The Comodo cert has the 'keyCertSign' and 'cRLSign' keyUsage bits set. That's unusual but permitted by RFC 5280.
I could have changed the Signature.initVerify method to also accept that combination of keyUsage bits but that would affect all signatures. Sean suggested the approach where the OCSP client supplies the signer's public key rather than the signer's cert. It does mean that the signer's 'digitalSignature' keyUsage bit is no longer checked but since the RFC allows other bit combinations to be set then I think that skipping that check is acceptable. On 29 May 2013, at 13:42, Xuelei Fan wrote: > What's the key usage of the OCSP responder? I think it is more like a > problem of Comodo CA. This fix may loosen the checking of the validity > of the OCSP responder's certificate. > > Xuelei > > On 5/28/2013 7:30 PM, Vincent Ryan wrote: >> Please review the fix for: http://bugs.sun.com/view_bug.do?bug_id=7174966 >> >> The problem occurs when validating the signature of an OCSP response from >> the Comodo CA. >> The Signature class tests for the presence of the digitalSignature keyUsage >> setting when examining >> a signer's certificate. One solution is for the >> sun.security.provider.certpath.OCSPResponse class to >> pass the signer's public key rather than the signer's certificate. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/ >> >> Thanks. >> >
