By ByteBot
Let’s Encrypt announced on October 7 that its default certificate validity drops from 90 days to 64 days starting February 10, 2027. The staging environment opens October 14 — two days from now. If any of your automation scripts renew certificates using hardcoded day offsets, you have a problem. Certificates will either renew on every single cron run, or refresh 15 times a month instead of once. This is the first validity reduction in Let’s Encrypt’s eleven-year history, and the first step in a CA/Browser Forum mandate that will cap all TLS certificates at 47 days by 2029.
The Real Risk Is Not the Shorter Cert
It’s the math baked into your renewal scripts.
Most ACME clients use one check: if the certificate expires sooner than now plus renewal_interval, renew. That logic works fine when your renewal interval is less than the certificate lifetime. When it isn’t, the condition is permanently true — and your client renews on every invocation.
Three specific values are dangerous:
| Hardcoded Value | What It Was For | Effect on 64-Day Cert |
|---|---|---|
| 83 days | Renew 7 days after issuance | Renews on every cron run |
| 80 days | Renew 10 days after issuance | Renews on every cron run |
| 60 days | Renew 30 days before expiry | ~15 renewals per month |
These offsets are everywhere: certbot --days flags, renew_before_expiry values in /etc/letsencrypt/renewal/*.conf, acme.sh --renew-days arguments, Ansible roles, Chef cookbooks, wrapper scripts in cron.d. They were written for 90-day lifetimes and nobody updated them because nothing broke. February 10, 2027 breaks them.
Who Can Ignore This
If your client supports ACME Renewal Information (ARI, RFC 9773) and you have not pinned a manual renewal offset, you’re fine. ARI lets Let’s Encrypt push the recommended renewal window directly to your client, bypassing fixed arithmetic entirely.
| Client | ARI Support Since | Default on 64-Day? |
|---|---|---|
| Certbot | 4.1.0 (June 2025) | Renews at day 43 — safe |
| Caddy | 2.8.0 (May 2024) | Fully automatic — safe |
| acme.sh | 3.1.4 (July 2026) | ARI on by default — safe |
| nginx ACME module | ngx_http_acme_module (Aug 2025) | Native ACME — safe |
Legacy scripts with --days flags | N/A | At risk |
The catch: ARI cannot override a pinned schedule. If you explicitly pass --days 60, or set renew_before_expiry = 30days in a conf file, ARI is silently bypassed for that certificate. Your client version does not matter if you’ve overridden it.
What to Do Before February
Start with the staging environment on October 14. Let’s Encrypt’s staging instance will issue 64-day certificates starting then. Run your renewal flow against it, check the logs, and verify nothing loops.
Then grep your infrastructure for the dangerous values:
grep -r "--days 8[0-9]\|renew_before_expiry.*8[0-9]\|renew_before_expiry.*60\|renew-days 6[0-9]\|renew-days 8[0-9]" \
/etc/cron.d/ /etc/cron.daily/ /etc/letsencrypt/renewal/ ~/.acme.sh/ /etc/systemd/system/If you get hits, remove the explicit value and let the client default (ARI-driven on modern versions) or replace it with a fraction-based interval — two-thirds of cert lifetime is the recommended heuristic. For 64-day certs that’s day 43. For the 45-day certs coming in 2028, that’s day 30.
If you run cert-manager in Kubernetes, check whether your version has ARI support. The CNCF project has been slower to adopt it and many cluster deployments still use fixed-day configuration in CertificateRequest specs.
The Bigger Picture
This is not a one-off. Let’s Encrypt is following a CA/Browser Forum mandate that shortens maximum certificate lifetimes on a fixed schedule:
- February 10, 2027 — 64-day default; authorization reuse drops from 30 days to 10
- February 16, 2028 — 45-day default; authorization reuse drops to 7 hours
- March 2029 — CA/Browser Forum Ballot SC-081 caps the industry at 47 days
The 7-hour authorization reuse window in 2028 is the next serious inflection. It effectively eliminates the ability to batch-authenticate a domain once and forget it. Everything will need to re-verify domain control on every renewal cycle. That’s only achievable with proper ACME DNS or HTTP challenge automation.
The security case is sound. TLS revocation — CRL, OCSP — is unreliable across browsers in practice. The only proven way to limit the blast radius of a compromised key or mis-issued certificate is to make certificates short-lived. Let’s Encrypt and the CA/Browser Forum are right to push this. The inconvenience falls entirely on operators who were never properly automating to begin with.
If you’re running manual renewal cron jobs with hardcoded days, February 10 is the forcing function you needed. Fix it now, use the staging window to test, and you’re done. Let the 2028 reduction hit a system that already does this correctly.
