JDK-7198537 : Certificate validation fails with error "Wrong key usage"
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_7
  • CPU: x86
  • Submitted: 2012-09-14
  • Updated: 2012-09-20
  • Resolved: 2012-09-20
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 SP1 64Bit

EXTRA RELEVANT SYSTEM CONFIGURATION :
CRL and/or OCSP checking is enabled

A DESCRIPTION OF THE PROBLEM :
Certificate validation fails for an applet and a webstart application, both signed with a "VeriSign Class 3 Code Signing 2010 CA" certificate

REGRESSION.  Last worked in version 7

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Enable CRL and/or OCSP checking in the Java Control Panel.
Start the applet: https://www.buergerkarte.at/index.en.php (press the button "CARD" at the "Demo Login" in the upper right area)
or the webstart application: http://webstart.buergerkarte.at/mocca/

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
applet/webstart application starts after certificate validation.
ACTUAL -
error message: ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: java.security.InvalidKeyException: Wrong key usage

  See also: https://forums.oracle.com/forums/message.jspa?messageID=10573379#10573379


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.

CUSTOMER SUBMITTED WORKAROUND :
disable CRL and/or OCSP checking
Taken from the Oracle forum:

We receive the same error message as described above by user 956556, when certificate validation (CRL, OCSP or both) is activated.
The certificate is issued by "VeriSign Class 3 Code Signing 2010 CA"
The extensions are:
SEQUENCE :
SEQUENCE :
OBJECT IDENTIFIER : basicConstraints [2.5.29.19]
OCTET STRING :
SEQUENCE : ''
SEQUENCE :
OBJECT IDENTIFIER : keyUsage [2.5.29.15]
BOOLEAN : '��'
OCTET STRING :
BIT STRING UnusedBits:7 : '80'
SEQUENCE :
OBJECT IDENTIFIER : cRLDistributionPoints [2.5.29.31]
OCTET STRING : ''
SEQUENCE : ''
SEQUENCE : ''
CONTEXT SPECIFIC (0) : ''
CONTEXT SPECIFIC (0) : ''
CONTEXT SPECIFIC (6) : 'http://csc3-2010-crl.verisign.com/CSC3-2010.crl'
SEQUENCE :
OBJECT IDENTIFIER : certificatePolicies [2.5.29.32]
OCTET STRING :
SEQUENCE :
SEQUENCE :
OBJECT IDENTIFIER : [2.16.840.1.113733.1.7.23.3]
SEQUENCE :
SEQUENCE :
OBJECT IDENTIFIER : cps [1.3.6.1.5.5.7.2.1]
IA5 STRING : 'https://www.verisign.com/rpa'
SEQUENCE :
OBJECT IDENTIFIER : extKeyUsage [2.5.29.37]
OCTET STRING :
SEQUENCE :
OBJECT IDENTIFIER : codeSigning [1.3.6.1.5.5.7.3.3]
SEQUENCE :
OBJECT IDENTIFIER : authorityInfoAccess [1.3.6.1.5.5.7.1.1]
OCTET STRING :
SEQUENCE :
SEQUENCE :
OBJECT IDENTIFIER : ocsp [1.3.6.1.5.5.7.48.1]
CONTEXT SPECIFIC (6) : 'http://ocsp.verisign.com'
SEQUENCE :
OBJECT IDENTIFIER : caIssuers [1.3.6.1.5.5.7.48.2]
CONTEXT SPECIFIC (6) : 'http://csc3-2010-aia.verisign.com/CSC3-2010.cer'
SEQUENCE :
OBJECT IDENTIFIER : authorityKeyIdentifier [2.5.29.35]
OCTET STRING :
SEQUENCE :
CONTEXT SPECIFIC (0) : 'CF99A9EA7B26F44BC98E8FD7F00526EFE3D2A79D'
SEQUENCE :
OBJECT IDENTIFIER : netscape-cert-type [2.16.840.1.113730.1.1]
OCTET STRING :
BIT STRING UnusedBits:4 : '10'
SEQUENCE :
OBJECT IDENTIFIER : spcFinancialCriteriaInfo [1.3.6.1.4.1.311.2.1.27]
OCTET STRING :
SEQUENCE :
BOOLEAN : '00'
BOOLEAN : '��'

Comments
WORK AROUND A workaround is to disable certificate checking by OCSP. Use CRLs instead.
20-09-2012

EVALUATION The problem is caused by a check performed by the OCSP client when verifying the response from an OCSP Responder. The check compares the key identifiers of two certificates. However some certificates do not contain a key identifier so the match should not be attempted unless a key identifier is present in both certificates. The extra check was added in JDK 7u6 to address the case where two certs may have the same SubjectName but have different public keys.
20-09-2012

SUGGESTED FIX Modify sun.security.provider.certpath.OCSPresponder to perform the key identifier check only when both certs have a key identifier present.
20-09-2012