Certificate Revocation: CRL vs OCSP vs Stapling

Revocation is the part of PKI everyone designs last and nobody tests. Issuing a certificate is easy; un-issuing one — quickly, verifiably, at internet scale — is where most deployments quietly fall apart. This guide walks the three mechanisms in production use and ends with a recommendation you can actually deploy.

Why revocation exists at all

A certificate is a signed promise with an expiry date. Revocation is how you break that promise early — after a key compromise, a mis-issuance, or an employee offboarding. The hard problem is distribution: how does a relying party, anywhere in the world, learn that a still-valid-looking certificate is no longer trustworthy?

Key idea

Every revocation scheme trades off freshness, privacy, and availability. You cannot maximise all three — pick the two that matter for your threat model.

The CRL approach

A Certificate Revocation List is a signed, timestamped file listing the serial numbers the CA has revoked. Clients download it from the CRL Distribution Point named in the certificate. It is simple, cacheable and offline-verifiable — but CRLs grow unbounded, and a client with a stale cached list happily trusts a revoked certificate until the next refresh.

# server_cert extensions in ca.cnf
authorityInfoAccess = OCSP;URI:http://ocsp.certsecure.ch
crlDistributionPoints = URI:http://crl.certsecure.ch/issuing.crl

# sign the request against those extensions
openssl ca -config ca.cnf -extensions server_cert \
  -in request.csr -out server.crt

OCSP, and why it disappoints

The Online Certificate Status Protocol flips the model: instead of downloading the whole list, the client asks the CA about one serial number in real time. Fresher, smaller — but it leaks the client’s browsing to the CA, adds a blocking network round-trip to every handshake, and fails open in most clients when the responder is down. A revocation system that fails open is barely a revocation system.

OCSP stapling fixes most of it

With stapling, the server fetches a signed OCSP response periodically and attaches it to the TLS handshake. The client gets fresh status with no extra round-trip and no privacy leak, and with Must-Staple in the certificate the handshake hard-fails if the staple is missing — closing the fail-open hole.

ssl_stapling            on;
ssl_stapling_verify     on;
ssl_trusted_certificate /etc/ssl/chain.pem;
resolver                1.1.1.1 valid=300s;

What to actually deploy

For public web servers: OCSP stapling with Must-Staple, backed by short-lived certificates so that even a missed revocation ages out fast. For internal PKI where you control every client, short-lived certificates and automated rotation (ACME) beat any revocation scheme — the best way to un-trust a certificate is to have issued one that expires in hours, not years.

Revocation is a safety net, not a plan. Design so you rarely need to pull it.