United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-7174966 : With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

Details
Type:
Bug
Submit Date:
2012-06-07
Status:
Closed
Updated Date:
2014-05-06
Project Name:
JDK
Resolved Date:
2013-05-29
Component:
security-libs
OS:
generic,windows_7
Sub-Component:
java.security
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7,7u10,7u25,8
Fixed Versions:
7u40 (b28)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
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.

                                    

Comments
URL:   http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/d61d06e30d0b
User:  lana
Date:  2013-06-03 19:46:42 +0000

                                     
2013-06-03
URL:   http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/d61d06e30d0b
User:  vinnie
Date:  2013-05-29 19:12:36 +0000

                                     
2013-05-29
OCSP revocation checking fails with Entrust SSL certificates. Affected tests:

CertPath/CertPathValidatorTest/OCSP_entrust.net_valid
CertPath/CertPathValidatorTest/OCSP_entrust.net_revoked
                                     
2013-05-23
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.
                                     
2012-11-21
SQE is OK to defer it to 7u12/6u40
                                     
2012-11-21
I think it is too late for 7u10
                                     
2012-11-20
Is this needed for 7u10 ? Please add comment.
                                     
2012-11-19
Also affected 

CertPath/CertPathValidatorTest/OCSP#OCSP_comodo.com 
JDK 7u10 b13 armvfp
                                     
2012-11-15



Hardware and Software, Engineered to Work Together