Let’s Encrypt, the world’s most widely used certificate authority for HTTPS, is preparing to halve the lifetime of its certificates — again.
By 2028, all standard Let’s Encrypt certificates will be limited to a maximum validity of 45 days, down from today’s 90 days.
This isn’t just a Let’s Encrypt experiment. It’s part of an industry-wide shift being driven by the CA/Browser Forum, the standards body that coordinates rules between browser vendors and certificate authorities. Following an earlier proposal from Apple, the Forum has agreed that publicly trusted certificates (except roots) will be capped at 47 days. Let’s Encrypt is aligning with that requirement and tightening its own policies along the way.
For operators, DevOps teams and SREs, the message is clear:
Short-lived certificates are the future, and robust, fully automated renewal is no longer optional.
From 90 Days to 45: The New Lifetime Roadmap
Let’s Encrypt currently issues certificates with a 90-day validity. These will be phased down over several stages, giving the ecosystem a few years to adapt:
Phase 1 – Optional testing profile (May 13, 2026)
- The opt-in
tlsserverACME profile will start issuing certificates with a 45-day lifetime. - This is targeted at early adopters and test environments that want to validate their tooling before the stricter limits apply globally.
Phase 2 – Shorter default lifetime (February 10, 2027)
- The default “classic” ACME profile — the one most users rely on — will switch to 64-day certificates.
- The authorization reuse period (how long a domain validation can be reused) will drop to 10 days.
Phase 3 – Final 45-day limit (February 16, 2028)
- The classic profile will be updated again to issue 45-day certificates.
- The authorization reuse window will shrink dramatically to 7 hours.
From that point on, every newly issued Let’s Encrypt certificate will effectively be short-lived. Users will encounter the new lifetimes at their next renewal after each phase kicks in.
Domain Authorization: From 30 Days to 7 Hours
Lifetime isn’t the only thing shrinking. Let’s Encrypt is also cutting the amount of time you can reuse a domain validation.
Today:
- Once a client proves control of a domain (via HTTP-01, TLS-ALPN-01 or DNS-01), that authorization can be reused for up to 30 days to issue certificates for that domain.
By 2028:
- That authorization reuse period drops to just 7 hours.
Practically, that means:
- If your ACME client validates a domain but doesn’t actually obtain the certificate within that 7-hour window, it will need to re-validate the domain.
- Any brittle or time-sensitive issuance workflows will be exposed quickly.
For modern ACME clients with continuous, automated operation, this shouldn’t be a problem. For manual or semi-manual setups, it’s a serious red flag.
Why the Industry Is Pushing Short-Lived Certificates
From a security and PKI standpoint, shorter lifetimes solve several long-standing problems:
- Reduced impact of key compromise
If a private key leaks, an attacker can impersonate a site only until the certificate expires. Shorter lifetimes cap that window by design, even if revocation checks fail or are bypassed. - Less dependence on unreliable revocation mechanisms
CRLs and OCSP have been criticized for years: they’re complex, slow, and not consistently enforced by clients. Shorter-lived certs mean less pressure on those mechanisms and fewer “zombie” certificates lingering after compromise. - More frequent key rotation becomes normal
With 45-day certs, rotation effectively becomes continuous. That aligns with modern security practices in cloud and microservice environments where credentials are treated as short-lived artifacts, not static assets.
In other words, the move increases operational pressure but raises the security baseline of the public web.
ACME Renewal Information (ARI): Let the CA Tell You When to Renew
To prevent the new limits from turning into a nightmare of failed renewals, Let’s Encrypt is encouraging adoption of ACME Renewal Information (ARI).
ARI allows the CA to signal to the ACME client when a given certificate should be renewed, instead of the client hard-coding renewal logic like “always renew after 60 days.”
In the 45-day world, that kind of static schedule is dangerous:
- A renewal interval of 60 days will simply miss the window and let certificates expire.
- A safer approach is to renew around two-thirds of the way through the lifetime (≈ day 30 for 45-day certs), or better yet, to follow ARI signals from the CA.
For operators, concrete actions include:
- Checking whether their chosen ACME client (Certbot, acme.sh, built-in support in control panels, etc.) already supports ARI.
- Enabling ARI once available and avoiding hard-coded renewal intervals that assume 90-day validity.
Manual Renewals Are Effectively Dead
Let’s Encrypt is blunt on this point: manual renewals are strongly discouraged.
With 45-day certificates and tighter validation windows, manual processes become:
- More frequent
- More error-prone
- More likely to cause outages
In practice, any environment that still depends on a human logging in and clicking “renew” is now a candidate for unexpected certificate expiry and browser warnings like “Your connection is not private.”
The only realistic strategy going forward is:
- Fully automated issuance and renewal, including deployment to web servers, load balancers, proxies and APIs.
- Monitoring and alerting around certificate expiry and renewal failures, rather than waiting for users to report problems.
DNS-PERSIST-01: Making DNS-Based Automation Less Painful
One of the friction points in ACME automation has always been domain control validation. All existing methods require the ACME client to interact with infrastructure in real time:
- HTTP-01: Serve a specific token over HTTP.
- TLS-ALPN-01: Perform a special TLS handshake.
- DNS-01: Create or update TXT records in DNS.
For organizations that don’t want to give automated tools broad access to web servers or DNS management, this can be a serious hurdle.
To address that, Let’s Encrypt and its partners are working on a new method called DNS-PERSIST-01:
- A single persistent TXT record can be set in DNS to prove domain control.
- That record does not need to change at each renewal.
- Once configured, certificates can be renewed automatically without further DNS updates.
Let’s Encrypt expects DNS-PERSIST-01 to be available around 2026, which should make it easier for more conservative environments to adopt full automation without exposing DNS or web servers to frequent automated changes.
What This Means for Operators and Platforms
For a tech audience — hosting providers, SaaS vendors, DevOps teams, platform engineers — the implications are clear:
- If you already use ACME-based, fully automated issuance and renewal, you’re in good shape, but you should:
- Verify that renewal logic doesn’t rely on 60-day timers.
- Track ARI support in your client and enable it when possible.
- If you’re still doing manual renewals or semi-manual workflows, you’re on borrowed time. The combination of 45-day lifetimes and 7-hour authorization reuse will expose every weak spot in those processes.
- If you run a platform that automates HTTPS for your users, you will need to:
- Confirm your ACME clients handle shorter lifetimes and tighter validation windows.
- Strengthen monitoring and observability around certificate status and failed renewals.
The upside: once the ecosystem has fully adapted, the public TLS layer of the internet will be more resilient, less exposed to long-term key compromise, and easier to reason about from a security standpoint.
In short, Let’s Encrypt’s move to 45-day certificates is not just a policy tweak — it’s a structural change in how the web handles trust, identity and encryption at scale.