"JCE cannot authenticate the provider BC" when BC is repackaged within another jar

[Raghavendranc]

Hi,

We are working on a standalone application where License3j is used for Licensing feature, and License3j in turn uses bouncy castle (bcprov-jdk16-1.46.jar). Our product is a jar and we repackage the class files of License3J and its dependencies (in this case the BCprov jar) into this jar.

When we tried to execute our application through command line, we are getting the following exception, “JCE cannot authenticate the provider BC” (Please find the attached stack trace).

Caused by: org.bouncycastle.openpgp.PGPException: Exception creating cipher
at org.bouncycastle.openpgp.PGPSecretKey.extractKeyData(Unknown Source)
~[LicenseGenerator-2.0.0-467.jar:na]
at org.bouncycastle.openpgp.PGPSecretKey.extractPrivateKey(Unknown Sourc
e) ~[LicenseGenerator-2.0.0-467.jar:na]
at org.bouncycastle.openpgp.PGPSecretKey.extractPrivateKey(Unknown Sourc
e) ~[LicenseGenerator-2.0.0-467.jar:na]
at com.verhas.licensor.License.encodeLicense(License.java:465) ~[License
Generator-2.0.0-467.jar:na]
at com.truvenhealth.analyticsengine.licensegenerator.LicenseGeneratorImp
l.createLicense(LicenseGeneratorImpl.java:105) ~[LicenseGenerator-2.0.0-467.jar:
na]
... 2 common frames omitted
Caused by: java.lang.SecurityException: JCE cannot authenticate the provider BC
at javax.crypto.Cipher.getInstance(DashoA13_..) ~[na:1.6]
... 7 common frames omitted
Caused by: java.util.jar.JarException: Cannot parse file:/C:/Users/dharanirajd/D
esktop/Test/Test3/LicenseGenerator-2.0.0-467.jar
at javax.crypto.SunJCE_c.a(DashoA13_..) ~[na:1.6]
at javax.crypto.SunJCE_b.b(DashoA13_..) ~[na:1.6]
at javax.crypto.SunJCE_b.a(DashoA13_..) ~[na:1.6]
... 8 common frames omitted

While making the BC as an installed/bundled provider (placing the bcprov jar in the jre ext folder worked), we do not want this. We want the bcprov classes to be within our jar and want the BC to be registered dynamically.

We tried with the following scenarios, like,

1. Set the Bouncy castle jar in the classpath
2. Set the Provider dynamically with the priority, as, “Security.insertProviderAt(new BouncyCastleProvider(), 2)”
3. Also edited the java.policy file and set the grant permission for the bouncy castle jar.

Even after all the above 3 steps we are still getting the above exception.

But if we place the bouncy castle jar in the JAVA’s ext folder, then it’s working, but we didn’t want to go with that approach.

Can you please help us with your suggestions on how to get this working.

Thanks and Regards
Raga

[verhas]

we repackage the class files of License3J and its dependencies (in this case the BCprov jar) into this jar.

With that you loose the signature created by BC. The solution is to use the original JAR. Anything else is wrong approach.

On Thu, Apr 24, 2014 at 9:06 PM, Raghavendranc notifications@github.com
wrote:

Hi,
We are working on a standalone application where License3j is used for Licensing feature, and License3j in turn uses bouncy castle (bcprov-jdk16-1.46.jar). Our product is a jar and we repackage the class files of License3J and its dependencies (in this case the BCprov jar) into this jar.
When we tried to execute our application through command line, we are getting the following exception, “JCE cannot authenticate the provider BC” (Please find the attached stack trace).
Caused by: org.bouncycastle.openpgp.PGPException: Exception creating cipher
at org.bouncycastle.openpgp.PGPSecretKey.extractKeyData(Unknown Source)
~[LicenseGenerator-2.0.0-467.jar:na]
at org.bouncycastle.openpgp.PGPSecretKey.extractPrivateKey(Unknown Sourc
e) ~[LicenseGenerator-2.0.0-467.jar:na]
at org.bouncycastle.openpgp.PGPSecretKey.extractPrivateKey(Unknown Sourc
e) ~[LicenseGenerator-2.0.0-467.jar:na]
at com.verhas.licensor.License.encodeLicense(License.java:465) ~[License
Generator-2.0.0-467.jar:na]
at com.truvenhealth.analyticsengine.licensegenerator.LicenseGeneratorImp
l.createLicense(LicenseGeneratorImpl.java:105) ~[LicenseGenerator-2.0.0-467.jar:
na]
... 2 common frames omitted
Caused by: java.lang.SecurityException: JCE cannot authenticate the provider BC
at javax.crypto.Cipher.getInstance(DashoA13_..) ~[na:1.6]
... 7 common frames omitted
Caused by: java.util.jar.JarException: Cannot parse file:/C:/Users/dharanirajd/D
esktop/Test/Test3/LicenseGenerator-2.0.0-467.jar
at javax.crypto.SunJCE_c.a(DashoA13_..) ~[na:1.6]
at javax.crypto.SunJCE_b.b(DashoA13_..) ~[na:1.6]
at javax.crypto.SunJCE_b.a(DashoA13_..) ~[na:1.6]
... 8 common frames omitted
While making the BC as an installed/bundled provider (placing the bcprov jar in the jre ext folder worked), we do not want this. We want the bcprov classes to be within our jar and want the BC to be registered dynamically.
We tried with the following scenarios, like,

1. Set the Bouncy castle jar in the classpath
2. Set the Provider dynamically with the priority, as, “Security.insertProviderAt(new BouncyCastleProvider(), 2)”
3. Also edited the java.policy file and set the grant permission for the bouncy castle jar.
   Even after all the above 3 steps we are still getting the above exception.
   But if we place the bouncy castle jar in the JAVA’s ext folder, then it’s working, but we didn’t want to go with that approach.
   Can you please help us with your suggestions on how to get this working.
   Thanks and Regards

Raga

Reply to this email directly or view it on GitHub:
#5

[pka123]

@verhas : Actually the version of License 3j that we are using is 1.0.3 (latest). This uses Bouncy castle version jdk16-1.46 which though signed does not work still as the certificate is expired. Any suggestions how we can get this right?

[verhas]

I will release a new version with newer dependency. 

Workaround until that time: update dependency in pom and recompile license3j 1.0.3 as 1.0.3.yourname

Peter

On Fri, Apr 25, 2014 at 12:40 PM, pka123 notifications@github.com wrote:

@verhas : Actually the version of License 3j that we are using is 1.0.3 (latest). This uses Bouncy castle version jdk16-1.46 which though signed does not work still as the certificate is expired. Any suggestions how we can get this right?

Reply to this email directly or view it on GitHub:
#5 (comment)