<!-- https://pkizerotohero.com/handbook/revocation/ | Markdown mirror of the HTML page | PKI Zero to Hero, by Duyutech BV -->

> How certificate revocation works: CRLs, OCSP, stapling, CRLite and CRLSets, why browsers soft-fail, and why OCSP is giving way to CRLs.

Source: https://pkizerotohero.com/handbook/revocation/ · Last reviewed: 2026-10-20

Part V: When trust breaks · Chapter 16

# Taking it back: CRLs, OCSP and stapling

**In one sentence:**

Revocation lets a CA cancel a certificate before it expires, but many clients check late, softly or not at all, so short lifetimes now do much of the work.

## Who is this for

- [IT ops](https://pkizerotohero.com/start/#itops)
- [Expert](https://pkizerotohero.com/start/#expert)
- [Developer](https://pkizerotohero.com/start/#developer)
- [Leader](https://pkizerotohero.com/start/#leader)
- [Beginner](https://pkizerotohero.com/start/#beginner)

Level: **Practitioner**

- [New to this? Start with The idea](https://pkizerotohero.com/handbook/revocation/#the-idea)
- [Developer? Jump to How it really works](https://pkizerotohero.com/handbook/revocation/#how-it-really-works)
- [IT ops? At work](https://pkizerotohero.com/handbook/revocation/#at-work)
- [Leader? Why it matters](https://pkizerotohero.com/handbook/revocation/#why-it-matters-to-the-business)

## The idea

- Beginner

A certificate has an end date written inside it. Until that date, anyone who checks the certificate’s signature will accept it. Sometimes a certificate must stop being trusted earlier:

- the server’s private key was stolen or leaked;
- the CA made a mistake, for example it issued the certificate to the wrong person;
- the organisation no longer owns the domain name.

Cancelling a certificate before its end date is called [revocation](https://pkizerotohero.com/handbook/glossary/#revocation). The [certificate authority](https://pkizerotohero.com/handbook/glossary/#certificate-authority) (CA) that issued it publishes a signed statement: “the certificate with this serial number is no longer good.”

Saying it is the easy part. The hard part is making sure everyone hears it. A revoked certificate does not change. A copy of it looks exactly as it did before, and its signature still checks out. A client only knows about the revocation if it goes and asks, or if someone tells it.

There are three main ways to spread the news:

1. A [certificate revocation list](https://pkizerotohero.com/handbook/glossary/#crl) (CRL). The CA publishes a signed list of every certificate it has revoked. Clients download the list.
2. [OCSP](https://pkizerotohero.com/handbook/glossary/#ocsp), the Online Certificate Status Protocol. The client asks the CA about one certificate and gets a signed answer: good or revoked.
3. [OCSP stapling](https://pkizerotohero.com/handbook/glossary/#ocsp-stapling). The server fetches that signed answer itself and hands it over at the start of the connection.

Each method has a weakness. Lists grow large. Asking the CA is slow and tells the CA which websites you visit. And when the answer does not arrive, most browsers carry on anyway. This is called [soft-fail](https://pkizerotohero.com/handbook/glossary/#soft-fail). A browser that refused every site whose CA was briefly unreachable would break the web. But an attacker who can intercept your connection can often block the check too.

So browsers now download their own compact revocation lists in the background, and the industry is making certificates live shorter. A certificate that expires in a few weeks needs revocation far less than one that lives for a year.

In the game

The Watchtower's list

In the game, the kingdom posts a list of cancelled certificates on the Watchtower, and the gate guards are meant to check it before they let anyone in. Where it stops being true: real guards are software, and many of them never walk to the tower. If the tower is slow to answer, most of them wave the visitor through. And revocation never changes the certificate itself: the stolen copy still looks perfect.

## How it really works

- Developer
- Expert

### When must a CA revoke a certificate?

For publicly trusted TLS certificates, the CA/Browser Forum’s [Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/requirements/) list the reasons and the deadlines in section 4.9.1.1. The CA must revoke within 24 hours when, for example, the subscriber asks for it, the private key is compromised, or the domain validation can no longer be relied on. For other problems, such as a certificate that breaks the rules or contains wrong information, the deadline is 5 days. Anyone can report a compromised key to the CA, not only the certificate’s owner. With ACME, the client sends a signed revocation request ([RFC 8555 section 7.6](https://www.rfc-editor.org/rfc/rfc8555#section-7.6)).

Short-lived certificates are the exception. Since ballot SC-063, a certificate valid for 7 days or less (the limit since 15 March 2026) needs no revocation pointer, and the CA does not have to revoke it.

### What is inside a CRL?

The CRL format is part of the X.509 profile, RFC 5280, in [section 5](https://www.rfc-editor.org/rfc/rfc5280#section-5). A CRL is a signed list with:

- the issuer’s name;
- `thisUpdate` and `nextUpdate`: when this list was made and when the next one is due;
- the serial number and revocation date of each revoked certificate, often with a reason code such as `keyCompromise`;
- a CRL number that only ever goes up.

A certificate points to its CRL in the CRL Distribution Points extension ([RFC 5280 section 4.2.1.13](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13)). Big CAs split their list into shards, and each shard carries an Issuing Distribution Point extension ([section 5.2.5](https://www.rfc-editor.org/rfc/rfc5280#section-5.2.5)) that says which part it covers. This is the start of a real shard published by Let’s Encrypt, downloaded in October 2026:

```text
Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=Let's Encrypt, CN=YE2
        Last Update: Oct 19 21:33:57 2026 GMT
        Next Update: Oct 28 21:33:56 2026 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: 
                B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
            X509v3 CRL Number: 
                1792445637973878324
            X509v3 Issuing Distribution Point: critical
                Full Name:
                  URI:http://ye2.c.lencr.org/96.crl                Only User Certificates

Revoked Certificates:
    Serial Number: 05F2C665B60BF07C77DA5AA7F58A3E99E3DF
        Revocation Date: Sep 14 22:53:11 2026 GMT
```

That one shard listed 1,588 revoked certificates. The Baseline Requirements (section 4.9.7) now oblige every publicly trusted CA to publish CRLs, to refresh them on a fixed schedule and to publish a new one soon after each revocation.

### How does OCSP work?

OCSP is defined in RFC 6960. It answers one question about one certificate. The client sends three things to the responder URL found in the certificate’s Authority Information Access extension: a hash of the issuer’s name, a hash of the issuer’s public key and the certificate’s serial number. The responder returns a signed answer with one of three statuses, `good`, `revoked` or `unknown` ([RFC 6960 section 2.2](https://www.rfc-editor.org/rfc/rfc6960#section-2.2)), plus `thisUpdate` and `nextUpdate` times that limit how long the answer may be cached.

OCSP fixed the size problem of CRLs but brought three new problems:

- **Privacy.** The responder sees which certificates, and so which websites, each client checks. Let’s Encrypt called OCSP “a considerable risk to privacy on the Internet” when it [announced the end of its service](https://letsencrypt.org/2024/12/05/ending-ocsp/).
- **Speed and availability.** Each check is an extra network round trip to a third party during the connection. If the responder is slow or down, the client must wait or give up.
- **Blocking.** An attacker who can intercept your traffic to a fake site can usually block your OCSP request as well.

### What does stapling change?

With OCSP stapling, the server fetches its own OCSP response regularly and sends it inside the TLS handshake. In TLS 1.2 this is the `status_request` extension ([RFC 6066 section 8](https://www.rfc-editor.org/rfc/rfc6066#section-8)). In TLS 1.3 the response travels as an extension of the certificate entry ([RFC 9846 section 4.5.1.1](https://www.rfc-editor.org/rfc/rfc9846#section-4.5.1.1)). The client checks the CA’s signature on the stapled answer, so the server cannot fake it. The CA no longer learns who visits the site, and the client makes no extra call.

Stapling has a gap. An attacker with a stolen key and certificate simply does not staple, and the client falls back to its normal behaviour. The fix was Must-Staple, a certificate extension ([RFC 7633](https://www.rfc-editor.org/rfc/rfc7633)) that tells clients to reject the certificate when no stapled answer arrives. Few clients enforced it, many servers stapled unreliably, and Let’s Encrypt stopped accepting Must-Staple requests as part of ending OCSP.

*Diagram: Three rows. Row 1, CRL: the client fetches the CA's whole signed list of revoked serial numbers; private, but large and only as fresh as the last update. Row 2, OCSP: the client asks a responder about one serial number and gets a signed good, revoked or unknown; the CA learns which site you visit and you wait. Row 3, stapling: the server fetches the OCSP answer in advance and sends it in the handshake; private and fast, but only if the certificate has an OCSP URL.*

Three ways a client can learn that a certificate was revoked.

### Why do browsers soft-fail?

When a browser cannot get a revocation answer in time, it has two choices. It can fail hard and refuse the connection, or fail soft and carry on as if the certificate were good. Hard-fail turns every responder outage and every hotel Wi-Fi login page into a broken web. Soft-fail means the check protects you when nobody is interfering, which is exactly when you need it least.

Mozilla documents Firefox’s choice: when no valid OCSP response arrives within a short timeout, Firefox “ignores the revocation check (i.e. soft-fails)” ([Mozilla wiki](https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox)). Chrome goes further. [Its documentation](https://www.chromium.org/Home/chromium-security/crlsets/) says: “Online (i.e. OCSP and CRL) checks are not generally performed by Chrome.” On the public web, browser revocation checking is largely soft-fail. Treat it as advisory, not as a guarantee.

### What do browsers use instead?

Browsers now push revocation data to users in the background. The check then happens locally, privately and without waiting:

- **CRLSets in Chrome.** Chromium calls CRLSets “the primary means by which Chrome quickly blocks certificates in emergency situations”. As a secondary function, they also carry some other revocations that Google finds by crawling CAs’ CRLs. They hold a subset of all revocations, not all of them.
- **CRLite in Firefox.** Firefox downloads a compact encoding of all revoked certificates that appear in Certificate Transparency logs, updates it every 12 hours and checks it locally on each new connection ([Mozilla Hacks](https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/)). It has been on for all desktop users since Firefox 137, and Mozilla announced it would turn off OCSP for domain-validated certificates in Firefox 142.
- **OneCRL in Firefox**, and similar lists in other browsers, cover revoked intermediate CA certificates.

All of these are built from CRLs. That is one reason the rules changed.

### Why is OCSP fading while CRLs come back?

CA/Browser Forum [ballot SC-063](https://cabforum.org/2023/07/14/ballot-sc063v4-make-ocsp-optional-require-crls-and-incentivize-automation) changed the balance. Since 15 March 2024: OCSP became optional and CRLs became mandatory for publicly trusted TLS certificates. Let’s Encrypt then ended OCSP completely. Let's Encrypt stopped putting OCSP URLs in its certificates from 7 May 2025, and Let's Encrypt has shut down its OCSP service (6 August 2025). It now publishes revocation information only through CRLs.

The direction is clear. Browsers collect CRLs centrally and push compact summaries, and certificate lifetimes shrink so that a revoked certificate stays dangerous for less time. Publicly trusted certificates will be limited to 47 days from 15 March 2029, and Let’s Encrypt already offers six-day certificates. Expiry now does much of the work revocation was meant to do. The [Certificate Transparency](https://pkizerotohero.com/handbook/certificate-transparency/) chapter covers the other half: finding the certificates that need revoking in the first place.

*Diagram: Two timelines. A long-lived certificate: after the key is stolen and the certificate revoked, clients that never check revocation keep accepting it, marked with a cross, until it finally expires. A short-lived certificate: the key is stolen shortly before expiry, the exposure is a short stretch marked with a cross, and after expiry every client rejects it, marked with a tick.*

Revocation shortens the danger only for clients that check. Expiry stops it for everyone.

## At work

- Developer
- IT ops

### Where does my certificate say to check?

The certificate lists its own revocation pointers. Here is the real output for letsencrypt.org:

```bash
openssl x509 -in cert.pem -noout -ext crlDistributionPoints,authorityInfoAccess
```

```text
Authority Information Access: 
    CA Issuers - URI:http://ye2.i.lencr.org/
X509v3 CRL Distribution Points: 
    Full Name:
      URI:http://ye2.c.lencr.org/96.crl
```

There is no `OCSP - URI` line: Let’s Encrypt certificates point only to a CRL. A certificate from a CA that still runs OCSP, here DigiCert, shows both:

```text
X509v3 CRL Distribution Points: 
    Full Name:
      URI:http://crl3.digicert.com/DigiCertEVRSACAG2.crl
    Full Name:
      URI:http://crl4.digicert.com/DigiCertEVRSACAG2.crl
Authority Information Access: 
    OCSP - URI:http://ocsp.digicert.com
    CA Issuers - URI:http://cacerts.digicert.com/DigiCertEVRSACAG2.crt
```

Paste any certificate into the decoder to find the same two fields:

*Interactive tool: Certificate decoder (runs in the browser at [/tools/decoder/](https://pkizerotohero.com/tools/decoder/))*

### How do I read a CRL?

CRLs are usually served in binary DER form. Download one and print its dates:

```bash
curl -s -o 96.crl http://ye2.c.lencr.org/96.crl
openssl crl -in 96.crl -inform DER -noout -issuer -lastupdate -nextupdate
```

```text
issuer=C=US, O=Let's Encrypt, CN=YE2
lastUpdate=Oct 19 21:33:57 2026 GMT
nextUpdate=Oct 28 21:33:56 2026 GMT
```

If `nextUpdate` is in the past, clients that rely on this CRL treat it as stale. Add `-text` to see every entry and its reason code.

### How do I ask an OCSP responder?

You need the certificate and its issuer (the intermediate):

```bash
openssl ocsp -issuer intermediate.pem -cert cert.pem -url http://ocsp.digicert.com
```

```text
WARNING: no nonce in response
Response verify OK
cert.pem: good
	This Update: Oct 18 22:09:01 2026 GMT
	Next Update: Oct 25 21:09:01 2026 GMT
```

“Response verify OK” means OpenSSL checked the responder’s signature. The nonce warning is normal: large responders sign answers in advance and do not echo a nonce.

### Is my server stapling?

```bash
openssl s_client -connect www.digicert.com:443 -servername www.digicert.com -status </dev/null
```

The output includes the stapled answer:

```text
OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
```

followed further down by `Cert Status: good`. For a site with a Let’s Encrypt certificate, the same command prints `OCSP response: no response sent`. That is expected, because there is nothing to staple. If you leave `ssl_stapling on;` in an nginx configuration for such a certificate, nginx logs `"ssl_stapling" ignored, no OCSP responder URL in the certificate "…"` (with the file path) and carries on, which is harmless.

### What does a revoked certificate look like to a client?

You can safely reproduce one with a throwaway lab CA: issue a certificate, revoke it, generate a CRL and verify against it. OpenSSL only checks a CRL when you ask it to:

```bash
openssl verify -crl_check -CAfile ca.pem -CRLfile lab.crl www.pem
```

```text
CN=www.example.test
error 23 at 0 depth lookup: certificate revoked
error www.pem: verification failed
```

Without `-crl_check`, the same command prints `www.pem: OK`. Many libraries and tools behave like this: they do not check revocation unless you configure it. Browsers that do catch a revoked certificate show `NET::ERR_CERT_REVOKED` (Chrome and Edge) or `SEC_ERROR_REVOKED_CERTIFICATE` (Firefox).

### What do I do when a private key leaks?

1. **Generate a new key pair.** Never re-issue a certificate on the leaked key.
    
2. **Get and deploy a new certificate** for the new key, everywhere the old one was used. You need an inventory for this: see [Inventory, expiry and renewal](https://pkizerotohero.com/handbook/certificate-lifecycle/).
    
3. **Revoke the old certificate** with the reason `keyCompromise`. Replace first, then revoke straight away, so that clients which do check are not cut off in between. With certbot (from its [documentation](https://eff-certbot.readthedocs.io/en/stable/using.html)):
    
    ```bash
    certbot revoke --cert-name example.com --reason keycompromise
    ```
    
4. **Search Certificate Transparency logs** for other certificates that use the same names, so that none is missed.
    
5. **Find out how the key leaked** and fix that, or the next key leaks the same way.
    

## Common mistakes

- **“Revoking a certificate blocks it everywhere at once.”** Many clients never check, browsers soft-fail, and pushed lists take hours to arrive. Revocation lowers the risk; it does not remove it.
- **“Once revoked, the stolen key is harmless.”** Clients that do not check keep accepting the revoked certificate until it expires. Replace the key and fix the leak.
- **“Re-issuing the certificate fixes a key compromise.”** Only if the new certificate has a new key. A fresh certificate on the old key is still compromised.
- **“Stapling is on, so revocation is enforced.”** Stapling needs an OCSP URL in the certificate, and an attacker with a stolen certificate simply does not staple.
- **“My library checks revocation by default.”** Often it does not, as the `openssl verify` example shows. Find out what your clients really do before you rely on it.

## Why it matters to the business

- Leader

Why it matters to the business

Revocation is a seatbelt with a loose buckle

If a server key leaks, revoking the certificate is required, but it does not stop every client from trusting it. Browsers check softly or rely on pushed lists, and many applications never check at all. The certificate’s remaining lifetime is the real exposure window. Two decisions follow. First, automate renewal so you can use short-lived certificates and replace any of them within hours. Second, keep a key-compromise runbook (new key, new certificate, revoke, investigate) and an inventory that says where every certificate lives. Without both, a leaked key becomes a long incident.

## Check yourself

Check yourself

A server's private key has leaked. What should you do first?

1. Revoke the certificate and wait for browsers to block it
2. Generate a new key, deploy a new certificate, then revoke the old one
3. Ask the CA to re-issue the same certificate with a new expiry date

Show answer

Answer B Generate a new key, deploy a new certificate, then revoke the old one

What happened

Replacing the key and certificate first, then revoking, removes the leaked key from service without an outage.

Why

Revocation alone does not reach clients that never check, and re-issuing on the old key leaves the leaked key in use.

The rule

Key compromise means new key, new certificate, then revoke.

Check yourself

Firefox asks an OCSP responder about a certificate, but the responder does not answer in time. What does Firefox do by default?

1. Blocks the site with an error
2. Treats the certificate as good and continues
3. Downloads the full CRL instead

Show answer

Answer B Treats the certificate as good and continues

What happened

Firefox soft-fails: it ignores the failed check and carries on.

Why

Failing hard would break sites whenever a responder is slow, so browsers accept the risk instead.

The rule

Browser revocation checking is largely soft-fail. Treat it as advisory.

Check yourself

Why can a CA stop running OCSP for publicly trusted certificates today?

1. The CA/Browser Forum made OCSP optional and CRLs mandatory
2. OCSP was replaced by Certificate Transparency
3. Browsers check every certificate against the CA live

Show answer

Answer A The CA/Browser Forum made OCSP optional and CRLs mandatory

What happened

Ballot SC-063 made OCSP optional for publicly trusted CAs and required CRLs.

Why

Browsers build their pushed lists, such as CRLSets and CRLite, from CRLs. OCSP adds privacy and availability problems.

The rule

CRLs are the required revocation channel. OCSP is optional and fading.

## Go deeper

- [RFC 5280 section 5](https://www.rfc-editor.org/rfc/rfc5280#section-5): the CRL format, fields and extensions.
- [RFC 6960](https://www.rfc-editor.org/rfc/rfc6960): OCSP requests, responses and statuses.
- [RFC 6066 section 8](https://www.rfc-editor.org/rfc/rfc6066#section-8) and [RFC 7633](https://www.rfc-editor.org/rfc/rfc7633): OCSP stapling in TLS and the Must-Staple extension.
- [CA/Browser Forum Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/requirements/), sections 4.9 and 4.10: when CAs must revoke and how they publish status.
- [Ballot SC-063](https://cabforum.org/2023/07/14/ballot-sc063v4-make-ocsp-optional-require-crls-and-incentivize-automation): the decision that made OCSP optional and CRLs mandatory.
- [Let’s Encrypt: Ending OCSP Support in 2025](https://letsencrypt.org/2024/12/05/ending-ocsp/): the reasons and the timeline.
- [Chromium: CRLSets](https://www.chromium.org/Home/chromium-security/crlsets/) and [Mozilla: CRLite](https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/): how Chrome and Firefox check revocation today.

The crash course covers revocation in [lesson 8, When trust breaks](https://pkizerotohero.com/course/when-trust-breaks/).

**Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/handbook/revocation/).

Last reviewed 20 October 2026Edition 0.9

## Keep going

Crash course: [Lesson 8: When trust breaks](https://pkizerotohero.com/course/when-trust-breaks/)

### How-to guides

- [How to monitor Certificate Transparency for your domains](https://pkizerotohero.com/guides/monitor-certificate-transparency/)
- [How to configure TLS securely (versions, ciphers, HSTS)](https://pkizerotohero.com/guides/tls-configuration/)
- [How to set up mutual TLS (nginx and curl)](https://pkizerotohero.com/guides/mutual-tls-setup/)
- [How to build a test CA with OpenSSL (lab only)](https://pkizerotohero.com/guides/openssl-test-ca/)
- [How to use SSH certificates instead of known\_hosts](https://pkizerotohero.com/guides/ssh-certificates/)

### Tools

- [Certificate decoder](https://pkizerotohero.com/tools/decoder/): Paste a PEM certificate and read every field in plain words.

### Topics

- [Revocation and transparency](https://pkizerotohero.com/topics/revocation-and-transparency/)