Let's Encrypt moves to 64-day certificates: what agencies need to check

The new timeline, the renewal settings that will break, and a checklist for every client site.

For an agency, this is not one change on one server. It is the same change on every client site you host, on the shared hosting you inherited, on the old VPS nobody has logged into since the launch, and on the load balancer where someone copies a certificate by hand. Most of them will be fine. The few that are not will fail quietly, and the first person to notice will be a client looking at a browser warning. This guide shows where to look.

The timeline

Two schedules overlap. The CA/Browser Forum, where browsers and certificate authorities agree on the rules, caps the maximum lifetime of every public certificate. Let's Encrypt, already well under those caps, is shortening its own certificates ahead of them.

The dates apply to certificates issued on or after them. You will see a 64-day certificate on each site at its first renewal after 10 February 2027, not on that day itself.

Paid certificates follow the CA/B Forum line, not the Let's Encrypt one: if some clients buy certificates from a commercial authority, the 100-day step in March 2027 is the one that concerns them.

What breaks

Let's Encrypt says it plainly: if your renewals are automated and your client supports ARI, you should be all set. Everything below is about the setups that are not in that situation. As a reference, two thirds of 64 days is about day 43, which leaves around three weeks of margin.

Renewal delays hard-coded for 90 days

Many scripts were written when every certificate lasted 90 days, and they count from the issue date. Let's Encrypt suggests searching for three numbers in cron jobs, wrapper scripts and runbooks: 83, 80 and 60.

• 83 or 80 days after issue. A 64-day certificate has already been expired for 16 to 19 days when the script decides to renew. These setups break at the first renewal after the switch.
• 60 days after issue. It still works on paper, with 4 days of margin. One failed attempt (a closed port 80, a DNS change, a rate limit) and the site goes down. In February 2028, with 45-day certificates, it breaks outright: the certificate expires 15 days before the renewal date.

A setting expressed as time before expiry ages better. Renewing when 30 days remain gives a 64-day certificate a renewal at day 34. A setting expressed as a fixed number of days after issue does not.

Renewal at two thirds of the lifetime

This is the rule Let's Encrypt recommends for clients without ARI, because it follows the certificate rather than the calendar: 60 days on a 90-day certificate, about 43 on a 64-day one, 30 on a 45-day one. If a script reads the real notBefore and notAfter dates of the certificate and renews at two thirds, it needs no change. If someone wrote "two thirds" as a constant of 60 days, it is a hard-coded delay like the others.

Cron jobs that run too rarely

A renewal job that runs once a month gets one, maybe two chances inside a three-week window. If the single attempt fails, the next one may come after the certificate has expired. RFC 9773, the ARI standard, makes the same point: cron-based clients may need to run more often, and must then remember failures so they back off instead of retrying in a loop. Run the check at least daily and let the client decide whether a renewal is due.

Legacy hosts and manual copies

Some certificates are not renewed where they are used. They are issued on one machine, then uploaded by hand to a shared hosting panel, a CDN, a mail server or an appliance. With renewal around day 43, each of those certificates is renewed about eight or nine times a year instead of about six. Every manual step is repeated that often, and the person who did it last time may have left. Our guide on why Let's Encrypt renewals fail covers the related trap: the renewal ran, but nothing reloaded.

Scripts that rely on authorization reuse

From 10 February 2027, a domain validation can be reused for 10 days instead of 30, then for 7 hours in 2028. Let's Encrypt notes that most clients do not depend on this. It concerns setups that validate a domain once and issue certificates later, for example a validation step run by hand before a batch job.

A checklist for agencies

Run this once per server or platform that renews certificates, not once per site.

1. 1List where renewals actually happen. For each client site: which machine or service renews the certificate, with which ACME client, and where the certificate is then deployed.
2. 2Search for hard-coded delays. On each machine, look for 83, 80 and 60 in cron jobs, systemd timers, wrapper scripts and runbooks. Expect noise (*/60, ports, timeouts); you are looking for numbers of days.

grep -rnE '\b(83|80|60)\b' /etc/cron* /etc/systemd/system /usr/local/bin 2>/dev/null

1. 3Check whether the client supports ARI. Look for "ARI" or "renewal information" in your ACME client's documentation or changelog. Let's Encrypt advertises it in its directory under renewalInfo.
2. 4Test against staging now. The staging environment has been announced as issuing 64-day certificates since 14 October 2026. With Certbot, sudo certbot renew --dry-run runs a full renewal against staging without touching your real certificates. Other clients have an equivalent staging or test option.
3. 5Check the lifetime of what you get. On any certificate issued after the switch, read the dates and confirm the renewal logic still fits:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates

1. 6Make the job run daily. Replace monthly or weekly renewal jobs with a daily check, and confirm it keeps a record of failures.
2. 7Automate the reload and every copy. Use deploy hooks to reload the web server, and script any upload to a CDN, load balancer or mail server. Anything left manual will need doing eight or nine times a year per certificate.
3. 8Move inherited and legacy sites first. Old panels and hand-made setups are the ones most likely to break. Plan them before February, not after the first browser warning.
4. 9Keep the domain itself under watch. A certificate cannot be renewed once its domain has lapsed: see what happens when a domain expires.

What ACME ARI does, and what it does not

ACME Renewal Information is an extension to the ACME protocol, standardised as RFC 9773. The certificate authority publishes a renewalInfo endpoint. For each certificate, the client asks it for a suggested renewal window, a start and an end time, picks a random moment inside it, and renews then. The server also tells the client when to ask again.

This solves the problem behind this whole guide: the client no longer has to guess the right renewal date from a lifetime written in its code. When Let's Encrypt shortens certificates, or needs a batch of certificates replaced early after an incident, it moves the window and ARI clients follow. When we checked a current 90-day Let's Encrypt certificate, the suggested window opened about 30 days before expiry.

You can look at the window yourself. The request is an unauthenticated GET built from the certificate's Authority Key Identifier and serial number (OpenSSL 1.1.1 or later, and Perl):

host=example.com
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null | openssl x509 > cert.pem
hex2b64url() { tr -d ' :\n' | perl -pe 's/([0-9a-fA-F]{2})/chr hex $1/ge' | openssl base64 -A | tr '+/' '-_' | tr -d '='; }
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | tail -n1 | sed 's/.*keyid://' | hex2b64url)
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
[ $(( ${#serial} % 2 )) -eq 1 ] && serial="0$serial"
case "$serial" in [89A-Fa-f]*) serial="00$serial";; esac
curl -s "https://acme-v02.api.letsencrypt.org/acme/renewal-info/$aki.$(printf %s "$serial" | hex2b64url)"

What ARI does not do is confirm that anything happened. It tells the client when to renew. It does not check that the renewal succeeded, that the new certificate was deployed to every server, or that the site now serves it. A certificate that "auto-renews" has not necessarily renewed. That gap is the same as before, with less time to notice it.

How to monitor it

The only reliable signal is the certificate a visitor actually receives. Logs from the renewal job tell you the job ran; they do not tell you what the CDN in front of the site is serving. So check from outside:

1. 1Alert on the served certificate, not the file on disk. Read the expiry date from the live site, as a browser would.
2. 2Set alerts relative to the new lifetime. If renewal normally happens around 21 days before expiry, an alert at D-14 means renewal has been failing for a week, and D-7 is the last comfortable moment to fix it. Alerts at D-60 make no sense for a 64-day certificate.
3. 3Watch for a lifetime or issuer change. A certificate that suddenly comes from another authority, or still lasts 90 days in April 2027, tells you something changed in the setup.
4. 4Send the alert to someone who still works on the project. For each client, check who receives it today.

Lapsentry does this for agencies: it reads the certificate served by every client domain, next to the domain's own expiry date, and alerts the right people on email, Slack, Teams or SMS before either one lapses.

Start your 14-day free trial: no card required.

Sources

• Let's Encrypt, 64-Day Certificate Lifetimes Coming Feb 2027, 7 October 2026.
• Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days, 2 December 2025.
• Let's Encrypt, Profiles documentation (classic, tlsserver, shortlived).
• IETF, RFC 9773: ACME Renewal Information (ARI) Extension.
• CA/Browser Forum, Baseline Requirements, section 6.3.2, and Ballot SC-081v3.

FAQ

When do Let's Encrypt certificates become 64-day certificates?

On 10 February 2027, for every certificate issued or renewed from that date with the default profile. Each site gets its first 64-day certificate at its first renewal after that date. The staging environment has been announced as issuing them since 14 October 2026, for testing.

Will my current 90-day certificates be revoked?

No. Let's Encrypt says it will not revoke valid certificates as part of this change. They stay valid until their normal expiry date, and the last ones are expected to expire around 11 May 2027.

What is ACME ARI?

ACME Renewal Information (RFC 9773) lets the certificate authority tell your ACME client when to renew each certificate, through a suggested time window. A client that supports ARI does not need a renewal delay written in its configuration, so shorter lifetimes do not require a change.

What should I change if my client does not support ARI?

Renew at about two thirds of the certificate's lifetime, calculated from its real dates, and run the renewal check at least once a day. Remove fixed delays such as 60, 80 or 83 days after issue.

Does Certbot's default "renew 30 days before expiry" still work?

Yes for 64-day certificates: renewal happens around day 34, with a month of margin. It also works with 45-day certificates in 2028, since the renewal then comes at day 15. What matters is that the job runs often enough to retry if one attempt fails.

Do paid SSL certificates change too?

Yes, on a different schedule. The CA/Browser Forum caps all public certificates at 200 days since 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Commercial authorities apply those limits to the certificates they sell.

How often will each certificate be renewed?

With renewal around two thirds of 64 days, about every 43 days, so eight or nine times a year instead of about six with 90-day certificates. Automated renewals will not notice. Manual steps, such as uploading a certificate to a hosting panel, will.

More guides

• Why Let's Encrypt renewals fail
• What happens when a domain expires?
• Orphaned subdomains: what they are and how to find them
• Who should own a client domain?