Certificate Revocation

Imagine discovering that your company's private key has been compromised. It's been leaked on a dark web forum. Attackers could now impersonate your servers, intercept customer data, sign malware with your code signing certificate. Your certificate doesn't expire for another two years. What do you do?

The answer is revocation—formally declaring that a certificate is no longer valid, even though it hasn't expired. In theory, this sounds straightforward. In practice, certificate revocation is one of the hardest problems in PKI—a problem that, despite decades of effort, remains imperfectly solved.

The core challenge: certificates are distributed. When a CA revokes a certificate, how do millions of clients learn about it? Clients can't query the CA for every certificate they encounter—that would create massive traffic and a single point of failure. But without checking, clients might trust a revoked certificate, enabling the very attacks revocation was meant to prevent.

This page examines the revocation mechanisms that exist (CRLs, OCSP, Stapling), their tradeoffs, their failures, and the emerging solutions that may finally address PKI's hardest problem.

Certificates have validity periods (typically 90 days to 2 years for TLS certificates). But many events require invalidating a certificate before expiration:

Revocation Reasons (RFC 5280):

Real-World Revocation Scenarios:

Key Compromise: The most critical case. If an attacker obtains your private key, they can:

• Impersonate your server to any client
• Decrypt recorded traffic (if not using forward secrecy)
• Sign malicious code in your name
• Read encrypted emails intended for you

Examples:

• Heartbleed vulnerability (2014) potentially exposed millions of server private keys
• DigiNotar breach (2011) led to fraudulent certificates for Google
• Code signing key theft has enabled malware distribution

Certificate Mis-issuance: Sometimes CAs issue certificates they shouldn't have:

• Certificate for domain the applicant doesn't control
• Incorrect organization name (fraudulent OV/EV)
• Technical errors in certificate content

Organizational Changes:

• Employee with client certificate leaves company
• Company changes domain names
• Server is decommissioned
• Company is acquired and rebranded

The oldest revocation mechanism is the Certificate Revocation List (CRL)—a signed document containing the serial numbers of all revoked certificates issued by a CA.

How CRLs Work:

1. CA maintains a list of revoked certificate serial numbers
2. CA periodically signs and publishes this list to a distribution point (usually a URL)
3. Clients download the CRL and check if the certificate's serial number is on it
4. If found, the certificate is considered revoked

CRL Structure:

CRL Distribution:

Certificates specify where to find CRLs in the CRL Distribution Points extension:

X509v3 CRL Distribution Points:
    Full Name:
      URI:http://crl.example.com/intermediate.crl

CRL Problems:

Delta CRLs:

To address the size problem, RFC 5280 defines Delta CRLs—CRLs containing only changes since a base CRL:

• Client downloads full base CRL occasionally
• Downloads smaller delta CRLs for updates
• Combines base + deltas for complete picture

In practice, Delta CRLs aren't widely used due to complexity and limited client support.

CRL Caching:

CRLs include nextUpdate field indicating when a fresh CRL should be available. Clients can cache CRLs until this time, reducing bandwidth. But this means revocations may not be visible until the cache expires—a significant security gap.

Online Certificate Status Protocol (OCSP), defined in RFC 6960, addresses CRL's scaling problems by providing real-time, per-certificate status queries.

How OCSP Works:

1. Client encounters a certificate to validate
2. Client sends OCSP request to the responder (URL in certificate's AIA extension)
3. Responder returns signed response: "good", "revoked", or "unknown"
4. Client accepts or rejects based on response

OCSP Request/Response:

OCSP Response Status Values:

OCSP Advantages over CRL:

• Real-time — Query for specific certificate, get current status
• Bandwidth efficient — Request and response are tiny (few KB vs MB)
• Scalable — Only query for certificates you're actually validating
• Fresher data — Responses reflect recent revocations

OCSP Problems:

OCSP Stapling (technically, the TLS Certificate Status Request extension, RFC 6066) addresses many OCSP problems by having the server provide the OCSP response.

How Stapling Works:

1. Server periodically fetches OCSP response from the responder
2. Server caches this signed response
3. During TLS handshake, server "staples" the OCSP response to the certificate
4. Client validates the OCSP response alongside the certificate

Benefits:

OCSP Must-Staple:

To address the soft-fail problem, certificates can include the OCSP Must-Staple extension (RFC 7633). This extension indicates:

• If the server supports stapling, it MUST staple a valid OCSP response
• If no valid stapled response is present, clients MUST reject the connection

This converts soft-fail to hard-fail for servers that opt-in:

X509v3 TLS Feature: 
    status_request   (OCSP Must-Staple)

Must-Staple Tradeoffs:

Despite the mechanisms available, what do browsers actually do to check revocation? The answer may surprise you—and depress you if you care about security.

Chrome (Most Used Browser):

CRLSets:

Google's CRLSet is a curated, compressed set of revoked certificates that Chrome considers particularly important (compromised CAs, high-profile incidents). It's:

• Pushed via Chrome updates (can happen within hours)
• Tiny compared to actual CRLs (~250KB vs many MB)
• Incomplete (only covers priority certificates)

Firefox:

Safari:

Given the limitations of current revocation mechanisms, researchers and practitioners have developed alternative approaches.

Short-Lived Certificates:

The most radical solution: make revocation unnecessary by having certificates that expire quickly.

• Concept: Issue certificates valid for hours or days, not months or years
• Example: Let's Encrypt issues 90-day certificates; some proposals suggest 24-hour validity
• Advantage: Compromised key loses value quickly without any revocation infrastructure
• Challenge: Requires reliable automation; any failure causes immediate outage

CRLite (Mozilla Research):

CRLite compresses the entire global CRL (all revoked certificates from all CAs) into a compact data structure:

• Uses Bloom filters and cascading filters
• Entire revocation dataset compressed to ~10MB
• Pushed to Firefox clients via updates
• Enables complete revocation checking without OCSP queries
• Currently experimental in Firefox

Certificate Transparency Log Monitoring:

CT logs provide another avenue for revocation-adjacent functionality:

• Log operators can flag certificates as revoked
• Some proposals use CT logs to distribute revocation information
• Site owners can monitor logs for unauthorized certificates

Expect-CT and CT Enforcement:

While not revocation per se, Certificate Transparency makes mis-issuance detectable:

• All certificates must be logged to CT logs
• Browsers reject certificates without valid SCTs (Signed Certificate Timestamps)
• Mis-issued certificates become publicly visible, enabling faster response

When you need to revoke a certificate, here's how to do it properly:

Step 1: Revoke Through Your CA

Each CA has a different revocation process:

Step 2: Verify Revocation

Confirm the certificate is actually revoked:

Step 3: Replace the Certificate

1. Generate new private key (don't reuse compromised key!)
2. Create new CSR
3. Submit to CA for new certificate
4. Deploy new certificate
5. Verify new certificate is working

Step 4: Investigate and Remediate

• Determine how the compromise occurred
• Fix the underlying vulnerability
• Audit for unauthorized use of the revoked certificate
• Consider notifying affected parties if data may have been compromised