# Let's Encrypt shuts down OCSP and moves revocation to CRLs

> Let's Encrypt switched off its OCSP responders on 2025-08-06, dropped OCSP URLs and Must-Staple in May 2025, and now publishes revocation via CRLs.

Source: https://ssl.sh/news/lets-encrypt-ends-ocsp/
Last updated: 2026-11-10

Let's Encrypt turned off its [OCSP](https://ssl.sh/glossary/ocsp/) responders on 6 August 2025, ending real-time certificate status queries at the world's largest CA. Revocation is now published only through [certificate revocation lists](https://ssl.sh/glossary/crl/), whose URLs appear in the certificates it issues. The shutdown completed a plan announced on 5 December 2024.

## What happened

Let's Encrypt dropped OCSP mainly for privacy: every query tells the CA which site a user is visiting. OCSP lets a client ask the CA whether one specific certificate has been revoked. CA/Browser Forum Ballot SC-063 made OCSP optional for publicly trusted CAs from 15 March 2024 while making CRLs mandatory, which allowed Let's Encrypt to drop OCSP entirely.

The timeline:

- **2024-12-05**: plan announced.
- **2025-01-30**: new orders requesting the [OCSP Must-Staple](https://ssl.sh/glossary/must-staple/) extension rejected, unless the account had previously been issued a Must-Staple certificate.
- **Before 2025-05-07**: CRL Distribution Point URLs added to certificates.
- **2025-05-07**: OCSP URLs removed from new certificates; all Must-Staple orders rejected.
- **2025-08-06**: OCSP responders shut down.

Because Let's Encrypt certificates last 90 days, the last certificates carrying an OCSP URL, issued just before 7 May 2025, had expired by the time the responders went offline.

## Who is affected

Browsers barely noticed. The change fell on servers and clients that still used OCSP:

- **Servers with [OCSP stapling](https://ssl.sh/glossary/ocsp-stapling/) enabled.** With no OCSP URL in the certificate, nginx logs a warning such as `"ssl_stapling" ignored, no OCSP responder URL in the certificate` and skips stapling. Sites keep working, but the configuration is dead weight.
- **Must-Staple users.** Let's Encrypt no longer issues certificates with the Must-Staple extension, so ACME clients configured to request it fail until the option is removed.
- **Clients that insist on an OCSP answer.** Custom software, some enterprise proxies and embedded devices that hard-fail without OCSP must switch to CRL checking or stop requiring online status checks.

Browsers did not depend on Let's Encrypt's responders: Chrome relies on its own CRLSets, and Firefox has been moving to [CRLite](https://ssl.sh/glossary/crlite/) instead of querying OCSP for most certificates.

## What you should do

Remove OCSP stapling and Must-Staple settings, which no longer do anything for Let's Encrypt certificates. First check whether a certificate still has an OCSP URL and where its CRL lives:

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

An empty result from the first command is expected for current Let's Encrypt certificates. On nginx servers that only use Let's Encrypt certificates, remove the stapling directives:

```nginx
# no longer useful for Let's Encrypt certificates
# ssl_stapling on;
# ssl_stapling_verify on;
```

Remove `--must-staple` from certbot commands and delete `must_staple = True` from files under `/etc/letsencrypt/renewal/`, then confirm renewal still works:

```bash
sudo certbot renew --dry-run
```

The [OCSP and CRL guide](https://ssl.sh/learn/ocsp-and-crl/) explains how [revocation](https://ssl.sh/glossary/revocation/) checking works today, and the [Let's Encrypt timeline](https://ssl.sh/timeline/lets-encrypt/) lists this change alongside the [end of expiration emails](https://ssl.sh/news/lets-encrypt-ends-expiration-emails/).