I’m trying to validate a certificate path with stapled OCSP checking through CertPathValidator. There might be some RFC-protocol that prohibits what I expect to validate just fine, but I’ve been unable to find this.
Some paint art to describe relations between certificates discussed: overview
When verifying the certificate path I get an exception stating that the responder is not authorized to sign OCSP responses.
CertPathValidatorException: Responder’s certificate is not authorized to sign OCSP responses
This is due to sun.security.provider.certpath.OCSPResponse:561. The checks leading to this outcome expect the certificate used to sign the OCSP response (or its issuer) to be the same as the one issuing the certificate of the signature we are verifying.
This is however not the case here. OCSP responders certificate has extended key usage for OCSP-signing, should it not be able to sign OCSP responses when there is an intermediate between the CA and signers certificate?
Advertisement
Answer
If you stumble upon the same problem;
I added the responding certificate for the OCSP to PKIXRevocationChecker.setOcspResponderCert() after validating that it originates from the root CA or is the root CA. The revocation checker will still validate that the responding certificate has the proper extensions to sign OCSPs.