1 2 Previous Next 20 Replies Latest reply on Jul 3, 2015 11:33 AM by Lucas DC

    Java 8 u31 fails revocation check on SSL certificate

    2844817

      We had no problems with our GeoTrust SSL certificate until clients started using the latest Update 31 for Java 8.

      After that we get a warning that our applet is unsecure because revocation check failed:

       

      "Unable to ensure the certificate used to identify the application has not been revoked ..... was generated with a certificate from a trusted certificate authority, but we are unable to ensure that it was not revoked by that authority."

       

      We get the following errors in the java console:

       

      First:

      network: Connecting http://ocsp.***trust.com/ with proxy=DIRECT

      network: Connecting http://ocsp.***trust.com:80/ with proxy=DIRECT

      security: OCSP Response: GOOD

      security: Failing over to CRLs: Certificate does not specify OCSP responder

      security: Revocation Status Unknown

      com.sun.deploy.security.RevocationChecker$StatusUnknownException: Certificate does not specify OCSP responder

      at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)

      at com.sun.deploy.security.RevocationChecker.check(Unknown Source)

      at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)

      at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)

      at com.sun.deploy.security.RevocationCheckHelper.checkRevocationStatus(Unknown Source)

       

      Then:

      network: Connecting http://gtssl-ocsp.***trust.com/ with proxy=DIRECT

      network: Connecting http://gtssl-ocsp.***trust.com:80/ with proxy=DIRECT

      security: UNAUTHORIZED

      security: Failing over to CRLs: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED

      network: Connecting http://gtssl-crl.***trust.com/crls/gtssl.crl with proxy=DIRECT

      network: Connecting http://gtssl-crl.***trust.com:80/ with proxy=DIRECT

      network: Downloading resource: http://gtssl-crl.***trust.com/crls/gtssl.crl

      Content-Length: 16.623

      Content-Encoding: null

      network: Wrote URL http://gtssl-crl.***trust.com/crls/gtssl.crl to File C:\Users\maa\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\6\3a3d3f06-482da49e-temp

      cache: Adding MemoryCache entry: http://gtssl-crl.***trust.com/crls/gtssl.crl

      security: Revocation Status Unknown

      com.sun.deploy.security.RevocationChecker$StatusUnknownException: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED

      at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)

      at com.sun.deploy.security.RevocationChecker.check(Unknown Source)

      at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)

      at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)

      at com.sun.deploy.security.RevocationCheckHelper.checkRevocationStatus(Unknown Source)

      at com.sun.deploy.security.X509TrustManagerDelegate.checkTrusted(Unknown Source)

       

      Have anyone else had the same problem or have any ideas to solve it?

      Since the problem only occurs with u31 it seems unlikely that certificate is to blame but will be contacting GeoTrust aswell.

      Really hope to have this solved before the majority of clients start applying this update.

        • 1. Re: Java 8 u31 fails revocation check on SSL certificate
          2846106

          We're seeing the same issue. After upgrading to u31, we observe the following:

           

          1) When launching a jnlp page with .jar files properly signed with a code signing certificate, the splash page appears, then disappears.

           

          2) After about 90 seconds, a Security Warning pops up saying: "The connection to this website is untrusted." Clicking more information says: "The digital signature for this application was generated with a certificate from a trusted certificate authority, but we are unable to ensure that it was not revoked by that authority."

           

          3) After clicking continue, application download and validation proceeds.

           

          4) After another 30 seconds or so of nothing visible happening, the application starts running.

           

          Our signing certificate is from Entrust (yours appears to be from GeoTrust), so the problem doesn't seem specific to a particular certificate provider.

          We are not observing this behavior with other versions of the JDK, including 1.8u25. So, this does appear to be a problem new in u31.

          • 2. Re: Java 8 u31 fails revocation check on SSL certificate
            989464

            We also see this problem now, in 8.31.

             

            It was not a problem in 8.25.

            • 3. Re: Java 8 u31 fails revocation check on SSL certificate
              2846644

              Hi,

               

              We've had the same problem. The issue also occured within the JRE1.7-line, in which it was first noticeable in version 1.7u75 (1.7u72 did not have the problem).

               

              The issue is the result of the JRE not only checking the application for certificate-status, but also checking the chain of certificates of the webserver hosting the application (before the application is checked).

               

              In our case, the order of intermediate certificates attached to the webserver-certificate was wrong. Our .pem-file looked like this (simplified/decrypted):

               

              -----BEGIN RSA PRIVATE KEY-----
              -----END RSA PRIVATE KEY-----
              Web Server CERTIFICATE
              -----------------

              -----BEGIN CERTIFICATE-----
              CertificateX, Signed by Y, OCSP-url 1
              -----END CERTIFICATE-----

              INTERMEDIATE CA:
              ---------------------------------------

              -----BEGIN CERTIFICATE-----
              Certificate Z, Signed by Root, OCSP-url 3
              -----END CERTIFICATE-----
              -----BEGIN CERTIFICATE-----
              Certificate Y, Signed by Z, OCSP-url 2
              -----END CERTIFICATE-----

               

              As I didn't know that the order of the CA's was having effect on the OCSP-checking, i started looking at the actual Requests being sent to the OCSP-locations.I observed the OSCP-request from JRE asking OCSP-url1 for the validity of CertificateX, for issuer Z, instead of Y.

               

              As soon as we've changed the order of the CA's of the Intermediate-section into this:

               

              -----BEGIN CERTIFICATE-----

              Certificate Y, Signed by Z, OCSP-url 2

              -----END CERTIFICATE-----

              -----BEGIN CERTIFICATE-----

              Certificate Z, Signed by Root, OCSP-url 3

              -----END CERTIFICATE-----

               

              The OCSP-requests were made to ask OCSP-url 1 the validity of X, as if it were issued by Y, which represents the actual situation, and which retured "GOOD". Subsequently, the certificate-warning no longer popped-up.

               

              So, the issues could be solved by supplying all of the Intermediate CA's to the webserver-certificate on the webserver, in the right order.

              1 person found this helpful
              • 4. Re: Java 8 u31 fails revocation check on SSL certificate
                2846106

                After a number of experiments, I suspect that 8u31 is failing to use the correct proxy server when attempting to contact the certificate issuer to verify that the certificate has not been revoked.

                 

                So, environments that make use of a proxy server for external connections (which would be most corporate environments, I'd imagine) won't be able to successfully perform the validation.

                 

                To the person who began this thread, I see the following in your traceback:

                 

                network: Connecting http://gtssl-ocsp.***trust.com/ with proxy=DIRECT

                 

                Are you running in a corporate environment where most connections to "the outside world" would normally go through a proxy server (rather than a DIRECT connection)?

                • 5. Re: Java 8 u31 fails revocation check on SSL certificate
                  2846106

                  The symptoms I'm seeing look quite alot like this previously closed Java bug:

                  JDK-8020390 : LSP: LocalSecurityPolicy is initialized too soon

                   

                  http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8020390

                   

                  I wonder if u31 re-introduced the problem.

                  • 6. Re: Java 8 u31 fails revocation check on SSL certificate
                    Edenshaw

                    We are having similar issues when we load our applet.

                     

                    As 989464 said, we didn't have this problem with previous versions of Java 8, only with u31

                     

                    Is this a problem with the certificate or is it a problem with the way Java 8u31 processes the validation of the certificate?

                    • 7. Re: Java 8 u31 fails revocation check on SSL certificate
                      2846106

                      I think it is a problem with the way Java 8u31 processes the validation of the code signing certificate.

                       

                      If my hunch is correct (and I'll admit that is a big "if"!), Applets and Webstart Applications will generate these warnings in any environment that requires connecting to the outside world through a Proxy server. The runtime needs to contact the certificate issuer (Entrust, or GeoTrust for example) to make sure the code signing certificate hasn't been revoked, but it appears to incorrectly always be using a DIRECT connection to make that contact.

                      • 8. Re: Java 8 u31 fails revocation check on SSL certificate
                        989464

                        In our environment all web-traffic goes through a webfilter that inserts its own certificate (trusted by windows) so that it can scan the https-traffic.

                         

                        I see this certificate as "issuer" when I view the certificate in "details" in the warning java creates.

                         

                        Java 8.31 introduced a series of warning messages creating a huge number of concerned customers:

                         

                        "The connection to the website is untrusted ( ...) The digital signature for this application was generated with a certificate from a trusted certificate authority, but we are unable to ensure that is was not revoked by that authority"

                         

                        It is important to note that this works like a transparent proxy, so there is no proxy-setup on the client.

                         

                        As a workaround we have refrained the webfilter from scanning https-traffic that uses certificates with subjects used in the certificates involved.

                        • 9. Re: Java 8 u31 fails revocation check on SSL certificate
                          ed303c9d-9885-42c2-8d53-e1dc25c52bd8

                          In our organization we have an web application that uses Signed Applets (by a trusted authority), but we are facing the same problem with Java 8 U31.

                          We have tested the application in our network and outside it (without a proxy) and the same error occurs.

                          The exception is the same. When the applet is loading it shows the following message in the console:

                           

                          security: Failing over to CRLs: java.security.cert.CertPathValidatorException: Responder's certificate is not authorized to sign OCSP responses

                           

                          I was wondering if there is a configuration in the app/web server that includes "OCSP" on the secured connection. .

                          I found the following link about it:

                          How to set up OCSP using OpenSSL - I-Space Research Labs

                          • 10. Re: Java 8 u31 fails revocation check on SSL certificate
                            2844817

                            Our provider said that SSLv3 has been disabled in 8u31 and that was the only protocol enabled on our certificate server, so after switching to TLS that specific problem has been solved.

                            However our app stopped working instead, but we are working on that.

                             

                            Running the SSL Toolbox from GeoTrust we got a error that certficates was installed in the wrong order, so that might also have played a role as another user mentioned (that issue we have not fixed yet).

                            But if that's the case it's strange it would only start failing after 8u31, so I still think the protocol-thing is the main culprit.

                             

                            You can test your site here: https://www.ssllabs.com/ssltest/

                            Then check that protocols other than SSL3 / SSLv3 is enabled like TLS

                             

                            EDIT: changelog info about it

                             

                            SSLv3 is disabled by default

                            Starting with JDK 8u31 release, the SSLv3 protocol (Secure Socket Layer) has been deactivated and is not available by default. See the java.security.Security property jdk.tls.disabledAlgorithms in <JRE_HOME>/lib/security/java.security file.

                            If SSLv3 is absolutely required, the protocol can be reactivated by removing "SSLv3" from the jdk.tls.disabledAlgorithms property in the java.security file or by dynamically setting this Security property to "true" before JSSE is initialized.

                            It should be noted that SSLv3 is obsolete and should no longer be used.

                            • 11. Re: Java 8 u31 fails revocation check on SSL certificate
                              2844817

                              The certificate is installed on a loadbalancer which is then used on semi-public websites (ipfiltered).

                              We have 2 ranges of sites (not identical ranges but close) with 2 different certificates, but only the 1 from GeoTrust has the issue.

                              So don't think proxy is the issue.

                               

                              AFAIK the PROXY/DIRECT function is controlled by the Java Control Panel Network Settings it self (where you can set a proxy) as it is the Java client that needs to contact certificate authority, not the server.

                              So if your browser can access the URL in the stack trace manually (you typing it in) without proxy, so should Java be able to (I would think).

                               

                              And by default Java uses the web browser network settings, so if you can acess both your website and the certificate authority URL in your browser, so should Java be able to.

                              If your browser uses a PROXY Java should use the same PROXY by default.

                              • 12. Re: Java 8 u31 fails revocation check on SSL certificate
                                2846106

                                As noted in a previous response:

                                 

                                • AFAIK the PROXY/DIRECT function is controlled by the Java Control Panel Network Settings it self (where you can set a proxy) as it is the Java client that needs to contact certificate authority, not the server.
                                • So if your browser can access the URL in the stack trace manually (you typing it in) without proxy, so should Java be able to (I would think).
                                • And by default Java uses the web browser network settings, so if you can acess both your website and the certificate authority URL in your browser, so should Java be able to.
                                • If your browser uses a PROXY Java should use the same PROXY by default.

                                 

                                That is indeed the way *it is supposed* to work. But, this has been a bit of a problematic area during initialization of applets and webstart programs.

                                 

                                See, for example, this bug report (for 1.7u25):

                                Bug ID: JDK-8020671 JWS doesn't use java control panel proxy settings when check for cert revoke

                                 

                                That was ultimately closed as a duplicate of this one:

                                Bug ID: JDK-8020390 LSP: LocalSecurityPolicy is initialized too soon

                                 

                                In tests on our system running 1.8u31, we are seeing symptoms very similar to those reported in 8020671. We're wondering if it is possible that the problem reported  in 1.7u25 has reappeared in some form in 1.8u31. Could be lots of things, I suppose, and we'll pursue some of the other ideas reported in this thread.

                                • 13. Re: Java 8 u31 fails revocation check on SSL certificate
                                  2844817

                                  Figured out that our remaining problems are down to a separate (reported) bug where using TLS 1.0 sometimes does not work in 8u25 + 8u31.

                                  So when we switched from SSLv3 to TLS 1.0 we switched from one problem to another.

                                   

                                  But the original error of failed revocation check was down to only having the SSLv3 protocol enabled.

                                  • 14. Re: Java 8 u31 fails revocation check on SSL certificate
                                    Edenshaw

                                    There's seems to be a opened bug for this issue:

                                     

                                    https://bugs.openjdk.java.net/browse/JDK-8071709

                                     

                                    Although in the comments, they said that this is a duplicated issue of INTJDK-7614270 which I wasn't able to find in their web-site

                                     

                                    Thinking that the problem was SSLv3, I updated my Firefox to 35 and re-test our applet but still the same error.

                                     

                                    Because in the logs there was this line:

                                     

                                    security: "Failing over to CRLs: Certificate does not specify OCSP responder"
                                    

                                     

                                    I used openssl to check if my signing certificate was in fact missing the OCSP uri:

                                     

                                    openssl x509 -noout -ocsp_uri -in mycert.pem

                                     

                                    and the URI was: http://ocsp.godaddy.com/

                                    1 2 Previous Next