Computer NetworksNetwork Security Protocols

Certificates and PKI

LevelIntermediate

Duration90 mins

TopicNetwork Security Protocols

4 / 5

Certificate Revocation

The Unsolved Problem of PKI

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.

What You Will Master

By the end of this page, you will understand why revocation is hard, how CRLs and OCSP work, the problems with each approach, how OCSP Stapling addresses some issues, what browsers actually do (or don't do) about revocation, and emerging solutions like short-lived certificates.

Why Revocation Is Necessary

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):

Certificate Revocation Reasons
Reason Code	Name	Description
0	unspecified	No specific reason given
1	keyCompromise	Private key has been compromised or disclosed
2	caCompromise	Issuing CA's key has been compromised
3	affiliationChanged	Subject's affiliation has changed (e.g., employee left)
4	superseded	Certificate replaced with a newer one
5	cessationOfOperation	Certificate subject no longer operates
6	certificateHold	Temporary hold (can be removed later)
8	removeFromCRL	Remove previously held certificate from CRL
9	privilegeWithdrawn	Subject's privileges have been withdrawn
10	aaCompromise	Attribute Authority compromised

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 Time Problem

From the moment a key is compromised until all clients learn of the revocation, a window of vulnerability exists. Attackers can exploit this window. The goal of revocation systems is to minimize this window—but none of them can eliminate it entirely.

Certificate Revocation Lists (CRL)

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:

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

CRL Structure:

crl-structure.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CertificateList  ::=  SEQUENCE  {
    tbsCertList          TBSCertList,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING
}
 
TBSCertList  ::=  SEQUENCE  {
    version                 Version OPTIONAL,      -- v2 if extensions present
    signature               AlgorithmIdentifier,
    issuer                  Name,                  -- CA that issued this CRL
    thisUpdate              Time,                  -- When CRL was issued
    nextUpdate              Time OPTIONAL,         -- When next CRL expected
    revokedCertificates     SEQUENCE OF SEQUENCE  {
        userCertificate         CertificateSerialNumber,
        revocationDate          Time,
        crlEntryExtensions      Extensions OPTIONAL  -- Revocation reason, etc.
    } OPTIONAL,
    crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
}
 
# Example CRL entry:
# Serial Number: 04:65:d5:40:6c:e7:78:94:4e:8b
# Revocation Date: Jan 15 12:00:00 2024 UTC
# Reason: keyCompromise (1)

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:

CRL Limitations

•Size — CRLs grow with every revoked certificate. Large CAs may have CRLs of several megabytes, containing millions of entries
•Latency — CRLs are only updated periodically (hours to days). Revocations aren't immediately visible
•Bandwidth — Every client must download the entire CRL, even for a single certificate check
•Availability — If the CRL distribution point is down, clients must choose: fail (breaking connections) or continue (accepting potentially revoked certs)
•Privacy — CRL downloads reveal which CAs (and potentially which sites) the client is visiting

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.

CRLs in Practice

Despite their limitations, CRLs remain available as a fallback. Many enterprise environments still use CRLs for internal PKI. For public web PKI, OCSP has largely replaced CRL checking, but CRL URLs are still included in certificates.

Online Certificate Status Protocol (OCSP)

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:

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

OCSP Request/Response:

ocsp-request.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Extract OCSP responder URL from certificate
openssl x509 -in cert.pem -noout -ocsp_uri
# Output: http://r3.o.lencr.org
 
# Get the issuer certificate (needed for OCSP)
openssl x509 -in cert.pem -noout -issuer
# Issuer: CN = R3, O = Let's Encrypt, C = US
 
# Make an OCSP request
openssl ocsp -issuer intermediate.pem \
             -cert server.pem \
             -url http://r3.o.lencr.org \
             -resp_text -noverify
 
# Response structure:
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = R3
    Produced At: Jan 17 10:00:00 2024 UTC
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 48DAC9A0...
      Issuer Key Hash: 142EB317...
      Serial Number: 0465D5406CE778944E8B...
    Cert Status: good
    This Update: Jan 17 10:00:00 2024 UTC
    Next Update: Jan 24 10:00:00 2024 UTC

OCSP Response Status Values:

OCSP Certificate Status
Status	Meaning	Client Action
good	Certificate is not revoked	Accept the certificate
revoked	Certificate has been revoked (includes date and reason)	Reject the certificate
unknown	Responder doesn't know about this certificate	Typically treat as 'good' or try alternate method

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 Limitations

•Latency — Every new connection requires an OCSP query, adding round-trip time
•Availability dependency — If OCSP responder is down, validation can't complete
•Privacy — CA learns every site you visit (OCSP queries reveal visited domains)
•Soft-Fail — Most clients 'soft-fail' if OCSP unreachable (treat as 'good'), defeating the purpose
•Attack surface — Attackers can block OCSP traffic, forcing soft-fail

The Soft-Fail Problem

When browsers can't reach the OCSP responder, they typically accept the certificate anyway ('soft-fail'). This means an attacker who controls the network can block OCSP queries and use a revoked certificate. The alternative, 'hard-fail', would break internet access whenever a CA's OCSP server is slow or unreachable—unacceptable for user experience.

OCSP Stapling: The Better Way

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:

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

Benefits:

OCSP Stapling Advantages

•No latency penalty — OCSP response comes with the certificate; no extra round trip
•Privacy preserved — Client doesn't contact CA; CA doesn't learn browsing habits
•Reliability — Server can cache responses; temporary OCSP outages don't affect clients
•Reduced CA load — One OCSP query per certificate refresh, not per client connection
•Works with CDNs — Edge servers can staple; client doesn't need to reach CA

nginx-ocsp-stapling.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Nginx OCSP stapling configuration
 
server {
    listen 443 ssl http2;
    server_name example.com;
 
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
 
    # Enable OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
 
    # Certificate chain for stapling verification
    ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
 
    # Resolver for OCSP responder lookup
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 10s;
}
 
# Apache OCSP stapling configuration
<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem
    SSLCertificateChainFile /path/to/chain.pem
 
    # Enable stapling
    SSLUseStapling On
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"
    SSLStaplingResponseMaxAge 86400
</VirtualHost>
 
# Verify stapling is working
openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 3 "OCSP Response"
# Should show: OCSP Response Status: successful

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:

Must-Staple Advantages

•Revoked certificates reliably blocked
•Attackers can't exploit soft-fail
•Clear security guarantee

Must-Staple Risks

•Server misconfiguration causes outages
•OCSP fetch failures break the site
•Requires careful operational practice

Stapling Best Practice

Enable OCSP stapling on all production servers. It improves connection latency, protects user privacy, and reduces load on CA infrastructure. Monitor stapling status—a server that stops stapling may indicate OCSP fetch issues that should be investigated.

What Browsers Actually Do About Revocation

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):

•Doesn't check CRLs — Too large, too slow
•Doesn't check OCSP by default — Latency, privacy concerns
•Uses CRLSets — Google-curated list of critical revocations, pushed via browser updates
•Checks stapled OCSP — If server provides, Chrome validates
•Hard-fails on Must-Staple — Respects the extension

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:

•OCSP by default — Sends OCSP queries (soft-fail if responder unreachable)
•OneCRL — Mozilla's equivalent of CRLSets for critical revocations
•CRLite (experimental) — Compressed representation of all unexpired revocations
•Respects stapling — Uses stapled responses when provided

Safari:

•OCSP by default — Apple infrastructure handles queries
•Aggressive pushing — Apple can push revocation data via system updates
•Platform integration — Tight control enables coordinated response

The Uncomfortable Truth

Most revocations are never effectively communicated to most clients. Chrome protects against high-profile incidents via CRLSets but ignores routine revocations. Firefox's soft-fail OCSP provides partial protection. The practical impact: if a certificate is revoked, don't assume clients will notice—especially quickly.

Browser Revocation Checking Summary
Browser	OCSP (Live)	Stapled OCSP	Must-Staple	CRL/CRLSet	Soft-Fail
Chrome	❌ Off by default	✅ Validates	✅ Hard-fail	CRLSets only	N/A (no check)
Firefox	✅ On by default	✅ Validates	✅ Hard-fail	OneCRL + CRLite	Yes (soft-fail)
Safari	✅ On by default	✅ Validates	✅ Hard-fail	Apple push	Yes (soft-fail)
Edge (Chromium)	❌ Off by default	✅ Validates	✅ Hard-fail	CRLSets	N/A (no check)

Emerging Solutions to the Revocation Problem

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

Validity Period and Revocation Window
Validity	Maximum Exposure	Automation Requirement
2 years	Up to 2 years	Manual renewal acceptable
1 year	Up to 1 year	Calendar reminders work
90 days	Up to 90 days	Automation strongly recommended
7 days	Up to 7 days	Automation mandatory
24 hours	Up to 24 hours	Continuous automation required

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

The Short-Lived Future

The industry is moving toward shorter certificate lifespans. Apple and Google have pushed for 1-year (now 398-day) maximum validity. Future proposals may further reduce this. The endpoint of this trend: certificates so short-lived that revocation becomes unnecessary.

Revoking Certificates in Practice

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:

revocation-commands.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# Let's Encrypt revocation via certbot
certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem \
    --reason keyCompromise
 
# Let's Encrypt revocation using the private key (if you still have it)
certbot revoke --cert-path /path/to/cert.pem \
    --key-path /path/to/privkey.pem
 
# Let's Encrypt revocation using account credentials
# (proves you're the certificate owner)
certbot revoke --cert-path /path/to/cert.pem
 
# Commercial CA revocation: typically via web portal
# 1. Log into CA's certificate management portal
# 2. Find the certificate to revoke
# 3. Select revocation reason
# 4. Confirm revocation
# 5. CA updates CRL and OCSP responder
 
# Enterprise/Internal CA using OpenSSL
openssl ca -config /etc/ssl/openssl.cnf \
    -revoke /path/to/cert.pem \
    -crl_reason keyCompromise
 
# Regenerate CRL after revocation
openssl ca -config /etc/ssl/openssl.cnf \
    -gencrl -out /path/to/crl.pem

Step 2: Verify Revocation

Confirm the certificate is actually revoked:

verify-revocation.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Check OCSP status
openssl ocsp -issuer intermediate.pem \
    -cert revoked-cert.pem \
    -url http://ocsp.example.com \
    -resp_text
 
# Expected output for revoked cert:
# Cert Status: revoked
# Revocation Time: Jan 17 15:30:00 2024 UTC
# Revocation Reason: keyCompromise (1)
 
# Check if cert appears in CRL
openssl crl -in crl.pem -noout -text | grep -A1 "Serial Number"
 
# Verify certificate against CRL
openssl verify -crl_check -CAfile ca-bundle.pem \
    -CRLfile crl.pem revoked-cert.pem
# Should fail: certificate revoked

Step 3: Replace the Certificate

Generate new private key (don't reuse compromised key!)
Create new CSR
Submit to CA for new certificate
Deploy new certificate
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

Revocation Delays

Remember: revocation propagation takes time. CRLs may have nextUpdate hours or days away. OCSP responses may be cached. CRLSets update with browser releases. Even after successful revocation through your CA, some clients may continue trusting the certificate for a period. Plan accordingly for high-security incidents.

Summary: Certificate Revocation Mastered

Certificate revocation is PKI's hardest problem—and one without a perfect solution. Let's consolidate what we've learned:

Key Takeaways

•Revocation is necessary for security — Key compromise, mis-issuance, and organizational changes all require invalidating certificates before expiration
•CRLs are comprehensive but unwieldy — Complete lists of all revocations, but too large for per-connection checking
•OCSP provides real-time status — Per-certificate queries, but adds latency and reveals browsing to CAs
•OCSP Stapling solves many problems — Server provides response, eliminating latency and privacy concerns
•Browsers mostly soft-fail — Practical reality is most revocations go unchecked; only high-profile ones get special treatment
•Short-lived certificates are the future — Making revocation unnecessary through fast expiration

What's Next:

We've now explored individual PKI components: certificates, CAs, trust chains, and revocation. The final page brings it all together: PKI Infrastructure—how all these pieces combine into functioning systems, from web PKI to enterprise deployments to specialized environments.

Page Complete

You now understand certificate revocation deeply: CRLs, OCSP, stapling, browser behavior, and emerging solutions. This knowledge is essential for incident response, understanding PKI limitations, and making informed security decisions. Next, we explore the complete PKI infrastructure ecosystem.

4 / 5

Loading learning content...

Computer NetworksNetwork Security Protocols

Certificates and PKI

LevelIntermediate

Duration90 mins

TopicNetwork Security Protocols

4 / 5

Certificate Revocation

The Unsolved Problem of PKI

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.

What You Will Master

Why Revocation Is Necessary

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):

Certificate Revocation Reasons
Reason Code	Name	Description
0	unspecified	No specific reason given
1	keyCompromise	Private key has been compromised or disclosed
2	caCompromise	Issuing CA's key has been compromised
3	affiliationChanged	Subject's affiliation has changed (e.g., employee left)
4	superseded	Certificate replaced with a newer one
5	cessationOfOperation	Certificate subject no longer operates
6	certificateHold	Temporary hold (can be removed later)
8	removeFromCRL	Remove previously held certificate from CRL
9	privilegeWithdrawn	Subject's privileges have been withdrawn
10	aaCompromise	Attribute Authority compromised

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 Time Problem

Certificate Revocation Lists (CRL)

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:

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

CRL Structure:

crl-structure.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CertificateList  ::=  SEQUENCE  {
    tbsCertList          TBSCertList,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING
}
 
TBSCertList  ::=  SEQUENCE  {
    version                 Version OPTIONAL,      -- v2 if extensions present
    signature               AlgorithmIdentifier,
    issuer                  Name,                  -- CA that issued this CRL
    thisUpdate              Time,                  -- When CRL was issued
    nextUpdate              Time OPTIONAL,         -- When next CRL expected
    revokedCertificates     SEQUENCE OF SEQUENCE  {
        userCertificate         CertificateSerialNumber,
        revocationDate          Time,
        crlEntryExtensions      Extensions OPTIONAL  -- Revocation reason, etc.
    } OPTIONAL,
    crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
}
 
# Example CRL entry:
# Serial Number: 04:65:d5:40:6c:e7:78:94:4e:8b
# Revocation Date: Jan 15 12:00:00 2024 UTC
# Reason: keyCompromise (1)

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:

CRL Limitations

•Size — CRLs grow with every revoked certificate. Large CAs may have CRLs of several megabytes, containing millions of entries
•Latency — CRLs are only updated periodically (hours to days). Revocations aren't immediately visible
•Bandwidth — Every client must download the entire CRL, even for a single certificate check
•Availability — If the CRL distribution point is down, clients must choose: fail (breaking connections) or continue (accepting potentially revoked certs)
•Privacy — CRL downloads reveal which CAs (and potentially which sites) the client is visiting

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 in Practice

Online Certificate Status Protocol (OCSP)

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:

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

OCSP Request/Response:

ocsp-request.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Extract OCSP responder URL from certificate
openssl x509 -in cert.pem -noout -ocsp_uri
# Output: http://r3.o.lencr.org
 
# Get the issuer certificate (needed for OCSP)
openssl x509 -in cert.pem -noout -issuer
# Issuer: CN = R3, O = Let's Encrypt, C = US
 
# Make an OCSP request
openssl ocsp -issuer intermediate.pem \
             -cert server.pem \
             -url http://r3.o.lencr.org \
             -resp_text -noverify
 
# Response structure:
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = R3
    Produced At: Jan 17 10:00:00 2024 UTC
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 48DAC9A0...
      Issuer Key Hash: 142EB317...
      Serial Number: 0465D5406CE778944E8B...
    Cert Status: good
    This Update: Jan 17 10:00:00 2024 UTC
    Next Update: Jan 24 10:00:00 2024 UTC

OCSP Response Status Values:

OCSP Certificate Status
Status	Meaning	Client Action
good	Certificate is not revoked	Accept the certificate
revoked	Certificate has been revoked (includes date and reason)	Reject the certificate
unknown	Responder doesn't know about this certificate	Typically treat as 'good' or try alternate method

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 Limitations

•Latency — Every new connection requires an OCSP query, adding round-trip time
•Availability dependency — If OCSP responder is down, validation can't complete
•Privacy — CA learns every site you visit (OCSP queries reveal visited domains)
•Soft-Fail — Most clients 'soft-fail' if OCSP unreachable (treat as 'good'), defeating the purpose
•Attack surface — Attackers can block OCSP traffic, forcing soft-fail

The Soft-Fail Problem

OCSP Stapling: The Better Way

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:

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

Benefits:

OCSP Stapling Advantages

•No latency penalty — OCSP response comes with the certificate; no extra round trip
•Privacy preserved — Client doesn't contact CA; CA doesn't learn browsing habits
•Reliability — Server can cache responses; temporary OCSP outages don't affect clients
•Reduced CA load — One OCSP query per certificate refresh, not per client connection
•Works with CDNs — Edge servers can staple; client doesn't need to reach CA

nginx-ocsp-stapling.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Nginx OCSP stapling configuration
 
server {
    listen 443 ssl http2;
    server_name example.com;
 
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
 
    # Enable OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
 
    # Certificate chain for stapling verification
    ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
 
    # Resolver for OCSP responder lookup
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 10s;
}
 
# Apache OCSP stapling configuration
<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem
    SSLCertificateChainFile /path/to/chain.pem
 
    # Enable stapling
    SSLUseStapling On
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"
    SSLStaplingResponseMaxAge 86400
</VirtualHost>
 
# Verify stapling is working
openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 3 "OCSP Response"
# Should show: OCSP Response Status: successful

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:

Must-Staple Advantages

•Revoked certificates reliably blocked
•Attackers can't exploit soft-fail
•Clear security guarantee

Must-Staple Risks

•Server misconfiguration causes outages
•OCSP fetch failures break the site
•Requires careful operational practice

Stapling Best Practice

What Browsers Actually Do About Revocation

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):

•Doesn't check CRLs — Too large, too slow
•Doesn't check OCSP by default — Latency, privacy concerns
•Uses CRLSets — Google-curated list of critical revocations, pushed via browser updates
•Checks stapled OCSP — If server provides, Chrome validates
•Hard-fails on Must-Staple — Respects the extension

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:

•OCSP by default — Sends OCSP queries (soft-fail if responder unreachable)
•OneCRL — Mozilla's equivalent of CRLSets for critical revocations
•CRLite (experimental) — Compressed representation of all unexpired revocations
•Respects stapling — Uses stapled responses when provided

Safari:

•OCSP by default — Apple infrastructure handles queries
•Aggressive pushing — Apple can push revocation data via system updates
•Platform integration — Tight control enables coordinated response

The Uncomfortable Truth

Browser Revocation Checking Summary
Browser	OCSP (Live)	Stapled OCSP	Must-Staple	CRL/CRLSet	Soft-Fail
Chrome	❌ Off by default	✅ Validates	✅ Hard-fail	CRLSets only	N/A (no check)
Firefox	✅ On by default	✅ Validates	✅ Hard-fail	OneCRL + CRLite	Yes (soft-fail)
Safari	✅ On by default	✅ Validates	✅ Hard-fail	Apple push	Yes (soft-fail)
Edge (Chromium)	❌ Off by default	✅ Validates	✅ Hard-fail	CRLSets	N/A (no check)

Emerging Solutions to the Revocation Problem

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

Validity Period and Revocation Window
Validity	Maximum Exposure	Automation Requirement
2 years	Up to 2 years	Manual renewal acceptable
1 year	Up to 1 year	Calendar reminders work
90 days	Up to 90 days	Automation strongly recommended
7 days	Up to 7 days	Automation mandatory
24 hours	Up to 24 hours	Continuous automation required

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

The Short-Lived Future

Revoking Certificates in Practice

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:

revocation-commands.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# Let's Encrypt revocation via certbot
certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem \
    --reason keyCompromise
 
# Let's Encrypt revocation using the private key (if you still have it)
certbot revoke --cert-path /path/to/cert.pem \
    --key-path /path/to/privkey.pem
 
# Let's Encrypt revocation using account credentials
# (proves you're the certificate owner)
certbot revoke --cert-path /path/to/cert.pem
 
# Commercial CA revocation: typically via web portal
# 1. Log into CA's certificate management portal
# 2. Find the certificate to revoke
# 3. Select revocation reason
# 4. Confirm revocation
# 5. CA updates CRL and OCSP responder
 
# Enterprise/Internal CA using OpenSSL
openssl ca -config /etc/ssl/openssl.cnf \
    -revoke /path/to/cert.pem \
    -crl_reason keyCompromise
 
# Regenerate CRL after revocation
openssl ca -config /etc/ssl/openssl.cnf \
    -gencrl -out /path/to/crl.pem

Step 2: Verify Revocation

Confirm the certificate is actually revoked:

verify-revocation.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Check OCSP status
openssl ocsp -issuer intermediate.pem \
    -cert revoked-cert.pem \
    -url http://ocsp.example.com \
    -resp_text
 
# Expected output for revoked cert:
# Cert Status: revoked
# Revocation Time: Jan 17 15:30:00 2024 UTC
# Revocation Reason: keyCompromise (1)
 
# Check if cert appears in CRL
openssl crl -in crl.pem -noout -text | grep -A1 "Serial Number"
 
# Verify certificate against CRL
openssl verify -crl_check -CAfile ca-bundle.pem \
    -CRLfile crl.pem revoked-cert.pem
# Should fail: certificate revoked

Step 3: Replace the Certificate

Generate new private key (don't reuse compromised key!)
Create new CSR
Submit to CA for new certificate
Deploy new certificate
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

Revocation Delays

Summary: Certificate Revocation Mastered

Certificate revocation is PKI's hardest problem—and one without a perfect solution. Let's consolidate what we've learned:

Key Takeaways

•Revocation is necessary for security — Key compromise, mis-issuance, and organizational changes all require invalidating certificates before expiration
•CRLs are comprehensive but unwieldy — Complete lists of all revocations, but too large for per-connection checking
•OCSP provides real-time status — Per-certificate queries, but adds latency and reveals browsing to CAs
•OCSP Stapling solves many problems — Server provides response, eliminating latency and privacy concerns
•Browsers mostly soft-fail — Practical reality is most revocations go unchecked; only high-profile ones get special treatment
•Short-lived certificates are the future — Making revocation unnecessary through fast expiration

What's Next:

Page Complete

4 / 5