OCSP Validation With OpenSSL
OCSP Validation With OpenSSL
In this post, we explore how to add authentication and validation protocols to your applications using OSCP and OpenSSL.
Join the DZone community and get the full member experience.Join For Free
Protect your applications against today's increasingly sophisticated threat landscape.
I have been working on understanding and troubleshooting an OCSP implementation and learned a few things and thought I could share them on the blog.
What Is OCSP?
Online Certificate Status Protocol (OCSP) defined in RFC 2560 is a protocol that:
enables applications to determine the (revocation) state of an identified certificate. OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responder provides a response.
Basically, OCSP is a mechanism where a client can ask the CA if a certificate is valid. This method is better than a Certificate Revocation List (CRL). In the CRL method, the CA publishes a list of all the certificates with which it has issues and that have now been revoked. Instead of processing this whole bunch, the client can check the status of just one certificate with OCSP.
Here are the steps of OCSP, as explained in the OCSP Stapling blog by Mozilla.
What Is OCSP Stapling?
With OCSP, the client is responsible for making a call to the CA (OCSP responder) to verify the status of a server certificate. This can cause additional round-trip delays. So an alternate solution was designed where the server could help. When the client initiates the TLS handshake, the server can include the OCSP validation message along with its certificate. By "stapling" the verification information, the client can complete the hand-shake faster.
OCSP stapling was originally defined as Transport Layer Extension in RFC 6066. Specifically, the RFC calls out this functionality:
Allow TLS clients and servers to negotiate that the server sends the client certificate status information (e.g., an Online Certificate Status Protocol (OCSP) [RFC2560] response) during a TLS handshake. This functionality is desirable in order to avoid sending a Certificate Revocation List (CRL) over a constrained access network and therefore saving bandwidth.
Again, here's the working of OCSP stapling from OCSP Stapling blog by Mozilla.
OCSP verification has been around for some time and OCSP stapling has been baked into browsers for the past few years now. It is now gaining more widespread use as IoT devices have started to implement mutual authentication schemes.
Testing OCSP With OpenSSL
I had been working on an implementation that uses this OCSP Stapled response. The use case was that a connected device makes a request to a server over TLS. The device presents a client cert to authenticate itself to the server. The server verifies and then responds back with its certificate and the stapled OCSP response for the client to authenticate.
We ran into issues over the stapling and we had to verify the result. For this purpose, I am showing a request/response that does not include client certificates. This just makes the discussion a little bit simple.
To work on this aspect, I started to use OpenSSL and here are the steps to achieve it:
Step 1: Get the Server Certificate
First, make a request to get the server certificate. When using the
openssl s_client -connect command, this is the stuff between
------BEGIN CERTIFICATE----- and
-----END CERTIFICATE-----. I am using www.akamai.com as the server.
openssl s_client -connect www.akamai.com:443 < /dev/null 2>&1 | sed -n '/-----BEGIN/,/-----END/p' > certificate.pem
The server certificate is saved as certificate.pem.
Step 2: Get the Intermediate Certificate
Normally, a CA does not sign a certificate directly. They use intermediaries and we need to this make the OpenSSL command work. So, make a request to get all the intermediaries.
To view the list of intermediate certs, use the following command.
openssl s_client -showcerts -connect www.akamai.com:443 < /dev/null 2>&1 | sed -n '/-----BEGIN/,/-----END/p'
The very first certificate is the server certificate we saved in step 2. For all the certificates below it, copy and save to a file named chain.pem.
Step 3: Get the OCSP Responder for a Server Certificate
The next step is to get the OCSP responder information. There are two ways to do this:
OCSP Responder With a Command
We can use the server certificate, certificate.pem, and run a command to extract just the OCSP responder field:
$ openssl x509 -noout -ocsp_uri -in certificate.pem http://ss.symcd.com
So here, http://ss.symcd.com is the OCSP responder.
OCSP Responder by Examination
We can use the OpenSSL command to print all the server certificate information using this command:
openssl x509 -text -noout -in certificate.pem
In the response, look for the section named Authority Information Access. This will hold the OCSP responder URL. In this case, here's what I see:
Authority Information Access: OCSP - URI:http://ss.symcd.com CA Issuers - URI:http://ss.symcb.com/ss.crt
Step 4: Make the OCSP Request
Now that we have the server certificate, the CA certificate chain and the OCSP responder URL, we can make the actual verification call.
openssl ocsp -issuer chain.pem -cert certificate.pem -text -url http://ss.symcd.com
Here's the relevant part of the response.
OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: D1B1648B8C9F0DD16BA38ACD2B5017D5F9CFC064 Issuer Key Hash: 5F60CF619055DF8443148A602AB2F57AF44318EF Serial Number: 7E34F9C3D2D21D999B668CC6C80EA4A8 Request Extensions: OCSP Nonce: 0410AE9A77D9FBDE8F7EC1F0C3305183BAEC OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: A2117BB82AC97305A9CCC170F80F82442BBF509A Produced At: Sep 12 16:58:10 2017 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: D1B1648B8C9F0DD16BA38ACD2B5017D5F9CFC064 Issuer Key Hash: 5F60CF619055DF8443148A602AB2F57AF44318EF Serial Number: 7E34F9C3D2D21D999B668CC6C80EA4A8 Cert Status: good This Update: Sep 12 16:58:10 2017 GMT Next Update: Sep 19 16:58:10 2017 GMT
The most important part is the Cert Status: good line. This indicates that everything is kosher and the client can trust the certificate. The other part of interest is the details Next Update. This indicates the OCSP stapling response can be cached until that time so that we don't overload the OCSP responder.
Bonus: Dissecting an OCSP Request
I was curious to see what actually happens during the OCSP request and ran a Wireshark trace. When we make the OCSP request, this is submitted as an HTTP POST. In this case, the headers looked like this:
POST / HTTP/1.0 Content-Type: application/ocsp-request Content-Length: 120 0v0t0M0K0I0..+..........d... .k...+P.....d.._`.a.U..C..`*..z.C....~4.......f.......#0!0..+.....0........w....~...0Q... HTTP/1.0 200 OK Server: nginx/1.10.2 Content-Type: application/ocsp-response Content-Length: 1609 content-transfer-encoding: binary Cache-Control: max-age=329052, public, no-transform, must-revalidate Last-Modified: Tue, 12 Sep 2017 16:58:10 GMT Expires: Tue, 19 Sep 2017 16:58:10 GMT Date: Fri, 15 Sep 2017 21:33:58 GMT Connection: close
If you notice, the "Cache-Control: max-age=329052" will be equal to telling the client to cache the response until the Next Update time period. So the POST request can be cached.
OCSP request/response sounds a bit complex but, ultimately it is just an HTTP request/response and can be tested with simple command line tools.
Published at DZone with permission of Akshay Ranganath , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.