Let’s Encrypt shortens certificates to 64 days in February 2027, then 45 days in 2028
On February 10, 2027, Let’s Encrypt drops the default certificate lifetime from 90 to 64 days, before 45 days in 2028. If your renewal relies on hard-coded dates, it will break: audit your cron jobs and move to ACME automation.
February 10, 2027. Let’s Encrypt drops the default certificate lifetime from 90 to 64 days. October 14, 2026. The staging environment already issues 64-day certificates for testing. February 16, 2028. The default falls to 45 days. Why it matters: anyone still renewing certificates with a fixed-date cron job will see their sites fail with certificate errors, no exceptions.
The precise timeline, so nothing catches you off guard
Let’s Encrypt published an unambiguous timeline on October 7, 2026. From February 10, 2027, every certificate issued or renewed will have a 64-day validity by default — unless you explicitly select a shorter profile of 45 or 6 days, announced back in late 2025.
The last 90-day certificate will expire on May 11, 2027. No valid certificate will be revoked: the transition is soft, and breaks nothing on its own. Then, on February 16, 2028, the default drops to 45 days, completing a move that has been years in the making.
The staging environment switched to 64 days on October 14, 2026. That is the entry point for testing your renewal chain before production, with no risk to your real certificates.
Why 64 days, and why it affects you
The motivation is simple and stated plainly by Let’s Encrypt: shrink the risk window from a key compromise or a mis-issuance. A 64-day certificate that leaks has a shorter exploitation value than a 90-day one. It is the same logic that pushed Apple and then the wider ecosystem toward shorter lifetimes, and it is on track to become the norm across all authorities, not just Let’s Encrypt.
The practical consequence lands first on self-hosters. On a NAS, a VPS, or a home server, renewal is often a cron written once and then forgotten. While certificates lasted 90 days, a “renew 30 days before expiry” job left a comfortable margin. At 64 days, then 45, that margin disappears and fixed-date scripts fall out of sync.
The second change is the authorization reuse period: it drops from 30 to 10 days now, then to 7 hours in 2028. Unless your ACME client was specifically designed to depend on validation reuse, you have nothing to do — but it is one more signal that the whole validation flow is tightening.
What breaks, and what does not
The announcement draws a clean line between two populations. If your renewals are automated and your client supports ARI (ACME Renewal Info), you are already ready: Let’s Encrypt tells your client when to renew, and the certificate lifetime becomes an implementation detail.
If your renewals are hard-coded to a date, you need to act before February 2027. Let’s Encrypt recommends renewing at about two-thirds of the lifetime, and grepping for the fixed numbers in your scripts: 83, 80, or 60 days are the typical values to replace.
# Quick audit of fixed-date renewal crons
grep -rE "(83|80|60)" /etc/cron* /etc/systemd/system 2>/dev/nullThe right reflex is to replace any “renew N days before expiry” logic with an ARI-driven trigger or, failing that, a frequent and idempotent renewal — certbot renew and modern clients are already built to run several times a day with no side effects.
For the self-hoster, the cleanest upgrade path is usually a one-line change: drop a fixed threshold like --days 83 in favor of the client’s built-in ARI-aware renewal, or simply run the renew command more often. Because ACME renewal is idempotent — renewing an unexpired certificate is a no-op — there is no penalty for running it daily, only protection against a forgotten edge case.
What does not change: rate limits, ACME endpoints, and issuance chains. You change neither the URL, nor the root chain, nor the quotas. Only the validity period contracts.
What it changes on a NAS or a box
On a Synology NAS, UGREEN, or a self-hosted box, renewal often goes through the vendor’s control panel or a dedicated Docker container. The move to 64 days asks nothing special if the embedded ACME client supports ARI or renews on a short interval. But two traps await older setups: scheduled tasks written for a 90-day certificate, and personal scripts that copy the certificate to a service — a reverse proxy, a VPN client — without reloading that service after renewal.
The staging test is exactly for this: run a full issuance, then check that the service consuming the certificate actually reloads it. A certificate renewed but not reloaded is an incident that only appears at expiry — and with shorter lifetimes, it will appear sooner.
Who supports ARI, and how to check
The variable that decides everything is ARI (ACME Renewal Info) support, the mechanism by which Let’s Encrypt tells your client the right time to renew. The major clients integrated it long ago: certbot, acme.sh, lego, Caddy — which renews natively in the background — and Traefik through its ACME provider. The check comes down to a command or a quick version read.
The right reflex is not to guess but to read your client’s documentation and confirm ARI is implemented in your exact version. If it is, you are ready for the move to 64 days without touching anything: the client will follow the schedule the authority announces. If it is not, switch to a client that supports it, or force a frequent, idempotent renewal.
The broader context points the same way. Apple was already proposing 47-day certificates back in 2023, and the CA/Browser Forum has pushed toward shorter lifetimes for years. Let’s Encrypt is simply aligning its schedule with a trajectory browsers have already endorsed: in the long run, long-lived certificates will become the exception, not the norm.
What to do now
The announcement leaves time, but the work is the “one hour now, one outage avoided in February” kind.
- Check ARI support. Read your ACME client’s documentation (certbot, acme.sh, lego, Caddy, Traefik…). If it supports ARI, you have nothing to change: the client will follow the new schedule automatically.
- Hunt for hard-coded dates. Grep for
83,80, and60in crons, wrapper scripts, and runbooks. Replace them with renewal at two-thirds of the lifetime, or better, an ARI trigger. - Test in staging. The staging environment has issued 64-day certificates since October 14, 2026. Validate your full chain — issuance, deployment, service reload — before February 2027.
- Automate reload and alerting. Use the occasion to automate certificate redeployment and add a renewal-failure alert. An expired certificate is a preventable incident, not a weather event.
Verdict
If you self-host HTTPS services, open your task manager today and replace any “renew on a fixed date” rule with ARI or frequent renewal: at 64 days then 45 days, the manual margin no longer exists. If your ACME client already supports ARI, you literally have nothing to do — and that is exactly the point: shorter lifetimes are only sustainable if renewal becomes an automation nobody has to watch by hand. February 2027 is closer than the calendar suggests when the fix is a one-line cron change.