How it works
SSL/TLS certificates signed by a Certificate Authority such as GeoTrust or Comodo must have a programmatic revocation mechanism. Traditionally, this came in the form of Certificate Revocation Lists (CRLs). When clients make a request to validate the chain of trust, one step in this process is pulling some metadata from the public x509 certificate of the server and reading an array of CRL endpoints to query. If the thumbprint of the certificate they are attempting to validate has been added to the CRL controlled by the issuer of the certificate, the certificate is presumed to have had its private key compromised, and the chain of trust validation fails. This mechanism works, but uses a lot of bandwidth on the part of both the server and the client. This results in longer load times for the user, especially if they have trouble resolving the CRL endpoint. OCSP Stapling flips this model on its head – instead of the client reaching out to the CA, the server queries the OCSP server periodically for signed, time-stamped response which it attaches to the certificate. This response makes its way to the clients, who can validate it on-the-fly without additional network calls.
OCSP Stapling in Nginx
If you’re running nginx as a reverse proxy in front of your other servers, that’s an ideal place to make this configuration change. It does not need to be made on each of the backing servers.
You’ll want to set two configuration directives inside your server block for each virtual host.
As a best practice, configuration items like these should live inside /etc/nginx/snippets/. They can then be applied to multiple virtual hosts.
Let’s assume you have a baseline SSL/TLS configuration you like to use in all of your virtual hosts, ssl.conf. Now we will create an ocsp.conf consisting of the following two lines:
text
ssl_stapling on; ssl_stapling_verify on;
In your myconfig.conf, you can add two includes
text
include /etc/nginx/ssl.conf; include /etc/nginx/ocsp.conf;
By organizing your configuration in this way, you only have to add one line at the top of each of your virtual hosts to take advantage of the server-wide configuration:
text
include /etc/nginx/snippets/myconfig.conf;
OCSP Stapling in Apache
In modern versions of Apache (Apache has supported OCSP stapling for almost ten years at this point), you can add the following to /etc/apache2/mods-available/ssl.conf.
text
SSLUseStapling On
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/ssl_stapling(32768)
This will enable OCSP Stapling globally.
OCSP Stapling in IIS
IIS has supported OCSP stapling since IIS 7 on Server 2008. However, there is one huge “gotcha”. If you use SNI to have multiple sites share a single port, OCSP becomes disabled unless you set the following registry key:
text
HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel\ EnableOcspStaplingForSni value 1
This can be created using the powershell command from an elevated prompt:
text
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\" -Name "EnableOcspStaplingForSni" -PropertyType DWord -Value 1
Verifying OCSP Stapling is enabled
You can verify that OCSP stapling is working properly by issuing:
shell
openssl s_client -connect yourserver.something.com:443 -tls1 -tlsextdebug -status
and looking for the OCSP Response status.
Alternatively, Qualys provides a free SSL/TLS test which will tell you, among other things, if OCSP stapling is enabled. www.ssllabs.com/ssltest/
Discussions and Comments
Click here to view and join in on any discussions and comments on this article.
