OCSP Stapling on nginx

03-02-2014 | Remy van Elst


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.

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

What is OCSP Stapling

OCSP stapling is defined in the IETF RFC 6066. 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 one of the following links for more 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 and on CentOS you need EPEL or the official repositories. However, it is easy to install the latest version of nginx.

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 test to see if OCSP stapling works.

Sources


Tags: crl,nginx,ocsp,ocsp-stapling,revocation,ssl,ssl-labs,tls,