What is a Certificate Revocation List (CRL)?

A CRL is a signed, periodically published list of certificate serial numbers that have been revoked by a Certificate Authority. Clients download the full list and check whether a certificate's serial number appears in it. CRLs can be large (megabytes for major CAs) and are typically cached for hours to days, creating a revocation lag.

What is OCSP and how is it different from CRL?

OCSP (Online Certificate Status Protocol) is a real-time protocol where a client queries an OCSP responder with a specific certificate serial number and receives a signed 'good', 'revoked', or 'unknown' response. Unlike CRLs, OCSP checks are per-certificate and near-real-time, but they add latency to each TLS handshake and create a privacy risk by telling the CA which sites you visit.

What is OCSP stapling?

OCSP stapling is a TLS extension where the server fetches and caches a time-limited OCSP response from the CA's responder and presents it to clients during the TLS handshake. This eliminates the client-to-CA round trip, removes the privacy leak, and reduces handshake latency — while still providing a recent, CA-signed revocation status.

Does certificate revocation actually work in practice?

Traditional CRL and OCSP have significant weaknesses: browsers soft-fail (accept the connection) if revocation checks time out, CRLs can be days out of date, and OCSP responders can be slow or unreliable. Google's CRLSets and Mozilla's OneCRL are browser-curated blocklists that provide faster and more reliable revocation for the most critical certificates.

What is the difference between OCSP Must-Staple and regular OCSP stapling?

Regular OCSP stapling is optional — a client will still accept a certificate without a stapled response. OCSP Must-Staple is a certificate extension (RFC 7633) that tells the client to reject the certificate if no valid stapled OCSP response is present. This closes the soft-fail loophole but requires the server to always have a fresh stapled response available.

How Certificate Revocation Works (CRL vs OCSP)

Q: What is certificate revocation?

Certificate revocation is the process of invalidating a digital certificate before its natural expiry date — typically because the certificate's private key was compromised, the certificate was mis-issued, or the organization's identity has changed. Browsers and TLS clients must check revocation status to avoid trusting a certificate that should no longer be valid.

Introduction

In March 2011, a hacker compromised the certificate authority Comodo and fraudulently obtained certificates for Google, Yahoo, Skype, and Mozilla — certificates that every browser in the world would have trusted as legitimate. The attack was discovered quickly, but the question it raised was urgent: how do you tell every browser, on every device, that a certificate is now invalid? The answer is certificate revocation — the mechanism by which a CA tells the world that a previously issued certificate should no longer be trusted. Revocation sounds simple, but implementing it at internet scale has proven surprisingly difficult. Browsers soft-fail when revocation checks time out. CRL files grow to megabytes. OCSP creates privacy leaks. OCSP stapling solves most of these problems — yet only a fraction of servers implement it correctly. Understanding how certificate revocation works, where it fails, and what the modern best practice is will help you build TLS deployments that remain secure even after a certificate compromise.

What Is Certificate Revocation?

Certificate revocation is the act of permanently invalidating a digital certificate before its stated expiry date. The Certificate Authority that issued the certificate publishes a signal — either a list or an online service — that clients can query to determine whether a certificate is still valid.

Revocation is necessary because certificates have long lifetimes — often 90 days to 1 year — and many things can invalidate them prematurely. A server’s private key may be stolen, making the certificate a tool for impersonation. A CA may have mis-issued the certificate with incorrect identity information. The certificate holder may have changed their domain or gone out of business. In each case, the certificate technically passes cryptographic validation but should not be trusted.

There are two primary mechanisms for publishing revocation information: Certificate Revocation Lists (CRL) and the Online Certificate Status Protocol (OCSP). Both are described in X.509 PKI standards and referenced in RFC 5280. Both have significant practical limitations that OCSP stapling addresses.

How Certificate Revocation Works

Certificate Revocation Lists (CRL)

A Certificate Revocation List is a signed file published by a CA that lists the serial numbers of all revoked certificates it has issued, along with the revocation reason and date. Every X.509 certificate contains a CRL Distribution Point (CDP) extension pointing to the URL where the CA publishes its current CRL.

When a client validates a certificate, it downloads the CRL from the CDP URL, parses the list, and checks whether the certificate’s serial number appears in it. CRLs are signed by the CA’s private key, so tampering is detectable.

The fundamental problem is scale: a major CA like DigiCert issues millions of certificates. Its CRL may be several megabytes and must be re-downloaded periodically. Browsers cache CRLs for hours or days to avoid constant large downloads, which means a freshly revoked certificate may still appear valid to a client with a cached CRL.

OCSP (Online Certificate Status Protocol)

OCSP is a request-response protocol (RFC 6960) where a client sends a query containing a specific certificate’s serial number to an OCSP responder operated by the CA. The responder returns a signed response — “good”, “revoked”, or “unknown” — within seconds.

OCSP is more bandwidth-efficient than CRL (per-certificate query instead of downloading the full list) and more timely (real-time instead of cached list). However, it introduces two serious problems:

Latency: Every TLS handshake requires an additional round-trip to the CA’s OCSP responder before the connection can proceed.
Privacy leak: The CA’s OCSP responder logs every certificate serial number queried — effectively tracking which websites each client visits.

OCSP Stapling

OCSP stapling (formally the TLS Certificate Status Request extension, RFC 6066) solves both problems. Instead of the client querying the CA, the server periodically fetches a fresh OCSP response for its own certificate and caches it. When a client connects, the server staples (attaches) this pre-fetched response to the TLS handshake alongside the certificate.

The client receives a CA-signed OCSP response without making any separate network request. The OCSP response is time-limited — typically valid for 24–48 hours — so the server must refresh it regularly. This removes the client-to-CA round trip, eliminates the privacy leak, and typically reduces TLS handshake time.

Three paths to revocation checking: CRL downloads the full revoked-certificate list; OCSP queries per-certificate in real time; OCSP stapling has the server pre-fetch and staple the response, eliminating client-to-CA round trips entirely.

Hussein Nasser explains all three revocation mechanisms with clear diagrams — watch particularly how OCSP stapling eliminates the client's need to contact the CA directly during the handshake.

CRL vs OCSP vs OCSP Stapling

Feature	CRL	OCSP	OCSP Stapling
Protocol	HTTP download of signed file	HTTP request/response (RFC 6960)	TLS extension (RFC 6066)
Granularity	Full revocation list	Per-certificate query	Per-certificate, server-cached
Freshness	Hours to days (cached)	Near-real-time	Up to 48 hours (server-cached)
Bandwidth	High — full list per client	Low — single certificate	Lowest — one CA fetch serves all clients
Latency impact	Moderate (large download, cached)	High — extra round-trip per handshake	None — bundled in handshake
Privacy	Good — CA doesn’t see individual requests	Poor — CA logs each client query	Good — client doesn’t contact CA
Soft-fail risk	Yes	Yes	Reduced with Must-Staple
Server support required	No	No	Yes — server refreshes stapled response

Real-World Use Cases

Browser-operated blocklists: Because both CRL and OCSP have soft-fail modes (browsers accept the connection if the check times out), Google Chrome and Mozilla Firefox maintain their own curated revocation lists. Chrome’s CRLSets and Firefox’s OneCRL are small, browser-shipped datasets of high-priority revoked certificates — primarily CA certificates and certificates flagged as security-critical. These are updated via browser updates rather than real-time queries, trading freshness for reliability. Understanding the broader PKI framework these revocation mechanisms operate within is covered in Public Key Infrastructure (PKI) Explained.

Let’s Encrypt OCSP infrastructure: Let’s Encrypt issues over 400 million active certificates and operates OCSP responders that handle billions of queries. Its short-lived 90-day certificates reduce revocation urgency — a revoked certificate expires within 90 days regardless — which is one of the arguments for shorter certificate lifetimes as a partial substitute for revocation. Short-lived certificates are increasingly the preferred approach for automated PKI deployments.

Enterprise internal PKI: Private CAs used for internal services — VPN certificates, internal web app TLS, device certificates — often publish CRL Distribution Points on internal servers accessible only to corporate clients. For enterprises running Microsoft AD CS or HashiCorp Vault PKI, configuring CRL and OCSP endpoints is a mandatory part of CA deployment. Failure to do so means clients cannot check revocation status and may accept compromised certificates indefinitely.

Common Mistakes to Avoid

Not enabling OCSP stapling on your web server: OCSP stapling is supported by Apache (with SSLUseStapling on), Nginx (with ssl_stapling on), and Caddy (enabled by default). Many servers ship with stapling disabled. Without stapling, every client must make a separate OCSP query to the CA, adding latency and leaking your users’ browsing activity to the CA.

Ignoring the soft-fail problem: Both CRL and OCSP have soft-fail behavior in most browsers — if the revocation check cannot be completed (network timeout, unreachable responder), the browser proceeds with the connection. This means an attacker who blocks OCSP traffic can effectively disable revocation checking. OCSP Must-Staple (the status_request TLS feature extension, RFC 7633) closes this gap by requiring a valid stapled response, but it demands that the server always have a fresh OCSP response available.

Forgetting to configure CRL Distribution Points in internal CA certificates: If you operate a private CA and issue certificates without CDP extensions, clients have no way to check revocation status. Always configure CDP and OCSP Authority Information Access (AIA) extensions when issuing certificates from an internal CA — even for internal-only services.

Letting OCSP staple responses expire: The server’s cached OCSP response has a validity window, typically 24–96 hours. If your server process cannot reach the CA’s OCSP responder to refresh the stapled response — due to network issues or the CA being temporarily unreachable — the stapled response will expire. With Must-Staple enabled, this causes clients to reject your certificate entirely. Monitor OCSP staple age and build in retry logic.

Getting Started

To implement revocation checking correctly:

First, enable OCSP stapling on every TLS-terminating server. In Nginx, add ssl_stapling on; ssl_stapling_verify on; along with a resolver directive pointing to a working DNS server. In Apache, add SSLUseStapling On and SSLStaplingCache. Test with OpenSSL’s s_client using the -status flag to confirm the stapled response is present and valid.

Second, validate your CRL and OCSP AIA extensions in issued certificates. Use OpenSSL to inspect the extensions: confirm the CDP URL is reachable and returns a valid, parseable CRL, and confirm the OCSP responder URL returns a “good” status for valid certificates. Broken CDP or AIA URLs mean clients cannot check revocation, defeating the entire mechanism.

Third, consider OCSP Must-Staple for high-security applications. Request certificates with the status_request TLS feature extension from your CA (Let’s Encrypt supports this with Certbot’s --must-staple flag). This strengthens your revocation posture but requires robust OCSP staple management — plan for OCSP responder downtime and build monitoring for staple expiry.

Fourth, set up certificate revocation monitoring. If a certificate for your domain is unexpectedly revoked — perhaps by a CA detecting a key compromise — you need to know immediately. Subscribe to CT log alerts (crt.sh or Facebook CT Monitor) and configure server health checks that verify OCSP status. For a deeper understanding of what underpins certificate trust, read Public Key Infrastructure (PKI) Explained and Certificate Transparency: How CT Logs Stop Bad TLS Certs.