OCSP Stapling

HTTPS is, unfortunately, expensive. The security it gives, makes this performance hit necessary, however as I have tried to make aware performance is critical, so we want to do whatever we can to address this.

The HTTPS negotiation sequence involves, the web server providing a security certificate to the browser, and then some back and forth between the two while they negotiate how they are going to secure the channel. The web server, should also validate that certificate. This involve making a separate connection to the Certificate Authority that issued the certificate and checking if the certificate has been revoked. This can be done in two ways:

1. Downloading and checking a Certificate Revocation List (CRL), which is basically is a big list of all revoked certificates for that CA. This gets quite lengthy so is not a very scalable solution.
2. Making an Online Certificate Status Protocol (OCSP) request, where you ask specifically about the certificate you are checking. This is more scalable, and is the preferred option. It does require the CA to set up an OCSP service, though almost all CAs have these.

This requires an extra network request to the CA server. Network requests are expensive so you now have a double hit for implementing HTTPS, with a length encryption negotiation period, and then a separate call to another server to check the certificate. The impact of this can be see below. It's small but it's there.

CSP Stapling moves that second network request from the web browser to the web server. The web server will make a periodic call to the CA, get the OCSP response, and send it back when the web browser starts a HTTPS connection. This may seem strange to have the web server, verify it's own certificate, but the OCSP response is actually signed by the CA and so it's easy for the browser to tell if the web server has just made it up.

There are additional side benefits to turning on OCSP Stapling. There are some privacy concerns with OCSP checking, as you are effectively telling a third part (the CA) that you are looking at a web site. By having the web server serve the OCSP response, that is no longer an issue. Additionally if the OCSP server is unavailable, then the web server can continue to ue the cached response in the meantime (though web browsers implement a so called "soft fail" and so would just assume the certificate is valid in this case, but that may change in the future).

This depends on your web server. For Apache it's simply a matter of adding the following config to set up the stapling cache:

#Set up Stapling cache (used to send a message that our cert is still valid without users contacting our CA with a separate call) SSLStaplingCache shmcb:/www/cache/stapling_cache(128000)

and then adding below setting to each SSL vhosts config:

SSLUseStapling on

You can then check whether you've set this up correctly by running your website through the SSLLabs checking tool:

This can also be tested by using an openssl command such as this:

openssl s_client -connect www.tunetheweb.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' OCSP response: ====================================== OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: 0F80611C823161D52F28E78D4638B42CE1C6D9E2 Produced At: Sep 5 15:15:00 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 105FA67A80089DB5279F35CE830B43889EA3C70D Issuer Key Hash: 0F80611C823161D52F28E78D4638B42CE1C6D9E2 Serial Number: 08A25AFB23E1988FE2202BB505A89970 Cert Status: good This Update: Sep 5 15:15:00 2015 GMT Next Update: Sep 12 15:30:00 2015 GMT

Most of the mainstream web servers support OCSP Stapling and in fact IIS enables this by default. I really think other web servers should do this by default though Apache is ideologically opposed to implementing a "phone home" feature by default.

Web server support is strong across all the main browsers (Internet Explorer supporting it from Windows Vista onwards). However Chrome doesn't do OCSP checking, basically because they think it's ineffective (which incidentally has led to some interesting back and forth between some sites and Google's Adam Langley on the subject). However, since they do not do the OCSP call, there is no need for OCSP Stapling, and also no harm in returning the OCSP Stapling response.

Some load balancers (e.g. Citrix's Netscaler), which sit in front of some web servers, do not support OCSP Stapling and since they do the HTTPS termination, that means even if the underlying web server supports it the client does not benefit.

There are quite a few arguments (as mentioned above) which argue whether there is any point to certificate revocation checking. However no matter which side of that argument you fall on, there are good reasons not to switch on OCSP Stapling while some browsers are doing OCSP checks. It benefits users performance and privacy.

Turning on OCSP Stapling will cause the web server to make an occasional call to the CAs OCSP service, but the overhead of this is negligible. Obviously this does require an internet connection to be available to the web server which is not always the case when behind a corporate firewall or proxy, and currently most web servers do not make it easy allow connections via proxy servers.

Presently, OCSP Stapling only works on the web server certificate, but the whole chain should be checked. This means one or more OCSP checks may still be performed on the intermediate certificates, limiting the performance benefits. An extension to the protocol proposes allowing all OCSP responses to be pinned, but this is not supported yet.

It is worth checking if there are any issues with the version of the web server you are using (Apache has a list of OCSP-Stapling bug fixes for example). Ryan Sleevi from Google has compile a long list of gripes about the current state of OCSP-Stapling support on web servers, which is well worth a read.

OCSP Stapling is a pretty simple check that web servers should turn on to provide a performance benefit to any browsers which do OCSP checking (pretty much everyone but Chrome). While some argue as to the point of OCSP checks, that is not a reason not to turn on OCSP Stapling and there are suggestions to implement a must staple proposal (either as part of the certificate or as a HTTP header), which would insist OCSP Stapling was used and address most of the issues with OCSP checking. Yes there are implementation issues of this feature in most of the web servers, and handling of failures could be considerably better but a large part of this will depend on the stability of your certificate providers OCSP service. Personally I've had no real problems using this on this website but it is worth monitoring for errors when first switching on.

• The official RFC for the extensions used by OCSP Stapling.
• The wikipedia page.
• The case for "OCSP Must-Staple - an interesting paper on the next iteration of OCSP Stapling.
• Ryan Sleevi's requirements for OCSP stapling support.

This page was originally created on 09-Aug-2015 and last edited on 28-Jun-2022.