Quickly probing with OpenSSL for the status of a certificate using OCSP

by adrian 3. October 2009 11:18

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

certutil_big

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

certutil_wr

 

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:

cert_1_openssl
cert_1_1_openssl

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:

resp_cert_1_1
resp_cert_1_2

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

openssl_ocsp_1

With the corresponding Wireshark trace:

openssl_ocsp_1_wr

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:

ocsp_wr_3

 

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:

openssl_ocsp_2

 

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:

openssl_ocsp_3

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:

openssl_ocsp_4

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:

ocsp_wr_1
ocsp_wr_2

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

openssl_ocsp_12

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

openssl_ocsp_13

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

openssl_ocsp_14

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

openssl_ocsp_15

 

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:

openssl_ocsp_5

openssl_ocsp_5_wr_q
openssl_ocsp_5_wr_a

 

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:

win2008_ocsp_nonce_ext

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):

openssl_ocsp_6

openssl_ocsp_7

 

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):

ocsp_ff_wr_1
ocsp_ff_wr_2

 

Extra Note:

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

cert_2_openssl
cert_2_1_openssl

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:

resp_cert_2

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:

cas_all_cert

The corresponding OCSP request using OpenSSL:

openssl_ocsp_8
openssl_ocsp_9

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:

openssl_hash1

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:
openssl_hash2
- 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.

 

And we can rename now in the hash directory:
- the a file to a386470b.0
- the b file to 7651b327.0

hash_folder

And after that we can make an OCSP request using the CApath option instead of the CAfile option:

openssl_ocsp_10
openssl_ocsp_11

 

References:
- http://www.openssl.org/docs/apps/ocsp.html
- http://www.openssl.org/docs/apps/verify.html
- http://www.openssl.org/docs/apps/x509.html
- http://technet.microsoft.com/en-us/library/dd299867(WS.10).aspx
- http://www.ietf.org/rfc/rfc2560.txt
- http://www.ietf.org/rfc/rfc5019.txt

Tags:

SSL

Comments (1) -

Bin United States
4/16/2010 4:04:50 AM #

Do you have these certificates available for downloading? I can see the picture of PEM file. I'd like to have the real one.

Thanks!

Pingbacks and trackbacks (1)+

Comments are closed

Home | Hire me

Support this blog

Adds

Book Shelf

 

Month List