This is a text-only version of the following page on https://raymii.org:
---
Title       :   OCSP Stapling on nginx
Author      :   Remy van Elst
Date        :   03-02-2014
URL         :   https://raymii.org/s/tutorials/OCSP_Stapling_on_nginx.html
Format      :   Markdown/HTML
---



When connecting to a server, clients should verify the validity of the server
certificate using either a Certificate Revocation List (CRL), or an Online
Certificate Status Protocol (OCSP) record. The problem with CRL is that the
lists have grown huge and takes forever to download.

OCSP is much more lightweight, as only one record is retrieved at a time. But
the side effect is that OCSP requests must be made to a 3rd party OCSP responder
when connecting to a server, which adds latency and potential failures. In fact,
the OCSP responders operated by CAs are often so unreliable that browser will
fail silently if no response is received in a timely manner. This reduces
security, by allowing an attacker to DoS an OCSP responder to disable the
validation.

<p class="ad"> <b>Recently I removed all Google Ads from this site due to their invasive tracking, as well as Google Analytics. Please, if you found this content useful, consider a small donation using any of the options below:</b><br><br> <a href="https://leafnode.nl">I'm developing an open source monitoring app called  Leaf Node Monitoring, for windows, linux & android. Go check it out!</a><br><br> <a href="https://github.com/sponsors/RaymiiOrg/">Consider sponsoring me on Github. It means the world to me if you show your appreciation and you'll help pay the server costs.</a><br><br> <a href="https://www.digitalocean.com/?refcode=7435ae6b8212">You can also sponsor me by getting a Digital Ocean VPS. With this referral link you'll get $100 credit for 60 days. </a><br><br> </p>


The solution is to allow the server to send its cached OCSP record during the
TLS handshake, therefore bypassing the OCSP responder. This mechanism saves a
roundtrip between the client and the OCSP responder, and is called OCSP
Stapling.

The server will send a cached OCSP response only if the client requests it, by
announcing support for the status_request TLS extension in its CLIENT HELLO.

Most servers will cache OCSP response for up to 48 hours. At regular intervals,
the server will connect to the OCSP responder of the CA to retrieve a fresh OCSP
record. The location of the OCSP responder is taken from the Authority
Information Access field of the signed certificate.

[This tutorial is also available for Apache][2]

### What is OCSP Stapling

OCSP stapling is defined in the [IETF RFC 6066][3]. The term "stapling" is a
popular term used to describe how the OCSP response is obtained by the web
server. The web server caches the response from the CA that issued the
certificate. When an SSL/TLS handshake is initiated, the response is returned by
the web server to the client by attaching the cached OCSP response to the
CertificateStatus message. To make use of OCSP stapling, a client must include
the "status_request" extension with its SSL/TSL Client "Hello" message.

OCSP stapling presents several advantages including the following:

 * The relying party receives the status of the web servers certificate when it is needed (during the SSL/TLS handshake).
 * No additional HTTP connection needs to be set up with the issuing CA.
 * OCSP stapling provides added security by reducing the number of attack vectors.

[Read][4] [one][5] [of][6] [the][7] [following][8] [links][9] for [more][10]
information on OCSP and OCSP stapling.

### Requirements

You need at least nginx 1.3.7 for this to work. This is not available in the
current Ubuntu LTS releases (12.04), [it has 1.1.19][11] and on CentOS you need
EPEL or the official repositories. However, it is easy [to install the latest
version of nginx.][12]

You also need create a firewall exception to allow your server to make outbound
connections to the upstream OCSP's. You can view all OCSP URI's from a website
using this one liner:



   OLDIFS=$IFS; IFS=':' certificates=$(openssl s_client -connect google.com:443 -showcerts -tlsextdebug -tls1 2>&1 </dev/null | sed -n '/-----BEGIN/,/-----END/ {/-----BEGIN/ s/^/:/; p}'); for certificate in ${certificates#:}; do echo $certificate | openssl x509 -noout -ocsp_uri; done; IFS=$OLDIFS


It results for google.com in:



   http://clients1.google.com/ocsp
   http://gtglobal-ocsp.geotrust.com


### nginx Configuration

Add the below configuration to your https (443) `server` block:



   ssl_stapling on;
   ssl_stapling_verify on;
   resolver 8.8.8.8 8.8.4.4 valid=300s;
   resolver_timeout 5s;


For the OCSP stapling to work, the certificate of the server certificate issuer
should be known. If the `ssl_certificate` file does not contain intermediate
certificates, the certificate of the server certificate issuer should be present
in the `ssl_trusted_certificate` file.

My certificate for raymii.org is issues by `Positive CA 2`. That certificate is
issued by `Addtrust External CA Root`. In my nginx `ssl_certificate` file all
these certificates are present. If that for you is not the case, create a file
with the certificate chain and use it like so:



     ssl_trusted_certificate /etc/ssl/certs/domain.chain.stapling.pem;


Before version 1.1.7, only a single name server could be configured. Specifying
name servers using IPv6 addresses is supported starting from versions 1.3.1 and
1.2.2. By default, nginx will look up both IPv4 and IPv6 addresses while
resolving. If looking up of IPv6 addresses is not desired, the `ipv6=off`
parameter can be specified. Resolving of names into IPv6 addresses is supported
starting from version 1.5.8.

By default, nginx caches answers using the TTL value of a response. The
(optional) `valid` parameter allows overrides it to be 5 minutes. Before version
1.1.9, tuning of caching time was not possible, and nginx always cached answers
for the duration of 5 minutes.

Restart your nginx to load the new configuration:



   service nginx restart


And it should work. Let's test it.

### Testing it

Fire up a terminal and use the following OpenSSL command to connect to your
website:



   openssl s_client -connect example.org:443 -tls1 -tlsextdebug -status


In the response, look for the following:



   OCSP response:
   ======================================
   OCSP Response Data:
       OCSP Response Status: successful (0x0)
       Response Type: Basic OCSP Response
       Version: 1 (0x0)
       Responder Id: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC
       Produced At: Feb  3 04:25:39 2014 GMT
       Responses:
       Certificate ID:
         Hash Algorithm: sha1
         Issuer Name Hash: 0226EE2F5FA2810834DACC3380E680ACE827F604
         Issuer Key Hash: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC
         Serial Number: C1A3D8D00D72FCE483CD84759E9EC0BC
       Cert Status: good
       This Update: Feb  3 04:25:39 2014 GMT
       Next Update: Feb  7 04:25:39 2014 GMT


That means it is working. If you get a response like below, it is not working:



   OCSP response: no response sent


You can also use the [SSL Labs][13] test to see if OCSP stapling works.

### Sources

 * [nginx documentation for resolver][14]

 * [nginx documentation for ssl_stapling][15]

  [1]: https://www.digitalocean.com/?refcode=7435ae6b8212
  [2]: https://raymii.org/s/tutorials/OCSP_Stapling_on_Apache2.html
  [3]: http://tools.ietf.org/html/rfc6066
  [4]: http://en.wikipedia.org/wiki/OCSP_stapling
  [5]: http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
  [6]: http://security.stackexchange.com/questions/29686/how-does-ocsp-stapling-work
  [7]: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
  [8]: http://www.thawte.com/assets/documents/whitepaper/ocsp-stapling.pdf
  [9]: http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html
  [10]: https://wiki.mozilla.org/Security/Server_Side_TLS
  [11]: http://packages.ubuntu.com/precise/nginx
  [12]: http://wiki.nginx.org/Install
  [13]: https://ssllabs.com
  [14]: http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver
  [15]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling

---

License:
All the text on this website is free as in freedom unless stated otherwise.
This means you can use it in any way you want, you can copy it, change it
the way you like and republish it, as long as you release the (modified)
content under the same license to give others the same freedoms you've got
and place my name and a link to this site with the article as source.

This site uses Google Analytics for statistics and Google Adwords for
advertisements. You are tracked and Google knows everything about you.
Use an adblocker like ublock-origin if you don't want it.

All the code on this website is licensed under the GNU GPL v3 license
unless already licensed under a license which does not allows this form
of licensing or if another license is stated on that page / in that software:

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.

Just to be clear, the information on this website is for meant for educational
purposes and you use it at your own risk. I do not take responsibility if you
screw something up. Use common sense, do not 'rm -rf /' as root for example.
If you have any questions then do not hesitate to contact me.

See https://raymii.org/s/static/About.html for details.