A public key infrastructure is only as trustworthy as its ability to say “this key is no longer valid.” Keys get stolen, employees leave companies, certificate authorities make mistakes, and private keys get accidentally published to GitHub more often than anyone would like to admit. When any of that happens, the entire system depends on a mechanism to revoke trust quickly and reliably. This article explains key revocation from first principles — why it exists, how Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) work internally, the mathematics and data structures behind them, the attacks that have exploited their weaknesses, and the modern practices (like OCSP stapling and short-lived certificates) that have emerged to fix those weaknesses.
Why Key Revocation Exists
In any Public Key Infrastructure (PKI), a Certificate Authority (CA) issues a digital certificate binding a public key to an identity, valid for a defined period, e.g.:
$$ \text{Cert} = { \text{Subject}, ; PK_{\text{subject}}, ; \text{Validity Period}, ; \text{Issuer}, ; Sig_{CA}(\ldots) } $$
The certificate’s validity period might be one to two years. But real-world events can invalidate a key long before its natural expiration:
- The private key is stolen or leaked.
- An employee holding a code-signing key leaves the organization.
- The CA discovers it issued a certificate in error (e.g., domain validation was bypassed).
- The organization is compromised (e.g., the DigiNotar breach of 2011).
- A cryptographic weakness is discovered in the algorithm used.
Without revocation, an attacker who steals a private key could impersonate the victim for the remainder of the certificate’s lifetime — potentially years. Revocation gives the ecosystem a way to shorten that exposure window from “years” to “hours.”
The Core Problem: How Does a Relying Party Know a Key Is Revoked?
When a browser (the “relying party”) receives a certificate during a TLS handshake, it must answer one question: is this certificate still trustworthy right now? There are three broad approaches, each with different trade-offs:
- Certificate Revocation Lists (CRL) — a periodically published, signed list of all revoked certificate serial numbers.
- Online Certificate Status Protocol (OCSP) — a real-time query-response protocol asking the CA directly about one certificate.
- OCSP Stapling / Short-lived certificates — newer approaches designed to avoid the weaknesses of both CRL and classic OCSP.
Certificate Revocation Lists (CRL)
A CRL is defined in RFC 5280 as a time-stamped, digitally signed list issued by a CA (or a delegated CRL issuer) that enumerates every certificate serial number that has been revoked and not yet expired.
CRL Structure
A CRL contains:
| Field | Description |
|---|---|
| Version | CRL format version (usually v2) |
| Signature Algorithm | Algorithm used by the CA to sign the CRL |
| Issuer | Distinguished Name of the issuing CA |
| This Update | Timestamp of CRL issuance |
| Next Update | Timestamp of the next scheduled CRL |
| Revoked Certificate List | Serial number + revocation date + reason code, repeated for each revoked cert |
| CRL Extensions | e.g., CRL number, delta CRL indicator |
| CA Signature | Digital signature over the entire list |
Each entry in the revoked list typically includes a reason code, standardized values including: keyCompromise, caCompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, and privilegeWithdrawn.
How a Client Verifies a CRL
- Download the CRL from the distribution point URL embedded in the certificate’s
CRL Distribution Pointsextension. - Verify the CA’s signature over the CRL:
$$ \text{Verify}(PK_{CA}, \text{CRL_data}, Sig_{CA}(\text{CRL_data})) \stackrel{?}{=} \text{valid} $$
- Check that the current time falls between
thisUpdateandnextUpdate. - Search the list for the certificate’s serial number. If found, the certificate is revoked; if the
nextUpdatehas passed without a fresh CRL, clients typically treat the certificate status as unknown or stale, depending on policy.
Delta CRLs
Because a full CRL can grow to include tens of thousands of entries for a large CA, RFC 5280 also defines Delta CRLs — smaller, incremental lists containing only the changes since the last full CRL, referenced via a “Base CRL Number” extension. This dramatically reduces bandwidth for clients that already cache the last full CRL.
Weaknesses of CRLs
- Staleness: CRLs are only as fresh as their publication schedule (commonly 24 hours to 7 days), so a revoked key can remain “valid” in a client’s eyes until the next CRL refresh.
- Size and bandwidth: Large CAs can have CRLs with hundreds of thousands of entries, becoming multi-megabyte downloads that many clients skip entirely for performance reasons.
- Fail-open behavior: Many clients, historically, would silently proceed with the connection (“soft-fail”) if the CRL couldn’t be downloaded — turning revocation checking into pure theater during network outages or denial-of-service attacks against the CRL distribution point.
Online Certificate Status Protocol (OCSP)
OCSP, defined in RFC 6960, was designed to solve CRL’s staleness and bandwidth problem by letting a client ask a real-time question about a single certificate instead of downloading an entire list.
OCSP Request/Response Flow
Client OCSP Responder
|------ OCSPRequest -------------->|
| (CertID: hash of issuer info |
| + certificate serial number) |
| |
|<----- OCSPResponse --------------|
| (status: good / revoked / |
| unknown, signed by responder) |
The CertID sent in the request is computed as a hash, not the raw certificate, to protect a small amount of privacy and reduce bandwidth:
$$ \text{CertID} = { \text{hashAlgorithm}, ; \text{Hash}(\text{Issuer Name}), ; \text{Hash}(\text{Issuer Public Key}), ; \text{Serial Number} } $$
The response includes a status of good, revoked (with reason and revocation time), or unknown, along with a thisUpdate/nextUpdate validity window and a digital signature — either from the CA itself or a delegated OCSP Responder whose authority is itself certified by the CA.
Verifying an OCSP Response
- Confirm the response is signed by a key the client trusts (the CA, or a properly delegated OCSP responder certificate signed by the CA).
- Confirm
thisUpdate≤ current time ≤nextUpdateto avoid replay of stale “good” responses. - Match the
CertIDin the response to the certificate being validated.
Weaknesses of OCSP
- Privacy leakage: every time a user visits a site, their browser may contact the CA’s OCSP responder, letting the CA (or anyone eavesdropping on that unencrypted request) build a browsing history.
- Latency: adds a network round-trip to every TLS handshake unless cached or stapled.
- Availability dependency: if the OCSP responder is down, clients again face the fail-open vs. fail-closed dilemma — soft-fail keeps sites working during outages but defeats the purpose of revocation checking; hard-fail is more secure but risks widespread outages if the OCSP infrastructure has issues.
- Replay attacks on “good” responses: an attacker who captured a valid “good” OCSP response before a key was compromised could, in theory, replay that response within its validity window to make a revoked key look trusted — one reason
nextUpdatewindows are usually kept short (hours, not days).
OCSP Stapling: Fixing Privacy and Latency
OCSP Stapling (formally, the TLS Certificate Status Request extension, defined in RFC 6066 and refined by RFC 6961) flips the responsibility: instead of the client querying the OCSP responder, the web server periodically fetches its own OCSP response and “staples” it directly into the TLS handshake.
Server (periodically, e.g. every hour):
OCSP response = query_CA_OCSP(own_certificate)
cache(OCSP response)
Client TLS Handshake:
Server -> Client: Certificate + stapled OCSP response (pre-fetched, signed by CA)
Client verifies signature and freshness locally — no separate network call needed
Benefits:
- No privacy leak: the CA never learns which clients are visiting which sites, since the server does all OCSP querying itself.
- No added client latency: the OCSP response arrives in the same handshake, with no extra round trip.
- Better availability: if the OCSP responder is briefly unreachable, the server can continue serving its last valid cached response until it expires.
Must-Staple (an X.509 certificate extension, RFC 7633) lets a certificate holder assert that clients must reject the connection if no valid stapled response is present, closing the soft-fail loophole entirely for that certificate.
CRL vs. OCSP vs. OCSP Stapling
| Property | CRL | OCSP | OCSP Stapling |
|---|---|---|---|
| Granularity | Entire list of revoked certs | Single certificate status | Single certificate status |
| Freshness | Hours to days (per publish schedule) | Real-time (per request) | As fresh as server’s cache (minutes to hours) |
| Bandwidth cost | High (large list) | Low per request | Low, embedded in handshake |
| Added latency | One-time download, then cached | Extra round trip per handshake (unless client-cached) | None (embedded in handshake) |
| Privacy | Good (no per-visit contact with CA) | Poor (CA can log every visitor) | Good (server queries CA, not client) |
| Availability risk | CA’s CRL server can be DoS’d | OCSP responder can be DoS’d | Server absorbs risk, more resilient |
| Fail-open risk | Common in practice | Common in practice | Reduced with Must-Staple |
Key Compromise vs. Certificate Revocation
It’s worth distinguishing key revocation conceptually from certificate revocation mechanically. The underlying cryptographic event is the compromise, loss, or retirement of a private key. Certificate revocation is the mechanism PKI uses to communicate that event to relying parties. In symmetric-key systems (e.g., enterprise key management, HSM-based systems), “key revocation” instead usually means:
- Marking the key as deactivated in a key management system (KMS) so it can no longer be used for new encryption or signing operations.
- Optionally re-encrypting data that was protected under the compromised key with a new key (key rotation).
- Logging and alerting on any further attempted use of the revoked key identifier.
Short-Lived Certificates: The Alternative to Revocation
An increasingly popular strategy — used heavily by Let’s Encrypt-style automation and internal service meshes — is to sidestep revocation machinery almost entirely by issuing certificates with very short lifetimes (hours to a few days) instead of years. If a key is compromised, the exposure window is naturally bounded by the short expiration, reducing dependence on CRL/OCSP infrastructure. This trades increased renewal automation complexity for a simpler trust model.
Real-World Attacks and Failures Involving Revocation
- DigiNotar (2011): after this Dutch CA was compromised and issued fraudulent certificates (including for
*.google.com), the incident exposed how slowly browser vendors could react — ultimately requiring an emergency, out-of-band distrust of the entire CA rather than relying on revocation alone, since attackers can also forge or suppress revocation status. - Heartbleed (2014): this OpenSSL vulnerability leaked private keys from memory, forcing a mass wave of certificate revocations across the web — and exposing just how overloaded CRL and OCSP infrastructure became under sudden, large-scale revocation events.
- OCSP soft-fail exploitation: security researchers have repeatedly demonstrated that an active man-in-the-middle attacker can simply block OCSP responses, causing browsers configured to “soft-fail” to treat a revoked (and attacker-controlled) certificate as valid.
Best Practices for Key and Certificate Revocation
- Prefer OCSP stapling with Must-Staple over classic client-side OCSP or CRL-only validation.
- Automate certificate issuance and renewal (e.g., via ACME/Let’s Encrypt) to make shorter certificate lifetimes operationally practical.
- Monitor Certificate Transparency (CT) logs to detect certificates issued for your domain that you didn’t request.
- Design for fail-closed in high-security contexts (e.g., internal PKI for financial systems) even though it sacrifices some availability, since silently trusting a possibly-revoked key is often worse than an outage.
- Rotate and revoke immediately upon any suspicion of compromise — don’t wait for confirmation; the cost of unnecessary rotation is far lower than the cost of a real compromise going unaddressed.
- Use Hardware Security Modules (HSMs) for high-value keys so that theft of the key material itself becomes far less likely in the first place, reducing how often revocation is needed at all.
Common Mistakes
- Relying solely on client-side OCSP without stapling, leaking browsing history to CAs.
- Treating “soft-fail” revocation checking as meaningful security rather than best-effort hygiene.
- Forgetting to revoke intermediate CA certificates when an intermediate is compromised, leaving every certificate it issued still nominally “trusted” from a chain-validation perspective.
- Publishing CRLs infrequently for high-value certificates, creating long windows of exposure.
- Not testing what happens when the revocation infrastructure itself is unreachable.
Frequently Asked Questions
Is OCSP always faster than CRL? For a single certificate check, yes — OCSP avoids downloading a potentially huge list. But OCSP adds a network round trip per handshake unless the response is cached or stapled, so under high load, a well-cached CRL can sometimes outperform live OCSP queries.
Why do browsers sometimes ignore revocation checks entirely? Because of availability and privacy concerns, several major browsers historically disabled or de-prioritized full revocation checking for ordinary certificates, relying instead on their own centrally distributed “kill lists” (like Chrome’s CRLSet or Firefox’s OneCRL) for the most critical mass-revocation events.
Can a revoked certificate still be used to verify old signatures? It depends on policy. For code signing and document signing, a “revoked” status is sometimes paired with a certificateHold state or timestamp-based validation, allowing signatures made before the compromise date to remain valid — an important nuance for long-term document signatures.
What is Certificate Transparency, and how does it relate to revocation? Certificate Transparency (RFC 6962) is a public, append-only log of issued certificates. It doesn’t itself revoke anything, but it lets domain owners and researchers detect fraudulently issued certificates quickly, often triggering a manual revocation request.
Summary
Key revocation exists because private keys don’t always remain private for as long as their certificates say they should. Certificate Revocation Lists provide a simple, auditable, but potentially stale mechanism for broadcasting revoked serial numbers, while OCSP offers real-time status checks at the cost of privacy, latency, and availability concerns. OCSP Stapling, especially combined with Must-Staple, resolves most of these trade-offs by shifting the query burden onto the certificate holder’s own server. Increasingly, short-lived certificates and automated renewal are reducing the entire ecosystem’s reliance on revocation machinery altogether. A resilient PKI deployment typically layers several of these mechanisms together, rather than depending on any single one.
References
- RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF.
- RFC 6960 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, IETF.
- RFC 6066 — Transport Layer Security (TLS) Extensions: Extension Definitions (Certificate Status Request).
- RFC 6961 — Multiple Certificate Status Request Extension, IETF.
- RFC 7633 — X.509v3 Transport Layer Security (TLS) Feature Extension (OCSP Must-Staple).
- RFC 6962 — Certificate Transparency, IETF.
- NIST Special Publication 800-57 — Recommendation for Key Management.
- Adkins, H. et al. — An Update on Attempted Man-in-the-Middle Attacks, Google Security Blog (relating to DigiNotar).
