Let’s Encrypt 64-day certificates will replace 90-day certificates for new and renewed default classic profile orders on February 10, 2027. Web hosts and agencies should remove fixed renewal intervals, confirm ACME Renewal Information support, automate deployment and service reloads, and test the complete workflow in staging. Existing certificates won’t be revoked, but brittle automation could leave sites with expired HTTPS certificates.
When will Let’s Encrypt 64-day certificates take effect?
Let’s Encrypt 64-day certificates take effect for certificates issued or renewed under the default classic ACME profile on February 10, 2027. According to Let’s Encrypt’s October 7, 2026 announcement, existing valid certificates will remain valid, and the organization expects the last 90-day default certificate to expire on May 11, 2027.
The production change doesn’t modify Let’s Encrypt’s ACME endpoints or certificate issuance chains, according to the same 2026 announcement. A modern ACME client should therefore keep communicating with the certificate authority. The operational risk lies elsewhere: renewal timing, domain validation, certificate installation, web-server reloads and failure alerts.
Let’s Encrypt plans another reduction on February 16, 2028, when default classic certificates are scheduled to fall to 45 days. The authorization-reuse period will shrink from 30 days to 10 days on February 10, 2027, then to seven hours on February 16, 2028. More renewals will consequently require fresh domain validation.
The direction is broader than one certificate authority. CA/Browser Forum requirements will cap publicly trusted subscriber certificates at 47 days beginning March 15, 2029, while Let’s Encrypt selected 45 days as its target. Shorter lifetimes reduce the period in which a compromised key or mistakenly issued certificate remains useful, Let’s Encrypt said in 2026.
Why can fixed renewal scripts fail after the change?
Fixed renewal scripts can fail with Let’s Encrypt 64-day certificates when they assume every certificate lasts 90 days or wait 60 days before attempting renewal. A 60-day delay leaves only four days of validity in 2027, sharply reducing the time available to recover from failed validation, deployment or service reloads.
The calculation exposes the danger. Under the 2026-era 90-day lifetime, renewing on day 60 leaves 30 days of recovery time. Under the 64-day lifetime beginning in 2027, the same schedule leaves four days. When 45-day certificates become the default in 2028, a script that waits 60 days won’t run until 15 days after expiration.
Let’s Encrypt specifically advised fleet operators in October 2026 to search cron jobs, wrapper scripts and runbooks for hard-coded values such as 83, 80 or 60 days. Also inspect configuration-management templates, hosting-panel defaults, systemd timers, CI pipelines and documentation copied between customers. The forgotten runbook is often more dangerous than the visible cron entry.
One edge case deserves attention: a renewal command can succeed while the website still serves the old certificate. The new files may have been written correctly, but Nginx, Apache, HAProxy or another TLS endpoint won’t necessarily load them without a successful reload. Honestly, renewal monitoring that ignores the certificate presented over the network is only half a monitoring system.
Security weaknesses elsewhere can complicate fleet operations too. Agencies managing WordPress estates should treat certificate automation as one layer alongside patching issues such as an Elementor vulnerability that could create rogue administrators and controlling the dependency risks introduced by AI-generated code.
How should ACME clients decide when to renew?
ACME clients should use ACME Renewal Information when supported, because ARI allows the certificate authority to provide a suggested renewal window. For systems without ARI, Let’s Encrypt’s October 2026 guidance recommends renewal at approximately two-thirds of each certificate’s actual lifetime rather than a fixed number of days before expiration.
ACME Renewal Information is an ACME mechanism that lets a certificate authority tell a client when to renew a specific certificate. ARI became IETF Standards Track RFC 9773 in June 2025. It replaces guesswork based on an assumed lifetime with server-provided timing that can distribute demand and support changing certificate policies.
For a 64-day certificate in 2027, the two-thirds fallback places the renewal attempt around day 42.7, leaving roughly 21.3 days before expiration. For a 45-day certificate in 2028, the same rule gives day 30 and leaves 15 days. Those windows provide far more recovery time than a fixed day-60 job.
| Certificate profile or period | Lifetime | Two-thirds renewal point | Validity remaining |
|---|---|---|---|
| Default classic before February 10, 2027 | 90 days | Day 60 | 30 days |
| Default classic from February 10, 2027 | 64 days | About day 43 | About 21 days |
| Default classic planned from February 16, 2028 | 45 days | Day 30 | 15 days |
| Opt-in shortlived profile documented September 2026 | About 160 hours | About 107 hours | About 53 hours |
Check every ACME client version and every hosting control panel separately. One modern client on an administrator’s laptop doesn’t prove that an older server image, appliance or panel integration supports ARI. Ask vendors for the exact version that implements RFC 9773, then verify behavior from logs rather than relying on a checkbox.
Does Certbot handle the shorter certificate lifetime?
Certbot 4.0.0 and later uses proportional renewal timing suitable for Let’s Encrypt 64-day certificates. According to Certbot’s documentation available on October 13, 2026, Certbot treats a certificate as ready for renewal when less than one-third of its lifetime remains; certificates lasting 10 days or less use a one-half-lifetime threshold.
You can run certbot renew frequently because the command checks eligibility before requesting a certificate. Certbot also supports pre-hooks, post-hooks and deploy-hooks, while --dry-run performs a staging-based renewal test. A deploy-hook is the appropriate place for actions that should occur only after a successful renewal, such as reloading Nginx.
Don’t assume every Certbot installation is automatic. Certificates created with the --manual plugin won’t renew unattended unless automated authentication hooks have been configured, according to Certbot’s 2026 documentation. DNS challenges are especially prone to hidden manual steps when a provider lacks an API integration or credentials have expired.
Review privilege boundaries as well. Renewal jobs may need access to DNS API tokens, certificate directories and reload commands, but broad credentials increase the impact of a compromised host. The same principle appears in wider infrastructure threats, including the Carbonato botnet’s targeting of Docker hosts: automation credentials deserve narrow permissions and active monitoring.
A safe migration checklist for hosting fleets
A safe migration for Let’s Encrypt 64-day certificates must test discovery, validation, issuance, deployment, service reload and external verification as one workflow. Let’s Encrypt is scheduled to move its staging environment to 64-day default certificates on October 14, 2026, giving hosting teams time to test before the production transition on February 10, 2027.
Use the following sequence across a representative sample before expanding the test to every customer site:
- Inventory certificate paths and owners. Record each hostname, ACME client and version, profile, challenge type, DNS provider, installation path, TLS endpoint and responsible team in 2026.
- Find fixed timing assumptions. Search scripts, cron jobs, systemd timers, control-panel settings and runbooks for 90-day arithmetic and values such as 83, 80 or 60 days identified by Let’s Encrypt in 2026.
- Confirm ARI or proportional renewal. Verify RFC 9773 support from client documentation and logs. Where ARI is unavailable, calculate the trigger from the certificate’s actual lifetime.
- Test against staging. Run the complete validation and deployment flow after October 14, 2026. Let’s Encrypt staging certificates are not publicly trusted and use separate, higher rate limits intended for testing and debugging.
- Exercise deployment hooks. Confirm file permissions, certificate-chain placement and successful reloads for Nginx, Apache, HAProxy, mail servers, load balancers and any CDN or proxy under your control.
- Verify from outside the host. Connect to every public hostname and inspect the certificate actually served, including expiry, issuer and Subject Alternative Names. Local files alone don’t prove deployment.
- Alert with enough recovery time. Monitor failed renewal jobs and served-certificate expiry. Route alerts to a staffed channel, assign ownership and test escalation before February 10, 2027.
Start with awkward sites, not the easy ones: wildcard certificates, split-horizon DNS, multi-region proxies, manual DNS challenges and servers with several TLS termination layers. At fleet scale, sample testing isn’t enough if customer configurations differ. A site behind a load balancer can pass a local check while one backend or edge location continues serving stale material.
Rate limits shouldn’t justify delaying the work. Let’s Encrypt stated on February 24, 2026 that renewals remain exempt from issuance rate limits, so shorter lifetimes don’t require larger subscriber rate-limit allocations. Staging remains the safer place for repeated debugging because its certificates are untrusted and its limits are designed for tests.
Frequently asked questions
Will existing 90-day Let’s Encrypt certificates be revoked?
Existing 90-day Let’s Encrypt certificates won’t be revoked solely because of the 2027 lifetime transition, according to Let’s Encrypt’s October 7, 2026 announcement. Let’s Encrypt expects the final default-profile 90-day certificate to expire on May 11, 2027.
Do Let’s Encrypt ACME URLs change in February 2027?
Let’s Encrypt ACME endpoints and issuance chains won’t change as part of the February 10, 2027 move to 64-day default certificates, according to the certificate authority’s 2026 operational notice.
How long do Let’s Encrypt short-lived certificates last?
Let’s Encrypt documented the opt-in shortlived profile as lasting approximately 160 hours, or about 6.7 days, on September 8, 2026. The opt-in tlsserver profile provides 45-day certificates.
Can I use a Let’s Encrypt staging certificate on a public website?
Let’s Encrypt staging certificates aren’t publicly trusted, according to the organization’s 2026 glossary. Use staging to test issuance, validation, deployment and reload automation, then return the ACME client to the production environment for a browser-trusted certificate.