Let's Encrypt Certificates Are Getting Shorter. Check Your Renewal.

On 7 October Let's Encrypt announced that from 10 February 2027 every certificate it issues will be valid for 64 days instead of 90. The last 90-day certificate it issues will expire on 11 May 2027. The staging environment switches on 14 October so you can test now. And 64 is a step, not the destination: the plan is 45 days in 2028, with a 6-day option already available for anyone who wants it.

For most WordPress sites this changes nothing, because certbot has been renewing certificates on a timer for years and will keep doing so. For a minority it will break something in February, quietly, and the site will go down with a certificate error one morning in April. This post is about finding out which group you are in before then.

Why they are doing it

A certificate is a promise that a key belongs to a domain. The shorter the promise lasts, the less damage a stolen key or a mistaken issuance can do, and the less the whole system has to lean on revocation, which has never worked well. Let's Encrypt has been moving in this direction for a while. Shorter lifetimes also mean renewal has to be automated, because nobody is going to do it by hand every nine weeks, and that is the point. Automation that works at 90 days but was never actually tested is what the change is going to find.

The two ways this breaks

A renewal schedule with a fixed number of days in it. Plenty of setups renew when a certificate has fewer than N days left, and N was picked when certificates lasted 90 days. Let's Encrypt's advice is to renew at about two-thirds of the certificate's lifetime, and to search cron jobs, wrapper scripts and runbooks for hard-coded numbers like 83, 80 or 60. A script that renews at 60 days remaining on a 64-day certificate will renew every four days, which is not what anyone intended. A script that renews at 30 days remaining will still work at 64, and at 45 it will be renewing with 15 days of margin, which is thinner than I would like for something that only tries twice a day.

An old client that does not know when to renew. Let's Encrypt publishes something called ACME Renewal Information, or ARI. The CA tells the client when it wants the renewal to happen, so the client does not need a fixed threshold at all and the CA can bring renewals forward if it ever needs to revoke. certbot added ARI support in version 4.1.0, in mid 2025. If your certbot is older than that, it is still using its own 30-day rule.

This is where Ubuntu catches people. The certbot in Ubuntu 22.04's package archive is 1.21.0. The one in 24.04 is 2.9.0. Neither has ARI, and neither is going to be updated to a version that does, because distribution packages freeze at release. certbot's own installation instructions have recommended the snap for years for exactly this reason, but a lot of servers were set up with apt install certbot because it was there and it worked. It still works. It just does not know anything about ARI, and when lifetimes drop to 45 days its 30-day rule starts to look less comfortable.

Check yours in five minutes

Start with the version:

certbot --version

Anything below 4.1 has no ARI. If it was installed with apt, the clean fix is to remove the apt package and install the snap, which is what certbot's documentation says to do on Ubuntu anyway. Your certificates and configuration in /etc/letsencrypt survive the swap.

Then confirm the renewal timer actually exists and actually runs:

systemctl list-timers | grep certbot
certbot renew --dry-run

If the dry run fails, it has been failing, and you have been living on the 90-day margin without knowing it. That margin is about to get smaller.

Then look for anything renewing on its own schedule:

grep -r "certbot\|acme" /etc/cron* /etc/systemd/system 2>/dev/null

Anything that passes a number of days, or runs a wrapper script that does, needs that number checked against two-thirds of 64, which is 42. Better still, remove the number and let ARI decide.

A smaller change arrived immediately: the period for which Let's Encrypt reuses a completed domain authorisation dropped from 30 days to 10 on the day of the announcement, and will fall to seven hours in 2028. In practice that means a renewal will re-run the HTTP or DNS challenge more often. If port 80 is firewalled off, or the DNS API token in your renewal hook expired a year ago, that is going to show up sooner than it used to.

If you are behind Cloudflare, or on managed hosting

If your site is proxied through Cloudflare, visitors see Cloudflare's certificate and this change does not touch it. Your origin certificate still matters, because Cloudflare has to trust it in Full (strict) mode, and if that origin certificate is from Let's Encrypt everything above applies. If it is a Cloudflare Origin CA certificate, those are issued for up to fifteen years and nothing changes.

If you are on managed hosting, the host's platform renews certificates and this is their problem. It is a reasonable question to ask them, though, because a host that has not thought about February is a host you want to know about now.

Where this fits

Chapter 6 of the Protect My WP handbook covers certificates, HTTPS and the headers around them, with certbot as the default and the dry-run renewal check as part of setting it up. The check above is the same one, with a date attached.

Get the book for £19.