Let’s Encrypt cuts certificate lifetimes to 64 days starting February 2027





Automation Required

Let’s Encrypt cuts certificate lifetimes to 64 days starting February 2027

Free SSL/TLS certificate lifetimes reduce to 64 days in February.


Nick Indge

–


|

5



Illustration of a padlock over a glowing digital data panel.

64-Day Certificate Lifetimes Coming Feb 2027


Credit:

Getty Images | Yuichiro Chino

64-Day Certificate Lifetimes Coming Feb 2027


Credit:

Getty Images | Yuichiro Chino




Story text








Let’s Encrypt is continuing a push toward tighter security by reducing free SSL/TLS certificate lifetimes from 90 days to 64 days, starting on February 10, 2027. For administrators already implementing modern ACME clients that support ARI (ACME Renewal Information), the change should be seamless. For those still relying on hardcoded renewal schedules or manual processes, next February will be the deadline to update before certificates start expiring unexpectedly.

Starting on October 14, 2026, Let’s Encrypt will begin testing the 64-day certificates, and interested users can opt-in to test their setups before production goes live.

Prior to Let’s Encrypt’s launch in early 2016, certificates were often issued for as long as one to three years. The service started with 90-day certificates to force renewal automation that didn’t previously exist. Shorter certificate validity periods limited vulnerabilities from private key thefts and encouraged accelerated HTTPS adoption across the web.

This move was a bit of a shakeup to industry norms at the time, but by limiting the certificate lifetime, the certs are less likely to cause damage if compromised or assigned in error. The move down to 64 days continues this logic, and the lifespans will only continue to get shorter as time goes on, with 45-day defaults planned to follow in 2028.

Just as the initial rollout of Let’s Encrypt aimed to push users toward HTTPS, the shortened certificate windows are aimed at moving users to full ACME automation. The ACME protocol, and, more specifically, ARI (ACME Renewal Information), allows the certificate authority to tell the client when it’s time to renew. Although ARI does this, many deployments are still stuck on scripted update intervals that trigger at fixed offsets like “60 days before expiration.”

Let’s Encrypt is getting this information out now to warn these users to audit their cron jobs and runbooks to automatically renew at two-thirds their lifespan and, in doing so, prepare for the additional shrinkage of 45 day certificates planned for 2028.

What web administrators can do now

  • The company specifically recommends users search for hardcoded renewal numbers like 83, 80, and 60 (common previous renewal targets for 90 day certificates) and update them to renew prior to expiration at the new 64-day limit.
  • Verify your ACME client supports ARI; if not, update renewal scripts.
  • Ensure notifications are set in the event of certificate expiration or renewal failures
  • Take advantage of the October 14, 2026, testing period before the official rollout.

Alongside certificate lifetimes, Let’s Encrypt is also compressing validation timelines. Authorization reuse periods will be shrinking from 30 days down to 10 days, and eventually all the way down to seven hours by 2028. This step should eliminate the need for CAA rechecks. Most operators won’t notice the change unless their ACME clients depend on cached validation data.

Administrators will have roughly four months to test their renewal automations before the February 10, 2027, deadline or face potential downtime when the deadline arrives.

Photo of Nick Indge


Nick Indge

Senior Technology Reporter
Nick Indge is a Senior Technology Reporter at Ars Technica covering hardware, embedded systems, and self-hosted infrastructure. A former security investigator turned tech writer, he writes to help readers escape subscription traps and regain ownership of their digital lives. He lives in Chicagoland with his family and a goofball husky.


5 Comments

Leer artículo original en Ars Technica