Let's Encrypt changes in 2025-2026: OCSP ended, new profiles, 64-day certificates from February 2027

Let's Encrypt has changed a lot since late 2024. Most of it is invisible if your renewals are automated and your client is reasonably current, but a few changes need action: hard-coded renewal intervals, software that expects OCSP, and anyone using Let's Encrypt certificates for TLS client authentication.

Below is what changed, when, and what to check, taken from Let's Encrypt's own announcements and documentation.

Changes that took effect in 2025

Expiry reminder emails ended (4 June 2025)

Let's Encrypt stopped sending expiration emails on 4 June 2025 and deleted the addresses it had stored with issuance data. If those emails were your safety net, you now need your own expiry monitoring.

OCSP switched off (6 August 2025)

Revocation information is now published only through Certificate Revocation Lists (CRLs). The timeline, from the December 2024 announcement: requests for the OCSP Must-Staple extension started failing for new accounts on 30 January 2025 and for everyone on 7 May 2025, when OCSP URLs were also dropped from new certificates; the OCSP responders were turned off on 6 August 2025. Browsers were not affected, but non-browser software (some VPN and embedded clients) that insisted on an OCSP URL could be. OCSP stapling settings in Nginx or Apache have nothing to staple for current Let's Encrypt certificates; they can stay or go, but do not expect them to do anything for these certificates.

Certificate profiles

An ACME client can now request a profile. classic is the default. tlsserver drops fields the Baseline Requirements no longer recommend and, since 13 May 2026, issues 45-day certificates. shortlived issues certificates valid for 160 hours (just over six days).

Changes in 2026

Six-day and IP address certificates (15 January 2026)

Short-lived certificates and certificates for IPv4 and IPv6 addresses became generally available. IP address certificates must use the shortlived profile. Both are opt-in; there is no plan to make six-day certificates the default. In Certbot, IP certificates need the --ip-address flag (Certbot 5.3) and version 5.4 or later for webroot mode, per the Certbot announcement.

No more TLS client authentication

Because of a Chrome root program requirement to separate client and server authentication, the classic profile stopped including the TLS Client Authentication EKU on 11 February 2026, and the temporary tlsclient profile was available only until 8 July 2026. If you used Let's Encrypt certificates to authenticate a client to a server (mutual TLS, some VPN or device set-ups), move those to a private CA.

New "Generation Y" roots and intermediates

Let's Encrypt created two new roots, ISRG Root YR (RSA) and ISRG Root YE (ECDSA), with intermediates YR1 to YR3 and YE1 to YE3 that cannot issue client-auth certificates. Its certificates page lists YE1, YE2, YR1 and YR2 in active rotation, with default chains cross-signed back to ISRG Root X1, and notes that the new roots are not yet in root program trust stores. Practical rules: serve the full chain your ACME client gives you (for Certbot, fullchain.pem), and never pin an intermediate; Let's Encrypt picks one at random for each certificate on purpose.

DNS-PERSIST-01 challenge

Let's Encrypt is implementing DNS-PERSIST-01, a DNS validation method where you publish one long-lived TXT record at _validation-persist.<domain> naming the CA and your ACME account, instead of changing a TXT record at every renewal. It was standardised in the Baseline Requirements by ballot SC-088v3 in October 2025; the post planned staging in early 2026 and production in the second quarter. Check the documentation for current availability before relying on it, and remember that the ACME account key becomes the thing to protect.

Coming next: 64 days, then 45 days

As announced on 7 October 2026:

• 14 October 2026: the staging environment started issuing 64-day certificates for testing.
• 10 February 2027: the default classic profile issues 64-day certificates, and authorization reuse drops from 30 days to 10 days. Existing certificates are not revoked; the last 90-day certificates should expire around 11 May 2027.
• 16 February 2028: 45-day certificates by default, with a 7-hour authorization reuse period (per the December 2025 plan).

Rate limits do not change: renewals are exempt from the new-certificate limits, according to the rate-limit post. Endpoints and issuance chains are unaffected by the lifetime change.

Check your client and scripts

Let's Encrypt's advice is to renew at about two thirds of the lifetime or use a client with ACME Renewal Information (ARI), and to search cron jobs, wrapper scripts and runbooks for hard-coded numbers such as 60, 80 or 83 days.

For Certbot from the distribution packages: Debian 12 (bookworm) ships Certbot 2.1.0, which renews 30 days before expiry and has no profile or ARI support; Debian 13 (trixie) ships Certbot 4.0.0, which renews when a third of the lifetime remains and supports --preferred-profile. ARI arrived in Certbot 4.1.0, according to the Certbot changelog. Both packaged versions renew in time for 64-day certificates if the timer runs.

certbot --version
sudo certbot certificates
systemctl list-timers certbot.timer
sudo grep -rn -e certbot -e acme /etc/cron* /etc/systemd/system 2>/dev/null

The last command finds custom renewal jobs that may override the packaged timer. A dry run now exercises the staging environment, which already issues 64-day certificates:

sudo certbot renew --dry-run

Looking further ahead, Let's Encrypt plans post-quantum certificates based on Merkle Tree Certificates, targeting a staging environment in late 2026 and production in 2027. Nothing changes for current certificates.

What you should do

• Set up your own expiry monitoring; Let's Encrypt no longer emails you.
• Remove fixed-interval renewal jobs; renew at about two thirds of the lifetime or use an ARI-capable client.
• Test now with certbot renew --dry-run against staging's 64-day certificates.
• Move any client-authentication use to a private CA.
• Serve the full chain and do not pin intermediates or roots.
• Check that VPNs and appliances using these certificates work without OCSP.

Sources

• letsencrypt.org/2026/10/07/64-day-certs
• letsencrypt.org/2025/12/02/from-90-to-45
• letsencrypt.org/2026/02/24/rate-limits-45-day-certs
• letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
• letsencrypt.org/2024/12/05/ending-ocsp
• letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life
• letsencrypt.org/docs/profiles
• letsencrypt.org/2026/01/15/6day-and-ip-general-availability
• letsencrypt.org/2026/03/11/shorter-certs-certbot
• letsencrypt.org/2025/05/14/ending-tls-client-authentication
• letsencrypt.org/2025/11/24/gen-y-hierarchy
• letsencrypt.org/certificates
• letsencrypt.org/2026/02/18/dns-persist-01
• letsencrypt.org/2026/06/03/pq-certs
• github.com/certbot/certbot/blob/main/certbot/CHANGELOG.md
• packages.debian.org/bookworm/certbot
• packages.debian.org/trixie/certbot