Skip to Main Content

Java 8u31+ = OCSP broken?

41bf4e47-18fb-4c18-9202-bde010be2e6aApr 7 2015 — edited Apr 7 2015


We're trying to track down a problem we've been having with one of the applications we use.

The application in question is Novell Filr, more specifically the "Edit In Place" function it has which launches a Java applet.  This function worked perfectly until we updated Java to 8u31+ or 7u75+

The problem we have is that the applet won't start unless we change the "Check for TLS certificate revocation using:" setting to "Certificate Revocation Lists (CRLs)" or disable TLS certificate revocation checking completely.

If I enable logging, I see this in the console a few times:

network: Server requesting to set-cookie with "__cfduid=d1eb5ba861e8678921256a5a30bd22e451428422041; expires=Wed, 06-Apr-16 15:54:01 GMT; path=/;; HttpOnly"

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

We have an Extended Validation (EV) certificate with GlobalSign and we have verified that the chain is good.  GlobalSign insist there is no issue with their OCSP server and I'm inclined to believe them.  I've also been in contact with Novell and they aren't able to shed much light on this either.

I was searching through the Java bug database and found the following open bug:

Bug ID: JDK-6878826 Add support for Extended Validation certificates

Is this an issue or a red-herring?

I'm not a Java dev so please be gentle!



Post Details
Locked due to inactivity on May 5 2015
Added on Apr 7 2015