Skip to Main Content

Java Security

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Java 8u31+ = OCSP broken?

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

Hi,

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 http://ocsp2.globalsign.com/gsextendvalsha2g2 requesting to set-cookie with "__cfduid=d1eb5ba861e8678921256a5a30bd22e451428422041; expires=Wed, 06-Apr-16 15:54:01 GMT; path=/; domain=.globalsign.com; HttpOnly"

security: Failing over to CRLs: java.security.cert.CertPathValidatorException: 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!

Thanks

-Iain.

Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on May 5 2015
Added on Apr 7 2015
0 comments
1,724 views