Let's Encrypt to shorten cert lifetimes in 2027

Certificate lifetimes have been shrinking for years, and Let's Encrypt is about to shorten them again. According to the company, free SSL/TLS certificates will drop from 90 days to 64 days beginning February 10, 2027. Administrators running modern ACME clients that support ARI will barely notice the shift. Everyone else has a deadline to meet.

The change is the next step in a long-running effort by Let's Encrypt to push automated certificate management into the mainstream. For organizations still renewing on fixed schedules or by hand, February 2027 is when the math stops working in their favor.

Testing begins in October

Before the 64-day certificates go into production, Let's Encrypt will run a testing period. Starting October 14, the company will begin issuing 64-day certificates for those who opt in, giving administrators a chance to try their setups against the shorter window before the change becomes mandatory.

The opt-in approach means nobody is forced to test. But it also means the administrators most likely to be caught off guard when February 2027 arrives are the ones who skip the trial run. The testing period is designed to surface renewal problems while there's still time to fix them.

Let's Encrypt has framed the change as a continuation of its original mission rather than a reaction to any particular incident. Shorter lifetimes reduce the window in which a stolen or misissued certificate can cause harm.

Why 90 days became 64

When Let's Encrypt launched in early 2016, it broke with the norms of the time. Prior to that launch, certificates were often issued for as long as one to three years. The service started with 90-day certificates specifically to force renewal automation that didn't previously exist, and to encourage accelerated HTTPS adoption across the web.

That decision shook industry norms at the time. By limiting the certificate lifetime, the certificates are less likely to cause damage if they are compromised or assigned in error. The move down to 64 days continues this logic.

It won't stop there. According to Let's Encrypt, lifespans will keep getting shorter, with 45-day defaults planned to follow in 2028. Administrators who treat the 64-day change as a one-time adjustment may find themselves revisiting their renewal scripts again soon.

The hardcoded offset problem

The 90-day certificate window has produced a generation of renewal scripts built around fixed offsets. A common pattern is to renew at some point before expiration, and those offsets are frequently written directly into configuration files or cron jobs.

Let's Encrypt is getting the information out now to warn those users to audit their cron jobs and runbooks so they renew at two-thirds their lifespan. The change is intended to move users to full ACME automation, the same way the initial rollout aimed to push users toward HTTPS.

The ACME protocol, and more specifically ARI, allows the certificate authority to tell the client when it's time to renew. Even so, many deployments are still stuck on scripted update intervals that trigger at fixed offsets like "60 days before expiration."

Let's Encrypt is also compressing validation timelines. Authorization reuse periods will shrink from 30 days to 10 days, and eventually 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.

What administrators should do now

Let's Encrypt's guidance for administrators is specific. The company recommends users search for hardcoded renewal numbers like 83, 80, and 60, which were common previous renewal targets for 90-day certificates, and update them to renew prior to expiration at the new 64-day limit.

Beyond updating the numbers, the company's recommendations include verifying that your ACME client supports ARI, and updating renewal scripts if it does not. Administrators should also ensure notifications are set in the event of certificate expiration or renewal failures.

Let's Encrypt also recommends taking advantage of the October 14 testing period before the official rollout. Testing against the 64-day certificates surfaces problems while there's still time to correct them.

The steps break down into a short checklist:

• Search scripts and configuration files for hardcoded renewal offsets such as 83, 80, and 60, then update them for the 64-day lifetime.
• Verify that your ACME client supports ARI, and update renewal scripts if it does not.
• Set notifications for certificate expiration or renewal failures.
• Use the October 14 testing period before the official rollout.

The compliance window

The practical effect of the change depends heavily on what an administrator is already running. Let's Encrypt says that for administrators already implementing modern ACME clients that support ARI, the change should be seamless.

For those still relying on hardcoded renewal schedules or manual processes, February 2027 is the deadline to update before certificates start expiring unexpectedly. The company's warning is aimed squarely at that group.

There is a testing window before the production change takes effect. Administrators who take part in the October 14 testing period can find and fix problems before the 64-day certificates become the default.

What 64 days means in practice

A 64-day certificate is not functionally different from a 90-day certificate. The cryptography is the same. What changes is how often the renewal machinery has to work correctly, and how much slack exists when it doesn't.

That is the entire point of shorter lifetimes. By limiting the certificate lifetime, Let's Encrypt reduces the damage a certificate can do if it is compromised or assigned in error. The tradeoff is that renewal becomes a more frequent operation, which raises the cost of any process that depends on human intervention or fixed scheduling.

The authorization reuse change compounds the pressure. Let's Encrypt says reuse periods will shrink from 30 days to 10 days, and eventually to seven hours by 2028. Most operators won't notice unless their ACME clients depend on cached validation data.

The company's stated goal is to push users toward full ACME automation, where the certificate authority decides when renewal happens rather than an operator-maintained schedule.

The 2028 horizon

The 64-day change is not the end of the roadmap. Let's Encrypt has said that 45-day defaults are planned to follow in 2028, along with authorization reuse periods that drop to seven hours.

For administrators, that means any fix built specifically around the 64-day number is a temporary one. The renewal logic that survives the next few years is the logic that asks the certificate authority when to renew, rather than counting days locally.

The company is getting this information out well ahead of the February 2027 date, which is the clearest signal that it expects administrators to need the runway. The warning about auditing cron jobs and runbooks is directed at anyone whose renewal process is not already ARI-aware.

Why it matters

The immediate implication for organizations is operational rather than cryptographic. Certificates that fail to renew cause outages, and outages caused by expired certificates are entirely preventable. This could mean that administrators who put off the audit until February 2027 find themselves troubleshooting an expired certificate on a production system instead of testing a renewal script in October.

For the broader web, the change suggests a continued shift toward automated certificate management as the default rather than an advanced practice. If the 2028 roadmap holds, certificate lifetimes will have dropped from 90 days to 45 days in roughly two years, a pace that leaves little room for manual renewal processes. Businesses that rely on websites, APIs, or internal services secured by Let's Encrypt certificates may want to confirm now that their renewal automation is handled by something that asks the certificate authority when to renew, not by a schedule someone set years ago and has not touched since.