Letsencrypt 64 Day Certificates: Server Checklist (2026)

On February 10, 2027, letsencrypt 64 day certificates become the default for every certificate Let’s Encrypt issues or renews. It is the first time in the CA’s history that the default lifetime has changed — the 90-day standard has stood since Let’s Encrypt launched a decade ago. If your server still renews on a 90-day mental model, you have about four months to audit your setup, and the staging environment starts issuing 64-day certificates tomorrow, October 14, 2026, so the testing window opens this week.

This post is that audit, written for people who run their own servers: a VPS with certbot or acme.sh, Caddy, nginx, or Traefik in front of an app. No panic, no hype — just the timeline, what can actually break, and the concrete checks to run before February.

Table of Contents

The timeline: what changes and when

Let’s Encrypt announced the change on October 7, 2026. Here is the full schedule, verified against the official announcement:

Date	What happens
October 14, 2026	Staging environment starts issuing 64-day certificates — test your renewal automation now.
February 10, 2027	Production default drops from 90 to 64 days for the `classic` ACME profile. Domain validation (authorization) reuse drops from 30 days to 10 days.
May 11, 2027	The last 90-day certificate expires. No valid certificates are revoked as part of this transition.
February 16, 2028	Production default drops again to 45 days. Authorization reuse shrinks to 7 hours.
2029	CA/Browser Forum requirements cap maximum public certificate lifetimes at 47 days.

A few things that are not changing on February 10: existing 90-day certificates keep working until they expire on their own schedule, the opt-in shorter profiles (45-day tlsserver and ~6-day shortlived) stay as they are, and nothing about pricing changes — the certificates are still free.

Why 64 days — and why not 45 right away

The argument is security, and it is straightforward: the shorter a certificate lives, the less damage a stolen private key or a mis-issued certificate can do, and the less the ecosystem has to depend on emergency revocation, which has never worked reliably at internet scale. The CA/Browser Forum’s baseline requirements are ratcheting maximum lifetimes down across the whole industry — 47 days by 2029 — and Let’s Encrypt is moving ahead of the curve with its own roadmap to 45-day defaults in 2028.

The 64-day stop is deliberate. In community discussions, Let’s Encrypt staff noted that some ACME clients still renew at a hardcoded 60-day interval — a pattern that worked fine for 90-day certificates but would leave almost no safety margin at 45 days. Stopping at 64 first means those setups start throwing imminent-expiration warnings now, surfacing brittle automation while there is still a year to fix it before the stricter baseline arrives. If your tooling survives 64 days cleanly, it will survive 45.

What can actually break

Let’s Encrypt has been explicit about who is at risk: anyone whose renewals are hardcoded to a fixed number of days from expiration, and anyone renewing manually. Here is the concrete list of things to check:

Hardcoded renewal offsets. Cron jobs, wrapper scripts, and runbooks that renew at a fixed point — typically 30 days before expiry, or “every 60/80/83 days” — assume a 90-day certificate. On a 64-day cert, renewing 30 days before expiry means renewing at day 34, which is fine; renewing every 83 days is a guaranteed outage.
Old ACME clients without ARI support. ACME Renewal Info (ARI, standardized as RFC 9773) lets the CA tell your client exactly when to renew, instead of the client guessing from the expiry date. If your client predates ARI support, it cannot adapt to shorter lifetimes automatically.
Monitoring tuned to a 90-day cadence. Alerts like “warn at 30 days remaining” still fire — they just fire proportionally later in the cert’s life. The real gap is renewal failure alerting, which many setups never had.
Manual runbooks. Renewing by hand four times a year was tolerable. Six times a year, trending toward eight at 45 days, is where humans start missing windows.
Validation-reuse assumptions. The authorization reuse window drops from 30 days to 10. Unless you specifically designed your client to rely on reusing validations, you do not need to change anything — but if you did, revisit it.

The renewal audit: six steps

Work through these in order. None of them takes long, and together they cover everything the announcement asks of you.

Step 0: Inventory your certificates

Before changing anything, know what you have. List every certificate on the box, who issued it, and which client manages it:

# See every live certificate and its expiry
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject

# List certbot-managed certificates
sudo certbot certificates

# List acme.sh-managed certificates
acme.sh --list

Note which ones are managed by which client, and flag any certificate that is renewed by a hand-rolled script rather than the client’s built-in renewal. Those are your risk points.

Step 1: Grep for hardcoded numbers

Let’s Encrypt’s own advice: search your cron jobs, wrapper scripts, and runbooks for the hardcoded offsets people actually use — 83, 80, and 60 are the usual suspects:

# Cron jobs and system timers
grep -rnE '\b(83|80|60)\b' /etc/cron* /var/spool/cron/ 2>/dev/null

# Your own scripts and deployment repos
grep -rnE 'renew.*\b(83|80|60)\b|--days?\s*(83|80|60)' ~/bin /opt /srv 2>/dev/null

# certbot renewal configs: check the timing each lineage uses
grep -H 'renew_before_expiry' /etc/letsencrypt/renewal/*.conf

Anything that renews at a fixed interval instead of relative to the certificate’s lifetime needs updating. The rule from the announcement: renew at approximately two-thirds of the certificate’s lifetime — for a 64-day certificate, that is around day 43 (about 21 days of validity remaining), not the old day-60 mark. Setting this correctly now also lays the groundwork for 45-day defaults in 2028.

Step 2: Check that your ACME client speaks ARI

If your client supports ACME Renewal Info, Let’s Encrypt says you should be all set — the CA will tell the client when to renew, and the client will follow. Here is where the common clients stand:

certbot 4.1.0+ (released June 2025): ARI support is built in. certbot renew checks ARI automatically and will renew at roughly two-thirds of the certificate’s lifetime even if renew_before_expiry in the lineage config is set to a later date. Check your version with certbot --version and upgrade if you are behind — distro packages are the usual reason for stale versions.
acme.sh: renews when the CA’s ARI suggestedWindow starts, falling back to the classic 30-day rule when the CA does not advertise renewal info. You can see the next planned renewal with acme.sh --info -d example.com (look for Le_NextRenewTimeStr) and inspect the live ARI window with acme.sh --renew -d example.com --debug 2 2>&1 | grep -i 'ARI suggestedWindow'.
Caddy: renews when a third of the certificate’s lifetime remains (renewal_window_ratio defaults to 0.3333), rescans loaded certificates every 10 minutes, and follows ARI. If you run Caddy’s automatic HTTPS, you are in good shape — this is the setup the 64-day change was designed around.
nginx ACME module / Apache mod_md: the nginx ACME module implements ARI since version 0.4.0; Apache’s mod_md has ARI-triggered renewal on by default since 2.4.66. If you run either, confirm your version.

If your client does not support ARI and cannot be upgraded, you are not stuck — you just own the math. Renew at roughly two-thirds of the lifetime and make sure the schedule runs often enough to notice (daily checks, not monthly).

Step 3: Test in staging this week

Starting tomorrow, October 14, the Let’s Encrypt staging environment issues 64-day certificates, specifically so you can test renewal behavior before production changes. Staging certificates are not trusted by browsers — never serve them on a live site — but they are perfect for a dry run of your automation:

# certbot: test renewal against staging (--dry-run uses staging)
sudo certbot renew --dry-run

# Issue a throwaway staging certificate to exercise the full path
sudo certbot certonly --staging -d test.example.com --webroot -w /var/www/html

# acme.sh: use the staging CA explicitly
acme.sh --issue -d test.example.com -w /var/www/html \
  --server https://acme-staging-v02.api.letsencrypt.org/directory

One quirk to know: certbot 4.1.1+ deliberately skips the ARI check during --dry-run, because dry runs hit staging while your real certificates were issued by production — checking ARI there produced scary warnings for renewals that would have succeeded. Do not read anything into the absence of ARI output in a dry run.

Watch for the failure modes the announcement is really about: a client that renews at a hardcoded 60-day offset will now renew with only 4 days of validity left (64 − 60), leaving almost no room for a failed attempt and a retry. Staging lets you see that margin collapse safely.

Step 4: Fix your alerting, not just your renewals

This is the step most people skip, and it is the one Let’s Encrypt itself flags: automate the reload and deployment of renewed certificates, and add alerting for renewal failures. Two facts make this urgent:

Let’s Encrypt stopped sending certificate expiration emails in 2025. If you were quietly relying on those, they are already gone — the alerting is entirely yours to build now.
Shorter lifetimes mean a failed renewal becomes an outage faster. A cron job that fails silently on a 90-day cert gives you weeks of runway; on a 64-day cert renewing at day 43, you have about three weeks — and at 45 days, roughly two.

At minimum: alert on renewal failure, not just approaching expiry. A simple external check (UptimeRobot, or a Prometheus blackbox exporter probing your HTTPS endpoints) catches the case your local cron cannot — the one where renewal “succeeded” but the new certificate was never deployed or the web server was never reloaded. If you use deploy hooks, make the hook verify the served certificate actually changed:

# Deploy hook: reload nginx, then verify the served cert is the new one
#!/bin/bash
systemctl reload nginx
sleep 2
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

Step 5: Sanity-check validation reuse assumptions

From February 2027, a completed domain validation can be reused for 10 days instead of 30 (dropping to 7 hours in 2028). Let’s Encrypt’s guidance: unless you specifically designed your ACME client to rely on validation reuse, you need no changes. Most setups re-validate on every renewal anyway, so this is a non-event — but if you built custom tooling that assumes a 30-day reuse window (for example, batching many certificate orders behind one validation), revisit that assumption now.

What this change does not do

Worth stating plainly, because the announcement is careful about it:

Nothing is revoked. Existing 90-day certificates stay valid until they expire naturally; the last of them lapses around May 11, 2027.
Rate limits are not tightening. Let’s Encrypt says the shift comes with no rate-limit changes, and renewal orders carrying the ARI replaces identifier are treated as renewals — exempt from issuance limits — so moving to more frequent renewals will not get you throttled.
You do not have to opt into anything. The 64-day default applies to the standard classic profile automatically. The shorter 45-day (tlsserver) and ~6-day (shortlived) profiles remain opt-in for anyone who wants them.
ARI-aware automation needs no changes. If Step 2 above showed a modern client, the official line is that you are already prepared — the audit is confirmation, not homework.

Looking ahead: 45 days in 2028

Everything in this audit pays off twice, because February 16, 2028 brings the 45-day default and the 7-hour validation reuse window. At 45 days, the two-thirds rule means renewing around day 30 — roughly eight renewals a year, and manual processes become operationally unsustainable. If your automation is solid, you could even opt into the 45-day tlsserver profile today and get a year and a half of practice at the future default; only do that if your renewal, deployment, and alerting are all proven, since there is no reason to volunteer for tighter margins early.

The industry is moving in one direction — the CA/Browser Forum’s 47-day maximum lands in 2029, and every publicly trusted CA is making similar moves. The operators who treat 64 days as a fire drill will find 45 days boring. The ones who ignore it will find 45 days is when things start expiring.

The 10-minute checklist

☐ Inventory: list every cert, its client, and its renewal path (Step 0)
☐ Grep cron jobs, scripts, and runbooks for hardcoded 83 / 80 / 60 offsets (Step 1)
☐ Confirm your ACME client supports ARI — certbot ≥ 4.1, current acme.sh, Caddy, or documented equivalents (Step 2)
☐ Retarget fixed schedules to ~⅔ of certificate lifetime (~day 43 for 64-day certs) (Step 1)
☐ Run one staging issuance or --dry-run after October 14 (Step 3)
☐ Add renewal-failure alerting; do not rely on expiry emails (discontinued 2025) (Step 4)
☐ Verify deploy hooks actually reload the server and the new cert is served (Step 4)
☐ Revisit any tooling that assumes 30-day validation reuse (Step 5)

Facts in this post verified October 13, 2026 against the official Let’s Encrypt announcement, the Certbot and acme.sh changelogs, and current client documentation.

Let’s Encrypt 64-Day Certificates: What to Check on Your Server Before February 2027