OCSP vs CRL: Revocation Explained

OCSP Stapling is a more efficient way to check if a certificate has been revoked than OCSP or CRLs.

Let’s watch a browser connect to a web server and see certificate revocation in action.

Here’s a typical TLS handshake when a browser connects to example.com over HTTPS:

1. Client Hello: Your browser sends a ClientHello message to the server, indicating supported TLS versions, cipher suites, and other parameters.
2. Server Hello: The server (example.com) responds with a ServerHello, selecting the TLS version and cipher suite.
3. Certificate: The server sends its digital certificate to the browser. This certificate is signed by a Certificate Authority (CA).
4. Certificate Verification (The Revocation Problem): Now, your browser needs to verify that the certificate is still valid and hasn’t been revoked by the CA. This is where OCSP and CRLs come in.

The Traditional Approach: CRLs (Certificate Revocation Lists)

• What it is: A CRL is a list published by a CA containing the serial numbers of all certificates that have been revoked.
• How it works: When your browser receives the server’s certificate, it needs to check if that certificate’s serial number appears on the CA’s CRL.
  • The certificate itself usually contains a URL (the CDP - CRL Distribution Point) pointing to the CRL.
  • Your browser downloads this entire CRL file (which can be megabytes in size).
  • It then searches the downloaded list for the serial number of the server’s certificate.

The Problem with CRLs:

• Size: CRLs can become very large, especially for CAs that issue many certificates. Downloading a multi-megabyte file for every HTTPS connection is inefficient and slow.
• Latency: The download and search process adds significant latency to the TLS handshake, delaying the start of your secure connection.
• Staleness: CRLs are not updated in real-time. They are published periodically (e.g., daily, weekly). A certificate could be revoked minutes after a CRL was published, but the CRL would only reflect this revocation on its next update. This leaves a window of vulnerability.

The Next Step: OCSP (Online Certificate Status Protocol)

• What it is: OCSP is a real-time protocol for checking certificate revocation status.
• How it works: Instead of downloading a whole list, your browser sends a specific query to an OCSP responder (a server run by the CA) asking about the status of a particular certificate.
  • The certificate contains an AIA (Authority Information Access) extension, which includes the URL of the OCSP responder.
  • Your browser sends a request to this URL, including the certificate’s serial number and the hash of the issuer’s certificate.
  • The OCSP responder checks its real-time revocation database and sends back a signed response: "good," "revoked," or "unknown."

The Problem with OCSP:

• Privacy: Your browser is directly contacting the CA’s OCSP responder. This means the CA knows which websites you are visiting because your browser is asking about their certificates.
• Latency (again): While better than CRLs, this still adds an extra network hop and processing time to the TLS handshake. If the OCSP responder is slow or unavailable, the browser might have to fall back to using the CRL or even abort the connection, depending on its configuration. This is known as "hard-fail" vs. "soft-fail."

The Modern Solution: OCSP Stapling

• What it is: OCSP Stapling (also known as Certificate Status Request) allows the web server to proactively fetch OCSP responses from the CA and "staple" them to its certificate when it sends it to the browser.
• How it works:
  1. The web server periodically queries the CA’s OCSP responder for the revocation status of its own certificate.
  2. The OCSP responder returns a signed OCSP response, which the server caches.
  3. When your browser initiates a TLS handshake with the server, the server includes its certificate and the cached, signed OCSP response in the Certificate message.
  4. Your browser receives the certificate and the OCSP response together. It verifies the OCSP response using the CA’s public key. If the response is "good" and the signature is valid, the browser knows the certificate is not revoked, and the handshake proceeds.

The Benefits of OCSP Stapling:

• Efficiency: No extra network hop for the browser. The browser gets all the necessary information directly from the server.
• Privacy: Your browser never directly contacts the CA’s OCSP responder. The CA only sees that the server is requesting its own status, not that you are visiting that server.
• Speed: Reduces TLS handshake latency significantly.
• Reliability: The server can manage fetching OCSP responses and handle potential issues with OCSP responders, rather than the browser being solely responsible.

Configuration Example (Nginx):

To enable OCSP stapling in Nginx, you typically add the following to your server block within your nginx.conf or site-specific configuration file:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/your/fullchain.pem; # This should contain your cert and intermediate certs
resolver 8.8.8.8 8.8.4.4 valid=300s; # Use public DNS resolvers, with a cache time
resolver_timeout 5s;

• ssl_stapling on;: Enables OCSP stapling.
• ssl_stapling_verify on;: Tells Nginx to verify the OCSP response it receives from the client before sending it. This is crucial for security.
• ssl_trusted_certificate: This directive is essential. Nginx needs to know the chain of trust to verify the OCSP response. It should point to a file containing your server certificate followed by any intermediate certificates.
• resolver: Specifies DNS servers Nginx will use to look up the OCSP responder’s address.
• resolver_timeout: Sets how long Nginx will wait for a DNS response.

After enabling OCSP stapling, you can test it using tools like SSL Labs (for public-facing sites) or by examining the TLS handshake details in your browser’s developer tools.

While OCSP stapling is the most efficient method, some older or misconfigured clients might still fall back to direct OCSP checks or CRLs if the stapled response is missing or invalid.

The next hurdle in secure communication is understanding and mitigating the impact of Logjam and FREAK vulnerabilities.