1 2 3 Previous Next 41 Replies Latest reply on Nov 4, 2009 10:18 AM by 843802

    BouncyCastle via Java Web Start 1.6.0_14

      I''ve written a jnlp-app using the bouncycastle crypto provider. After the update of Java Web Start to version 1.6.0_14 I get the following error:

      Java Web Start 1.6.0_14
      Verwendung der JRE-Version 1.6.0_14-b08 Java HotSpot(TM) Server VM
      Home-Verzeichnis des Benutzers = /home/jschwellach
      c:   Konsole löschen
      f:   Objekte in Finalisierungswarteschlange finalisieren
      g:   Speicherbereinigung
      h:   Diese Hilfemeldung anzeigen
      m:   Speicherbelegung anzeigen
      o:   Protokollierung auslösen
      p:   Proxy-Konfiguration neu laden
      q:   Konsole ausblenden
      r:   Richtlinien-Konfiguration neu laden
      s:   System- und Bereitstellungseigenschaften ausgeben
      t:   Threadliste ausgeben
      v:   Thread-Stack ausgeben
      +0-5: Trace-Stufe auf <n> setzen+
      Reading certificates from 66925 http://localhost:8080/bouncytest/bc.testclasses.jar | /home/jschwellach/.java/deployment/cache/6.0/37/6fb73f25-58be3bd9.idx
      Reading certificates from 199419 http://localhost:8080/bouncytest/bc.gov.server-jdk15-143-bos-0.1.jar | /home/jschwellach/.java/deployment/cache/6.0/2/a176802-5df6a3c5.idx
      Reading certificates from 10162 http://localhost:8080/bouncytest/junit-3.8.1.jar | /home/jschwellach/.java/deployment/cache/6.0/45/659b69ed-1db2c992.idx
      Reading certificates from 5138 http://localhost:8080/bouncytest/activation.jar | /home/jschwellach/.java/deployment/cache/6.0/42/458c262a-5fec5ca6.idx
      Reading certificates from 21318 http://localhost:8080/bouncytest/mail.jar | /home/jschwellach/.java/deployment/cache/6.0/38/e1b55a6-55474704.idx
      +     at org.bouncycastle.cms.test.SignedDataTest.init(SignedDataTest.java:366)+
      +     at org.bouncycastle.cms.test.SignedDataTest.suite(SignedDataTest.java:353)+
      +     at org.bouncycastle.cms.test.AllTests.suite(AllTests.java:22)+
      +     at AllTests.suite(AllTests.java:45)+
      +     at AllTests.main(AllTests.java:18)+
      +     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)+
      +     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)+
      +     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)+
      +     at java.lang.reflect.Method.invoke(Method.java:597)+
      +     at com.sun.javaws.Launcher.executeApplication(Launcher.java:1468)+
      +     at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1414)+
      +     at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1225)+
      +     at com.sun.javaws.Launcher.run(Launcher.java:114)+
      +     at java.lang.Thread.run(Thread.java:619)+
      Caused by: java.lang.RuntimeException: java.security.NoSuchProviderException: JCE cannot authenticate the provider BC
      +     at org.bouncycastle.cms.test.CMSTestUtil.<clinit>(CMSTestUtil.java:164)+
      +     ... 14 more+
      +#### Java Web Start Error:+
      +#### null+

      With Java Web Start 1.6.0_13 all works fine.

      Any suggestions?

      J. Schwellach
        • 1. Re: BouncyCastle via Java Web Start 1.6.0_14
          J. Schwellach and Java Web Start community:

          While I can not provide any insights to the cause of this problem, I can confirm that we have also seen that Java Web Start 1.6.0_14 is unable to deal with the BouncyCastle encryption provider.

          The error message that we get (we don't dump a stack trace ....) is also the "cannot authenticate the provider BC" message:

          java.lang.SecurityException: JCE cannot authenticate the provider BC

          Note: we use a rather dated version of the Bouncy Castle provider (v 1.23, I believe) that has worked on all of the Java Web Start versions through the 1.5.0 series and now through 1.6.0_13. Java Web Start 1.6.0_14 is the first one that has encountered this exception so it would appear to be a problem introduced, as you suggest, in Java Web Start 1.6.0_14.


          • 2. Re: BouncyCastle via Java Web Start 1.6.0_14
            Hi John,
            I have filled a bug report, I will try to post the status of the report here.
            • 3. Re: BouncyCastle via Java Web Start 1.6.0_14
              I got the eactly the same issue as yours. Right now I am trying to downgrade my JDK to 1.6.0-13 but I could not find it from sun download site. Do you know where I can find the JDK 1.6.0-13 version?
              • 4. Re: BouncyCastle via Java Web Start 1.6.0_14
                Yes, if you go to the normal download page, you will see that you are on a tab labeled, I think, "Latest Release". At the far right is a tab that says "Previous Releases". If you click that, you would have the option of downloading JDK 5, JDK 1.4.2, etc. However, on that page, there is also a link to the Archive of previous releases. On that page you will find the ability to download JDK 1.6.0_13 so that you can go back to the previous release until this issue is resolved.

                Let me know if you have any further questions,

                • 5. Re: BouncyCastle via Java Web Start 1.6.0_14
                  Did you submit the bug? What is the bug ID?


                  • 6. Re: BouncyCastle via Java Web Start 1.6.0_14

                    Although it was not I who submitted the bug, it appears as if it is bug #6846531 which is listed as a high priority and apparently scheduled to be fixed in JDK 1.6.0_15. At least that's the way that I see it.

                    Here is the link:


                    • 7. Re: BouncyCastle via Java Web Start 1.6.0_14
                      the comments in that link mention that the problem can be worked around for now by signing an app's .jar files without a timestamp. I looked at the command-line options for the jarsigner tool, and the Ant documentation for the signjar task, but nothing jumped out at me. Could someone explain how to sign a .jar file without a timestamp?


                      - dan
                      • 8. Re: BouncyCastle via Java Web Start 1.6.0_14
                        Does this look similar to what you're asking?
                        • 9. Re: BouncyCastle via Java Web Start 1.6.0_14
                          I've experienced the same issue, but using standard jarsigner tool. A deployed application signed with a self-made certificate is executed with JRE 1.6_13 but not with 1.6_14. I'm not using Bouncy Castle Crypto provider.
                          Any hint ? The self made certificated it's expired: I wonder if JWS in JRE 1.6_14 checks time validity while previous releases didn't.

                          Thank you.
                          • 10. Re: BouncyCastle via Java Web Start 1.6.0_14

                            While I can't say what will happen for certain, if you've got a self-signed certificate, it should be a simple matter to create a new one that is not expired. That should at least allow you to test to see if this circumvents the problem that you are experiencing.

                            Good luck,

                            • 11. Re: BouncyCastle via Java Web Start 1.6.0_14
                              Note: The prevailing theory offered on the bug discussion cited above is that there are problems related to timestamps of the signed jar files. Thinking that this might be the problem, I checked the version of the Bouncy Castle provider that I had been using and found that it was indeed out of date. However, I purged the JWS cache, made sure that the old Bouncy Castle certificate was also removed, upgraded to the latest version of the Bouncy Castle provider in the JNLP extension that I'm using (version 143) and verified that it has been signed by a certificate that is still valid .... it is.

                              Alas, no joy .... I am still unable to start this application using Java Web Start 1.6.0_14. So, while I don't profess to be an expert on jarsigning and timestamps, it is not obvious to me what more I can do to make sure that I'm using only valid and non-expired certificates.

                              It seems to me that JWS 1.6.0_14 still has a serious bug and I can only hope that it will be resolved by 1.6.0_15. Now that JavaOne is over, hopefully, we'll hear something from the grand masters as Sun on this issue.


                              • 12. Re: BouncyCastle via Java Web Start 1.6.0_14
                                Thank you very much for your ansers. I forgot to say that I've only update the JRE and not the JDK; perhaps, installing new release of JDK, re-signing and re-deploying my apps may solve the issue.
                                I'll try when back in office....
                                • 13. Re: BouncyCastle via Java Web Start 1.6.0_14

                                  as the 6u15 just arrived and the above mentioned bug should've been fixed (though I was unable to verify through the release notes), the error is still in there.
                                  We have no timestamped jars, neither ours nor the bouncy castle ones, all certs are valid, ours is self signed.
                                  6u13 runs, 6u14/6u15 won't.
                                  I followed the instructions here: http://bouncycastle.org/devmailarchive/msg10415.html to no avail.
                                  The bcprov.jar is wrapped in its own jnlp and referred as extension from the "main" jnlp.
                                  The interesting parts of the stack trace are these:

                                  Caused by (via getCause): java.lang.SecurityException: JCE cannot authenticate the provider BC
                                       at javax.crypto.Cipher.getInstance(DashoA13*..)
                                       at javax.crypto.Cipher.getInstance(DashoA13*..)
                                  Caused by (via getCause): java.util.jar.JarException: Cannot parse https://localhost:8443/deploy/bcprov.jar
                                       at javax.crypto.SunJCE_c.a(DashoA13*..)
                                       at javax.crypto.SunJCE_b.b(DashoA13*..)
                                       at javax.crypto.SunJCE_b.a(DashoA13*..)
                                       at javax.crypto.Cipher.getInstance(DashoA13*..)
                                       at javax.crypto.Cipher.getInstance(DashoA13*..)

                                  For me it seems there's a problem with resolving the url of the bcprov.jar, which would explain the lack of a delay which normally occurs when JCE verifies the signature of the bcprov provider classes. The error pops up almost instantly.

                                  I'm clueless what to do now. Did Sun really achieve to completely destroy JCE provider functionality in Javaws, forcing us to use an alternative implementation?

                                  • 14. Re: BouncyCastle via Java Web Start 1.6.0_14
                                    Hi Patric,

                                    as far as I'm concerned, I solved a similar issue - i was not able to deploy application via jws any more, after installing JRE 1.6_14 - but i was working with a self-certificate and default crypto provider. In my case, I usually partition my classes in more than a single jar. I noticed that some jars were empty. In that case, JWS with 1.6_14 raises an exception.
                                    Removing any empty jar from jnlp solved my problem.

                                    Hope this will help.

                                    Edited by: mauriclaudio on Aug 5, 2009 12:35 PM
                                    1 2 3 Previous Next