OCSP vs CRL: How Certificate Revocation Works

OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List) are the two mechanisms a client can use to check whether a TLS certificate has been revoked before its stated expiry date. A certificate can become untrustworthy long before it expires — the private key might leak, the domain might change ownership — and revocation is how the certificate authority (CA) tells the world “don’t trust this one anymore,” ahead of schedule.

Why revocation exists

Every certificate carries a validity window, but a TLS handshake only checks the certificate’s signature and expiry by default — it doesn’t inherently know if the CA revoked the certificate yesterday. Without a separate revocation check, an attacker holding a compromised private key could keep using a stolen certificate for its full validity period, which is often a year or more. Revocation checking closes that gap by giving clients a way to ask, at connection time, “has this specific certificate been revoked?”

Certificate Revocation Lists (CRL)

A CRL is exactly what it sounds like: a signed, published list of every certificate a CA has revoked, identified by serial number, along with the time and reason for revocation. Clients download the list from a URL embedded in the certificate itself and check whether the certificate they’re validating appears on it.

The problem is scale. As a CA revokes more certificates, the list grows — a large CA’s CRL can run to megabytes. Downloading and parsing that list on every connection is impractical, so clients typically cache it for a period defined by the CA (hours to days) rather than fetching it fresh every time. That caching window is also the CRL’s core weakness: a certificate revoked five minutes ago can still pass validation against a CRL cached six hours ago.

Online Certificate Status Protocol (OCSP)

OCSP was designed to fix CRL’s scaling and freshness problems by making the check specific rather than exhaustive. Instead of downloading an entire list, the client sends the CA’s OCSP responder a single query — “is certificate serial number X still valid?” — and gets back a signed response: good, revoked, or unknown.

This is smaller and faster than downloading a full CRL, but it introduces a different problem: the client now has to make a live network request to the CA’s OCSP responder on every new connection, which adds latency and creates a dependency on that responder’s availability. It’s also a privacy leak — the OCSP responder sees, in real time, which sites a given client is visiting, since the query includes the certificate being checked.

OCSP stapling

OCSP stapling addresses both the latency and privacy problems by moving the query off the client entirely. Instead of the browser querying the CA, the server periodically queries the CA’s OCSP responder itself, caches the signed response, and “staples” it directly onto the TLS handshake it sends to clients. The client gets the freshness benefit of OCSP without making its own network call to the CA, and the CA never learns which clients are connecting to which sites.

Comparison

	CRL	OCSP	OCSP stapling
Data transferred	Full revocation list	Single certificate status	Single status, sent by server
Who contacts the CA	Client	Client	Server, periodically
Client privacy	No leak	CA sees client’s browsing	No leak
Freshness	Limited by cache lifetime	Near real-time	Near real-time
Failure mode	Stale list if fetch fails	Handshake delay or soft-fail if responder is down	Falls back to unstapled OCSP or CRL

Soft-fail: revocation checking’s practical weak spot

In principle, a client that can’t reach the OCSP responder or download the CRL should refuse the connection — “hard-fail.” In practice, most browsers “soft-fail”: if the revocation check can’t complete, they proceed as if the certificate were valid, rather than breaking the connection for what might just be a network blip. This is a deliberate trade-off — an attacker capable of a man-in-the-middle position can often also block the revocation check itself, which would make hard-fail turn a minor availability problem into a way to force connections through as if unrevoked anyway. Soft-fail accepts that revocation checking is a best-effort defense, not an absolute guarantee, and leans on short certificate lifetimes and certificate transparency logs as complementary safeguards.

The takeaway

CRLs and OCSP both answer the same question — has this certificate been revoked — but trade off differently between bandwidth, freshness, and privacy. OCSP stapling is the practical modern default: it gives clients fresh revocation status without a live per-connection query to the CA, and without leaking browsing activity to a third party. None of these mechanisms are airtight against a well-positioned attacker, which is why revocation checking is treated as defense in depth alongside short certificate validity periods rather than a single point of trust.