Bug ID: JDK-7174966 With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

Type: Bug
Component: security-libs
Sub-Component: java.security
Affected Version: 6u85,7,7u10,7u25,8

Priority: P3
Status: Closed
Resolution: Fixed
OS: generic,windows_7
CPU: generic,x86

Submitted: 2012-06-07
Updated: 2018-11-21
Resolved: 2013-05-29

JDK 6	JDK 7	JDK 8
6u95Fixed	7u40 b28Fixed	8Fixed

FULL PRODUCT VERSION :
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b22)
Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :

With OCSP enabled in Java 7 you get an error when you try to load a page containing our java applet signed with a Comodo certificate. I tested this with the first release of Java 7 and Java 7 update 4. Both exhibit the same behavior.

With Java 6 update 32 it works as expected.

Analyzing the OCSP traffic indicates that the OCSP response was successful.

Comodo has this to say:
--------------------------------
It appears that Java is not following RFC 2560 which defines how all OCSP responses are to be digitally signed. [ http://www.rfc-editor.org/rfc/rfc2560.txt ; Page 2 ] It says:
" All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA "

We use the first option of "the CA who issued the certificate in question" but most other CAs such as Verisign (Symantec, Thawte, GeoTrust) and Entrust use the last one "a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA" where as Java should be supporting all three to be RFC Compliant.
--------------------------------


REGRESSION.  Last worked in version 6u31

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Install any JRE version 7 release.
2. Enable OCSP in Java Control Panel: Click Advanced tab, expand Security, expand General, check Enable Online Certificate Validation.
3. Make an HTML file with the following:
<html>
	<head>
	</head>
	<body>
		<applet code="NonExistingClass" archive="https://www.docuvantageondemand.com/DropZone_Applet/DVStoreDropZone.jar"></applet>
	</body>
</html>

4. Open the HTML file in a browser.




EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You should get the prompt asking you to trust the certificate in question. Here is the detail:
--------------
The application's digital signature has been verified. Do you want to run the application?

Name: NonExistingClass
Publisher: Document Advantage Corporation
  From: https://www.docuvantageondemand.com
--------------



ACTUAL -
Get an error dialog with this text:
The publisher cannot be verified by a trusted source.
Code will be treated as unsigned.

Name: NonExistingClass
ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: java.security.InvalidKeyException: Wrong key usage



ERROR MESSAGES/STACK TRACES THAT OCCUR :
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: java.security.InvalidKeyException: Wrong key usage
	at sun.security.validator.PKIXValidator.doValidate(Unknown Source)
	at sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
	at sun.security.validator.Validator.validate(Unknown Source)
	at sun.security.validator.Validator.validate(Unknown Source)
	at sun.security.validator.Validator.validate(Unknown Source)
	at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source)
	at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.isTrustedByTrustDecider(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.getTrustedCodeSources(Unknown Source)
	at com.sun.deploy.security.CPCallbackHandler$ParentCallback.strategy(Unknown Source)
	at com.sun.deploy.security.CPCallbackHandler$ParentCallback.openClassPathElement(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
	at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.security.cert.CertPathValidatorException: java.security.InvalidKeyException: Wrong key usage
	at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(Unknown Source)
	at sun.security.provider.certpath.PKIXCertPathValidator.doValidate(Unknown Source)
	at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(Unknown Source)
	at java.security.cert.CertPathValidator.validate(Unknown Source)
	... 36 more
Caused by: java.security.InvalidKeyException: Wrong key usage
	at java.security.Signature.initVerify(Unknown Source)
	at sun.security.provider.certpath.OCSPResponse.verifyResponse(Unknown Source)
	at sun.security.provider.certpath.OCSPResponse.<init>(Unknown Source)
	at sun.security.provider.certpath.OCSP.check(Unknown Source)
	at sun.security.provider.certpath.OCSPChecker.check(Unknown Source)
	... 40 more


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
The problem lies with the signing certificate that was used so this does not apply.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Uninstall Java 7 and install Java 6 update 32.

OCSP revocation checking fails with Entrust SSL certificates. Affected tests: CertPath/CertPathValidatorTest/OCSP_entrust.net_valid CertPath/CertPathValidatorTest/OCSP_entrust.net_revoked
23-05-2013
SQE is OK to defer it to 7u12/6u40
21-11-2012
I cannot reproduce this issue using the instructions above. The URL cited in the instructions uses a GeoTrust cert rather than a Comodo cert. This is not a showstopper for 7u10. It was first reported against 7u4.
21-11-2012
I think it is too late for 7u10
20-11-2012
Is this needed for 7u10 ? Please add comment.
19-11-2012
Also affected CertPath/CertPathValidatorTest/OCSP#OCSP_comodo.com JDK 7u10 b13 armvfp
15-11-2012

Duplicate :	JDK-6500710 - PKIXCertPathChecker fails if OCSP responder has keyUsage=nonRepudiation
Relates :	JDK-7197652 - Impossible to run any signed JNLP applications or applets, OCSP off by default