Let's Encrypt is about to make a quiet operational assumption expire. On February 10, 2027, its default certificates will move from 90-day lifetimes to 64 days. The first 64-day test certificates arrive in the staging environment on October 14, giving operators four months to discover whether their automation follows the certificate authority or merely remembers the old calendar.

The change, covered by Ars Technica and detailed by Let's Encrypt, applies to certificates issued or renewed on and after the production date. Existing 90-day certificates will not be revoked. The last of them should age out by May 11, 2027.

For a modern ACME client, 64 is just new input. For a hand-built script that says "renew when 60 days remain," it is nearly the entire lifetime. The security gain comes from a shorter window of trust. The reliability test is whether renewal was ever truly automated.

A certificate timer should be data from the issuer, not a number fossilized in a cron job.

The Lifetime Bounds A Trust Statement

A TLS certificate binds a public key to one or more names for a defined period. It does not keep a private key secret, and expiry does not erase a stolen key. A shorter lifetime limits how long browsers and other relying parties will accept that certificate if the key is compromised or the certificate was issued incorrectly.

That is why the industry has been moving away from year-long certificates. Let's Encrypt started with 90 days in 2016, making automated renewal a practical requirement instead of an optional convenience. The next steps tighten the same loop. Its default classic profile moves to 64 days in February 2027 and 45 days on February 16, 2028. Subscribers may already select shorter profiles where supported.

The broader direction is not unique to one certificate authority. CA/Browser Forum requirements are stepping maximum publicly trusted certificate lifetimes down, eventually reaching 47 days for certificates issued from March 15, 2029. Let's Encrypt's 45-day target fits inside that ceiling and arrives earlier.

Shorter certificates reduce exposure, but they also multiply routine operations. Moving from renewal around day 60 of a 90-day certificate to around day 30 of a 45-day certificate roughly doubles steady renewal volume. The issuer has to spread that load. Operators have to prove that issuance, deployment, reload, and monitoring all work without a person shepherding each cycle.

ARI Replaces Calendar Arithmetic

ACME already automates certificate orders and domain validation. Its Renewal Information extension, standardized as RFC 9773, closes a scheduling gap. An ACME server can publish a renewalInfo endpoint and return a suggested window for a particular certificate. A supporting client chooses a time inside that window, normally with randomization, and renews there.

ACME directory
  -> advertises renewalInfo endpoint

client + current certificate
  -> requests renewal information
  <- receives suggestedWindow { start, end }

client
  -> chooses a randomized time in the window
  -> renews, deploys, and reports the replacement
ARI lets the issuer communicate a moving renewal window instead of forcing every client to guess from the expiry date.

This is more than convenience. The certificate authority can distribute renewals across time rather than watching millions of clients converge on the same fraction of a lifetime. It can move a window earlier before a planned mass revocation or other exceptional event. The client still needs fallback timing, retry backoff, and a healthy clock, but the issuer gains a control channel for the schedule.

Let's Encrypt says operators whose ACME clients support ARI should be ready for the 64-day change. Everyone else should avoid fixed day counts and renew after roughly two thirds of the actual certificate lifetime has elapsed. That calculation survives a move from 90 to 64 to 45 days. The better long-term answer is a client that consumes ARI directly.

Renewal Is Not The Same As Deployment

Obtaining a certificate is only the first half of rotation. The new key and certificate have to reach every TLS endpoint, the service has to reload them, and an external check has to confirm that clients receive the new chain. A pipeline that successfully writes files to disk but never reloads a proxy is not automated renewal. It is automated inventory.

The failure modes tend to hide in glue:

  • A cron expression runs less often than the new renewal window expects.
  • A wrapper script searches for exactly 60 days remaining and never matches a 64-day certificate safely.
  • A certificate is renewed on one host but not copied to a load balancer, appliance, or secondary region.
  • A service reload fails, while the ACME client still reports a successful order.
  • Monitoring checks that a certificate file exists rather than inspecting what the public endpoint actually serves.

Those defects may have survived for years because a 90-day certificate left a generous interval between the expected renewal date and expiry. A shorter lifetime compresses that recovery margin. It does not create the bug; it makes the old assumption easier to reach.

Search configuration and runbooks for numbers such as 83, 80, and 60, the specific hard-coded offsets Let's Encrypt calls out. Also search for absolute schedules that do not inspect the certificate at all. A daily ACME timer can be perfectly reasonable when the client decides whether work is due. A monthly timer that assumes the certificate shape is not.

Validation Gets A Shorter Memory Too

The certificate lifetime is not the only clock changing. Let's Encrypt will reduce its authorization reuse period from 30 days to 10 days with the February transition, then to seven hours in 2028. Authorization reuse is how long a previous proof of domain control may remain usable for another issuance.

A shorter reuse period means the system asks for fresher evidence that the requester still controls the name. Most ordinary ACME clients should handle this without special work because they already know how to perform the HTTP, DNS, or TLS challenge again. Custom issuance platforms that deliberately rely on cached authorizations need closer inspection.

The distinction is useful: certificate validity tells relying parties how long to trust an issued binding, while authorization reuse tells the certificate authority how long it may rely on an earlier validation. Shortening both reduces stale trust at different stages of the system.

The October 14 Test Should Exercise The Whole Path

Staging exists to find operational mistakes without risking a production name. A useful test should request the 64-day certificate, observe the lifetime, follow the client's renewal decision, deploy a replacement, reload the serving process, and verify the result from outside the host. Merely proving that the ACME order endpoint returns success leaves the most failure-prone steps untouched.

Operators should record evidence for each layer:

issue    - ACME order completes with the expected identifiers
store    - new key and certificate land with correct ownership
deploy   - every endpoint receives the replacement
reload   - the serving process adopts it without interruption
observe  - public probes see the new serial and expiry
alert    - a forced renewal failure pages before the safety margin closes
Short lifetimes are safe when rotation is a verified control loop rather than a successful command.

Testing failure matters as much as testing success. Block a challenge temporarily, break a staging deploy hook, or deny a reload in a disposable environment. Confirm that retries use backoff, the old certificate remains served, and alerting identifies the stuck stage. A green ACME log should not be the only signal between a site and expiry.

Large fleets should also check renewal distribution. ARI clients choose times within issuer-provided windows, which helps avoid synchronized traffic. Homegrown tooling that renews every certificate at midnight may work at small scale and create its own incident at large scale.

Rate Limits Are Not The New Bottleneck

More frequent renewal naturally raises a concern about issuance limits. Let's Encrypt says its rate limits will not change for this transition because renewals for existing names are exempt from the limits governing new names and new orders. That does not make retries free of operational cost, but it means a healthy fleet should not need a larger allowance simply because certificates are shorter.

The practical bottleneck is distribution. Certificates may terminate at ingress controllers, reverse proxies, CDN edges, VPN gateways, mail servers, embedded appliances, and vendor-managed load balancers. The least automated endpoint determines the real rotation capability of the organization.

Inventory therefore matters more than any one ACME command. For each public certificate, operators should know who requests it, where its private key lives, which services consume it, how those services reload, what probe checks the public result, and which alert fires when the next renewal misses its window.

Short Certificates Reward Boring Systems

The move to 64 days is an intermediate step, not a finish line. That is useful. It gives brittle systems a visible deadline before 45-day defaults arrive in 2028, while giving mature systems a staging event that should look uneventful.

The security argument for shorter lifetimes is straightforward: reduce how long a compromised or mistaken credential remains naturally valid. The engineering argument is more interesting. Trust should be continuously renewable, observable, and replaceable. A certificate is no longer a document installed once a year. It is output from a small distributed system.

On February 10, good automation will read a new lifetime, accept an issuer-suggested window, rotate the certificate, reload the service, and confirm the public result. Nothing dramatic will happen. That absence of drama is the feature Let's Encrypt has spent a decade teaching the Web to build.

Sources