Adrian Dimcev's Blog | Quickly probing with OpenSSL for the status of a certificate using OCSP

I was playing the other days with the Online Responder from Windows Server 2008.
Out there might be several OCSP clients that you can use for manual OCSP probing for a status of a certificate(if OCSP is supported).
My usual approach is to use OpenSSL for quickly probing with OCSP for the status of a certificate if I want to do a manual test, as I like the way OpenSSL displays the OCSP information and that I can install OpenSSL on various operating systems.

Microsoft’s Windows (Vista, 7, Server 2008, Server 2008 R2) certutil tool does OCSP checks, but can be a little too noisy sometimes or might not print the entire desired info in respect with the OCSP request and response.
For example this certutil command(a simple and clean command) will check every CDP and AIA URL found on a certificate(can be quite handy in certain cases, that’s why I’ve mentioned it):

certutil –verify –urlfetch ‘cert’

For ‘cert’ specify the server’s certificate.
Say for an example(excuse the mess, I’ve got all the eggs in one basket in this lab):

certutil –verify –urlfetch abcd.cer

The corresponding Wireshark trace for the above certutil command(the OCSP request should be somewhere in this trace):

Alternatively we can use OpenSSL to check the status of a certificate using OCSP.
For example this command quickly sends an OCSP request and prints a summary of the OCSP response:

openssl ocsp –issuer ‘issuer_cert’ –cert ‘cert’ –CAfile ‘ca_cert’ –url ‘responder_url’ –no_nonce

- the –issuer option: the certificate of the issuer who signed the (server’s) certificate(it can get the issuer key from it to append this(hashed) to the OCPS request, see the OCSP request in the bellow Wireshark capture).
- the –cert option: the (server’s) certificate to be checked(in PEM format in the above command, on Windows save the certificate as Base-64 encoded X.509 if say, you view the server’s certificate from IE when you're connected to a secure web site), (it can get from it the serial number of the (server’s) certificate to append this to the OCPS request, see the OCSP request in the bellow Wireshark capture, the responder will check if a certificate with that serial number was revoked or not).
- the –CAfile option: the CA(s) certificate which issued the responder’s certificate(to verify the response, if not found OpenSSL might issue an Response Verify Failure). Alternatively you can use the –CApath option(please refer to the Extra Note at the end of this blog post).
- the –no_nonce option: do not add an OCSP nonce extension to a request.
- the –url option: specifies the responder’s URL(looks like OpenSSL does not (yet) read the OCSP URL from the certificate).

Say you want to check this server certificate:

Actually the lab1dca issued the responder certificate("the CA designated responder case"), see bellow, on the OCSP response(the responder signs this response) the responder’s certificate(the responder can append its certificate to the OCSP response) must be verified up to a trusted root CA which bellow is lab1dca. In some cases the OCSP responder might be a “global responder” which can respond for certificates issued by multiple CAs and has a separate certificate chain(not the case now).
Note that I’ve marked on the server’s certificate the corresponding OpenSSL options, and not on the responder’s certificate, as in practice probably would be more easier for one to get the needed info from this certificate rather from the responder’s certificate and there might be a certain degree of likeliness in not having to deal with a “global responder”(separate certificate chain).
Just keep in mind that the –CAfile or –CApath options do not necessarily specify the certificate(s) of the CA(s) that issued the server’s certificate, rather the one(s) that issued the responder’s certificate(which in this case are the same, "the CA designated responder case").

Responder certificate:

Example command for an OCSP request for the above server certificate:

openssl ocsp –issuer C:\CA\export\abc_ca.pem –cert C:\CA\export\abc.pem –CAfile C:\CA\export\abc_ca.pem –url http://lab1dc.carbonwind.net/ocsp –no_nonce

With the corresponding Wireshark trace:

If you are intrigued with the This Update value being prior to the Revocation time value(and if so how the certificate was known to be revoked at that prior time), this may have to do with Windows’ Effective Date (aka thisupdate), effective time, which by default is set to 10 minutes prior to the current date and time(the responder was the Online Responder from Windows Server 2008), probably for avoiding clock synchronization issues, thus append 10 minutes to the This Update value and things might start to have sense after this operation.

Say to picture an OCSP response from the Windows Server 2008 Online responder seen with Wireshark:

If you want to see more details(the OCSP request and the OCSP response) printed by OpenSSL append the –text option to the above command:

openssl ocsp –issuer C:\CA\export\abc_ca.pem –cert C:\CA\export\abc.pem –CAfile C:\CA\export\abc_ca.pem –url http://lab1dc.carbonwind.net/ocsp –no_nonce –text

Which translates into:

Or maybe you want to save the response to a file, just append the –respout ‘file’ option to the request:

openssl ocsp –issuer C:\CA\export\abc_ca.pem –cert C:\CA\export\abc.pem –CAfile C:\CA\export\abc_ca.pem –url http://lab1dc.carbonwind.net/ocsp –no_nonce –respout C:\CA\export\abcresp.der

Which translates into:

And we can later read this response with OpenSSL with the –respin ‘file’ option:

openssl ocsp –respin C:\CA\export\abcresp.der –CAfile C:\CA\export\abc_ca.pem –text

Which translates into:

Actually we can steal an OCSP response from Wireshark, like bellow, right-click the Online Certificate… and click Export Selected Packets Bytes… and save that to a file, file which you can later read with OpenSSL and the –respin ‘file’ option like we did above:

We can save both the request and response to a file, we just need to append the –reqout option to the above request(where we had only the –respout option):

openssl ocsp –issuer C:\CA\export\abc_ca.pem –cert C:\CA\export\abc.pem –CAfile C:\CA\export\abc_ca.pem –url http://lab1dc.carbonwind.net/ocsp –no_nonce –reqout C:\CA\export\abcreq.der –respout C:\CA\export\abcresp.der

And later read them both with the –reqin and –respin options:

openssl ocsp –reqin C:\CA\export\abcreq.der –respin C:\CA\export\abcresp.der –CAfile C:\CA\export\abc_ca.pem –text

Actually we can use the saved OCSP request to make a “fresh” OCSP request like this(we “feed” this saved request as input with the –reqin option and we do not need to specify anymore the issuer or the server’s certificate):

openssl ocsp –reqin C:\CA\export\abcreq.der –CAfile C:\CA\export\abc_ca.pem –url http://lab1dc.carbonwind.net/ocsp –text

Or just save an OCSP request to a file without sending it(maybe you want to use it later):

openssl ocsp –issuer C:\CA\export\abc_ca.pem –cert C:\CA\export\abc.pem –no_nonce –reqout C:\CA\export\abcreq.der –text

As you have noticed I’ve used the –no_nonce option(do not add an OCSP nonce extension to a request, id-pkix-ocsp-nonce, OID value: 1.3.6.1.5.5.7.48.1.2 (id-pkix-ocsp 2)) so far, and this is because it may cause troubles with certain responders, which will ignore it(and respond with no nonce) or reject the request. For example the Online Responder on Windows Server 2008, by default, rejects the request with an "unauthorized" error:

We can enable the Enable NONCE extension support option within the Window Server 2008 Online Responder’s Revocation Configuration, please refer to this guide, and have it respond to OCSP requests which contain this extension:

The nonce cryptographically binds a request and a response to prevent replay attacks, and the client is sure that the OCSP response is for its OCSP request. This should enhance the security against attacks that attempt to replay OCSP responses.
But the nonce extension may not fit well into high volume networks(one may use proxies to (carefully) cache OCSP responses).
So for such networks, other ways of providing freshness for an OCSP response(to make sure that the clients do not accept out-of-date responses that indicates a good status when in fact there is a more up-to-date response that specifies the status of revoked) can be used.
Like an accurate source of time, thus have the clients check for the existence of a nextUpdate field and such clients must ensure the current time, expressed in GMT time, falls between the thisUpdate and nextUpdate times.

Assuming we’ve enabled the nonce extension on the Window Server 2008 Online Responder we can now make with OpenSSL an OCSP request with this extension and get an answer for it(you can add the –nonce option to the command if you want, but when we send a request like so, it should be added by default):

Speaking about the Window Server 2008 Online Responder, it should not have any problems with the id-pkix-ocsp-response extension(id-pkix-ocsp 4, OID value: 1.3.6.1.5.5.7.48.1.4) containing the AcceptableResponse type id-pkix-ocsp-basic(OID value: 1.3.6.1.5.5.7.48.1.1), Firefox may sent such an OCSP request, as far as I know currently OpenSSL does not support this extension(so we cannot sent it with OpenSSL):

Extra Note:

Say you may have a server certificate like the bellow one(the chain till the root CA contains intermediate CA(s)):

As can be noted from bellow, the same Thawte SGC CA also issued the responder certificate("the CA designated responder case").
On the OCSP response(the responder signs this response) the responder’s certificate(the responder can append its certificate to the OCSP response) must be verified up to a trusted root CA which is VeriSign Class 3 Public Primary CA which issued Thawte SGC CA’s certificate. As already said in some cases the OCSP responder might be a global responder which can respond for certificates issued by multiple multiple CAs and has a separate certificate chain(not the case now).
Note that, one more time, above, I’ve marked on the server’s certificate the corresponding OpenSSL options, and not on the responder’s certificate, as in practice probably would be more easier for one to get the needed info from this certificate rather from the responder’s certificate and there might be a certain degree of likeliness in not having to deal with a “global responder”(a separate certificate chain).
Just keep in mind that the –CAfile or –CApath options do not necessarily specify the certificate(s) of the CA(s) that issued the server’s certificate, rather the one(s) that issued the responder’s certificate(which in this case are the same, "the CA designated responder case").

Responder's certificate:

If you use the –CAfile option, then place all the CAs certificates in a file, one after another, for example like this(all certs are in PEM format), the first one starting from top is the Thawte SGC CA’s certificate, and the last one is the VeriSign Class 3 Primary CA’s certificate:

The corresponding OCSP request using OpenSSL:

Alternatively you can use the –CApath option. With this we can specify a directory of trusted certificates, the certificates should have names of the form hash.0.
We can use this command to “populate” such a directory:

openssl x509 –subject_hash –in ‘ca_cert’ –out ‘file’

For example, for the CAs’ certificates from Google’s certificate, I can issue these commands:

Where:
- the x509 command is a multi purpose certificate utility.
- the –subject_hash option outputs the “hash” of the certificate subject name. Alternatively instead of the –subject_hash option you can use the –hash option, which is a synonym for the –subject_hash option(for backward compatibility reasons), see:

- the –in option specifies the certificate from which we extract the subject name(PEM format above).
- the –out option in this case basically “copies” the certificate we specified with the –in option in the hash directory.