SSL Certificate Revocation: CRL and OCSP Explained

When a private key is compromised, an employee leaves and their client certificate should no longer be valid, or a certificate was issued by mistake, that certificate needs to be invalidated before its natural expiration date. This is revocation. The certificate itself cannot be modified (it is a signed document), so revocation works by publishing information that tells clients the certificate should no longer be trusted. The challenge is getting this information to clients reliably and quickly. For background on how certificates and the certificate chain work, see our SSL/TLS guide.

Why Revocation Exists

Certificates have fixed expiration dates, but security incidents don't wait for certificates to expire. Common reasons for revocation include:

Key compromise. If an attacker obtains your private key, they can impersonate your server. The certificate must be revoked immediately so that clients stop trusting it.

CA compromise. If a certificate authority is compromised, all certificates it issued may need to be revoked. This happened with DigiNotar in 2011.

Domain ownership change. If you sell a domain, the previous certificate should be revoked to prevent the old owner (or anyone who obtained the private key) from using it.

Misissued certificates. If a CA issues a certificate incorrectly (wrong domain, wrong organization, policy violation), it must be revoked.

Certificate replacement. When you replace a certificate (new key, new CA, changed subject), revoking the old one is good practice.

Without revocation, a compromised certificate would remain valid and trusted until its expiration date, which could be months or even a year away. Two main mechanisms exist to distribute revocation information: CRLs and OCSP.

CRL (Certificate Revocation List)

A CRL is a signed file published by a certificate authority that lists the serial numbers of all certificates it has revoked. Clients can download the CRL and check whether a certificate's serial number appears on the list.

How CRL Works

Every certificate contains a "CRL Distribution Points" extension that specifies the URL where the CA publishes its CRL. When a client (browser, application, or library) validates a certificate, it can fetch the CRL from that URL and check whether the certificate's serial number is listed.

CRLs are signed by the CA, so clients can verify their authenticity. Each CRL has a "next update" field that tells clients when a new CRL will be published. Clients typically cache CRLs until this date.

Problems with CRLs

CRLs have several significant practical problems.

Size. A CRL contains the serial numbers of every revoked certificate that has not yet expired. For a large CA, this list can be enormous. Let's Encrypt's CRL would contain millions of entries. Downloading multi-megabyte files just to check one certificate is impractical, especially on mobile networks.

Freshness. CRLs are published periodically (every few hours to every few days). A certificate revoked between CRL publications won't appear on the list until the next update. This creates a window where revoked certificates are still trusted.

Availability. If the CRL endpoint is unreachable, the client must decide whether to accept the certificate anyway (soft-fail) or reject it (hard-fail). Most clients soft-fail, which means CRL checking provides no protection during network issues.

Performance. Fetching and parsing a CRL adds latency to the first connection to a server. This is noticeable enough that many clients skip CRL checks entirely.

Because of these problems, CRLs are rarely used by browsers today for real-time revocation checking. They remain relevant for certain enterprise applications and as a baseline mechanism specified in RFC 5280.

OCSP (Online Certificate Status Protocol)

OCSP was designed to address CRL's shortcomings. Instead of downloading an entire list of revoked certificates, the client asks the CA about one specific certificate.

How OCSP Works

The client sends a query to the CA's OCSP responder (the URL is specified in the certificate's "Authority Information Access" extension) containing the serial number of the certificate it wants to check. The OCSP responder returns a signed response indicating whether the certificate is "good," "revoked," or "unknown."

This is much more efficient than downloading an entire CRL. The query and response are small (a few hundred bytes), and the check is for one specific certificate.

OCSP Problems

OCSP solved the size problem but introduced new ones.

Privacy. Every OCSP query tells the CA which website you are visiting. The CA receives a request saying "is the certificate for example.com still valid?" from your IP address. This is a significant privacy concern. CAs can potentially build browsing profiles from OCSP queries.

Latency. Each new TLS connection requires an OCSP query to the CA's responder. This adds a round trip to connection setup. For sites used by millions of users, this creates massive load on OCSP responders.

Availability. If the OCSP responder is down, the client faces the same soft-fail/hard-fail dilemma as with CRLs. Most browsers soft-fail, meaning a down OCSP responder effectively disables revocation checking.

Single point of failure. If a CA's OCSP responder goes down, every website using that CA's certificates is affected. This has happened in practice, causing widespread connection delays.

OCSP Stapling

OCSP stapling is the most widely recommended approach to revocation checking today. It solves the privacy, latency, and availability problems of standard OCSP.

How OCSP Stapling Works

Instead of the client querying the CA's OCSP responder, the server does it. The server periodically fetches its own OCSP response from the CA, then "staples" this signed response to the TLS handshake. The client receives the OCSP response directly from the server, along with the certificate.

This works because OCSP responses are signed by the CA. The server cannot forge a "good" response for a revoked certificate. The CA's signature on the response proves its authenticity regardless of who delivers it.

Benefits of OCSP Stapling

No privacy leak. The client never contacts the CA's OCSP responder, so the CA doesn't know which clients are visiting your site.

No latency penalty. The OCSP response is included in the TLS handshake, so there is no additional round trip.

No CA availability dependency. Even if the CA's OCSP responder goes down temporarily, the server can continue serving a cached OCSP response until it expires (typically 7 days).

Reduced load on OCSP responders. One server fetching one response periodically instead of millions of clients each fetching their own.

OCSP Must-Staple

The "OCSP Must-Staple" certificate extension (technically the "TLS Feature" extension, RFC 7633) tells clients that the server promises to always staple an OCSP response. If the server fails to staple, the client should reject the connection.

This closes the soft-fail loophole. Without Must-Staple, an attacker using a revoked certificate can simply block OCSP traffic, and the client will soft-fail and accept the certificate. With Must-Staple, the missing staple itself causes a hard failure.

You can request OCSP Must-Staple when generating your CSR or through your CA's issuance process. Let's Encrypt supports it.

CRLite: Mozilla's Approach

Mozilla developed CRLite as a different approach to the revocation problem. Instead of checking revocation status at connection time, CRLite compresses the entire set of revoked certificates into a small data structure (a cascade of Bloom filters) that can be shipped to browsers as an update.

How CRLite Works

Mozilla aggregates CRLs and OCSP data from all CAs into a single dataset. This is compressed using Bloom filters into a file of roughly 1-10 MB. The file is pushed to Firefox browsers through the regular update mechanism (Remote Settings). When Firefox encounters a certificate, it checks the local CRLite data without making any network request.

Benefits of CRLite

• No network requests for revocation checking (no privacy leak, no latency).
• Complete coverage of all revoked certificates, not just those where the server staples OCSP.
• No soft-fail problem because the data is always available locally.
• Updates are incremental (small diffs rather than full downloads).

Limitations of CRLite

CRLite data is updated periodically (currently every few hours in Firefox). A certificate revoked between updates won't be blocked until the next push. This is similar to CRL freshness issues but with much shorter update intervals.

CRLite is currently specific to Firefox. Chrome and Safari have not adopted this approach.

Browser Behavior: Soft-Fail vs Hard-Fail

How browsers handle revocation check failures is a critical practical consideration.

Soft-fail means the browser accepts the certificate if it cannot check revocation status (OCSP responder unreachable, CRL unavailable). This is the default behavior for Chrome, Firefox (for OCSP), and Safari. The rationale is that an availability problem at a CA shouldn't prevent users from accessing websites.

Hard-fail means the browser rejects the certificate if revocation status cannot be confirmed. This is more secure but causes usability problems when OCSP responders are unavailable.

In practice, most browsers use soft-fail for most connections. This means that real-time revocation checking (CRL or OCSP) provides limited security against a determined attacker who can block network traffic. The attacker can block OCSP/CRL traffic, and the browser will accept the revoked certificate.

This is why OCSP stapling with Must-Staple and approaches like CRLite are important. They eliminate the soft-fail vulnerability.

How to Check Revocation Status

You can check a certificate's revocation status using several methods.

OpenSSL command line:

# Check OCSP status
openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 5 "OCSP Response"

This shows whether the server is stapling an OCSP response and what the response says.

Online tools like SSL Labs (ssllabs.com), SSL certificate checkers, and DigiCert's certificate checker show revocation status as part of their analysis.

crl.sh and crt.sh can help you look up certificate details, including CRL distribution points and OCSP responder URLs.

For a comprehensive approach to managing your certificates including revocation awareness, see our SSL certificate management strategy.

References

• RFC 6960 - Online Certificate Status Protocol (OCSP)
• RFC 5280 - Internet X.509 PKI Certificate and CRL Profile
• RFC 7633 - X.509v3 TLS Feature Extension (Must-Staple)
• Mozilla - CRLite