|
From: <oh...@ya...> - 2019-06-26 16:58:10
|
Hi Jaime (et al),
Ok, I figured it out. I was mistaken about the command line that we've been using with our normal OCSPD, and found that we are using the "openssl ocsp" with only "-issuer" and "-VAfile".
So I think we are ok now.
Thanks,
Jim
On Wednesday, June 26, 2019, 11:41:54 AM EDT, Jaime Hablutzel <hab...@gm...> wrote:
On Wed, Jun 26, 2019 at 10:28 AM ohaya--- via Ejbca-develop <ejb...@li...> wrote:
Hi,
Ok, I found that adding "-VAfile" and pointing that to the SIGNING CERTIFICATE, seems to make the error go away. I am not 100% why that needs to be added when sending an OCSP request for a cert issued by one CA (the SimpleAuthorityCA), but the "-VAfile" is not needed for OCSP request for a cert in the simpleca CA??
It is because the expected signer for OCSP responses depends on the certificate you are requesting status for. Quoting from RFC 6960, "2.2. Response":
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 requestor
- a CA Designated Responder (Authorized Responder, defined in
Section 4.2.2.2) who holds a specially marked certificate issued
directly by the CA, indicating that the responder may issue OCSP
responses for that CA
So, when you request status for a certificate issued by "SimpleAuthorityCA" you are against a response that is not signed by the "the CA who issued the certificate in question" nor a "a CA Designated Responder who holds a specially marked certificate issueddirectly by the CA" so you are left only with the "Trusted Responder whose public key is trusted by the requestor" and there is where the openssl ocsp "-VAfile" option applies. From "man ocsp":
-VAfile file
File containing explicitly trusted responder certificates.
|