Let's Encrypt 45-Day Certificates: Timeline and How to Prepare

Introduction#

Let's Encrypt is cutting its certificate lifetime from 90 days to 45. The change is phased in between 2026 and 2028, and it isn't only a Let's Encrypt decision: the CA/Browser Forum has already voted to cap every publicly trusted TLS certificate at 47 days by March 2029. For teams that manage hundreds or thousands of domains, renewal stops being a periodic chore and becomes something that has to run on its own.

If your team still handles SSL renewals manually, you're about to feel the pressure. What was four renewal cycles per year becomes eight. What was a manageable quarterly task becomes a perpetual operational burden. The timeline is already in motion, and infrastructure teams that prepare now will navigate the transition smoothly. Those that don't will face increased outage risk and mounting operational overhead.

This guide covers the exact dates, what changes for renewals, how ACME automation compares with manual certificate management, and a checklist for redirect and parked domains, which are the certificates most often forgotten.

The announcement: Let's Encrypt moves from 90-day to 45-day certificates#

In December 2025, Let's Encrypt announced that it will shorten certificate lifetimes from 90 days to 45 days in stages, and shorten how long a domain validation (authorization) can be reused. The changes apply to newly issued certificates, so you see the shorter lifetime at your next renewal after each date.

Let's Encrypt has issued 90-day certificates since it launched, at a time when most commercial certificates lasted a year or more. Short lifetimes were meant to push everyone toward automation. The move to 45 days continues that, and it lines up with the industry-wide schedule below.

The practical impact is straightforward: every domain secured by Let's Encrypt will need certificate renewal twice as often. For organizations that have already automated their renewal process, the transition may be seamless. For teams relying on manual processes or semi-automated workflows, the operational impact will be significant.

Why It's Happening: Security Best Practice — Limiting the Window of Compromise#

Shorter certificate lifetimes are fundamentally a security improvement. Every TLS certificate represents a potential attack vector. If a certificate's private key is compromised, an attacker can impersonate the legitimate domain until the certificate expires or is revoked. The longer the certificate lifetime, the longer that window of compromise remains open.

Forty-five-day certificates shrink that window by half compared to the current 90-day standard. If a key is compromised on day one, the maximum exposure is 45 days instead of 90. In practice, the exposure is typically shorter, but the ceiling matters — especially for organizations that may not detect a compromise immediately.

There's also a revocation argument. Certificate revocation through CRLs and OCSP has historically been unreliable. Browsers don't always check revocation status consistently, and revoked certificates sometimes continue to be trusted. Shorter lifetimes reduce reliance on revocation infrastructure. If a certificate only lives 45 days, revoking it becomes less critical — it expires soon anyway.

The security community has long advocated for shorter certificate lifetimes. Let's Encrypt's move operationalizes what security researchers have been recommending for years.

It isn't just Let's Encrypt: the CA/Browser Forum's 47-day rule#

In 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for public TLS certificates, adopted ballot SC-081v3. It lowers the maximum lifetime of every publicly trusted certificate, from every CA including DigiCert, Sectigo and GlobalSign, in three steps, and shortens how long domain validation can be reused:

So if you buy one-year commercial certificates today, those are already capped at 200 days, and they'll follow the same path down to 47. Short lifetimes are now the rule for the whole web, not a quirk of one free CA.

Let's Encrypt timeline: the dates that matter#

Each change reaches the Let's Encrypt staging environment about a month before production, so you can test your setup against it first.

The 7-hour authorization reuse is the change that catches people out. Today, a domain validated once can be reissued for weeks without validating again. From 2028, nearly every renewal needs a fresh validation, so the DNS record or HTTP challenge must still work at renewal time, not just on the day you set the domain up.

Let's Encrypt also offers a shortlived profile with 6-day certificates for teams that want to go further.

The practical deadline is your renewal schedule. Let's Encrypt says a fixed 60-day renewal interval is no longer enough. Use ACME Renewal Information (ARI) if your client supports it, which lets the CA tell you when to renew; if it doesn't, renew at about two-thirds of the certificate's lifetime.

What 45 Days Actually Means: 8 Renewal Cycles Per Year vs Current 4#

The math is simple but the operational impact is not. Moving from 90-day to 45-day certificates means:

Renewal frequency doubles. Instead of four renewal cycles per year per domain, you're handling eight. For a team managing 100 domains, that's 800 renewal events annually instead of 400. For teams managing thousands of domains, the numbers become unmanageable without full automation.

Renewal windows shrink. With 90-day certificates, renewing 30 days before expiry leaves a comfortable buffer. With 45-day certificates, renewing at two-thirds of the lifetime leaves about 15 days to notice and fix a failure.

Failure tolerance decreases. With 90-day certificates, a renewal failure gives you weeks to investigate and resolve before expiration. With 45-day certificates, you have days. Every renewal failure is more urgent, and your monitoring needs to be more responsive.

Rate limiting becomes a concern. Let's Encrypt enforces rate limits on certificate issuance. Doubling renewal frequency means you're consuming twice the rate limit budget. Teams near their limits on 90-day certificates may hit them on 45-day certificates and need to adjust their issuance patterns.

The bottom line: manual or semi-automated renewal processes that barely worked at 90 days will fail at 45 days. Full automation is no longer optional.

Who This Affects Most: Teams Managing 100+ Domains with Manual SSL Processes#

The 45-day certificate era doesn't affect everyone equally. Here's who feels the biggest impact:

Domain investors and portfolio managers. Teams managing hundreds or thousands of parked, redirected, or monetized domains face the largest operational burden. Each domain needs its own certificate. Manual renewal at this scale was already painful at 90 days. At 45 days, it's not feasible.

Agencies managing client domains. Digital agencies often manage SSL for dozens or hundreds of client domains. Each client may use different infrastructure, different renewal processes, and different levels of automation. The 45-day timeline amplifies every inconsistency in their renewal workflows.

E-commerce platforms with multiple storefronts. Multi-brand e-commerce operations run separate domains for each brand, each region, and each campaign. The certificate count multiplies quickly, and so does the renewal burden.

SaaS platforms with custom domains. SaaS products that allow customers to bring their own domains typically handle SSL provisioning as part of onboarding. With 45-day certificates, the renewal infrastructure needs to be bulletproof — a renewal failure for a customer's domain means their site shows a security warning.

Teams with fully automated ACME-based renewal may not feel the change at all. The certificate lifetime is abstracted away by infrastructure that renews automatically. The dividing line is automation — if your renewal process involves a human checking a dashboard or running a script, you're on the wrong side of it.

The Enterprise Readiness Gap#

Plenty of teams automated certificates years ago and never looked again. The gaps show up in the same places:

certificates tracked in a spreadsheet instead of monitored, renewal scripts that someone has to trigger, expiry alerts going to an inbox nobody reads, and domains that only redirect, so no one thinks of them as having a certificate at all.

The readiness gap is widest in organizations that adopted Let's Encrypt early but never fully automated their renewal pipeline. They set up Certbot on a few servers five years ago, added a cron job, and haven't revisited the setup since. Those cron jobs may run every 60 days — which won't be frequent enough for 45-day certificates.

Audit now, while you still have 90-day certificates as a safety margin: list every certificate, confirm each renews automatically, and test what happens when a renewal fails.

ACME vs manual certificate management#

Checklist for redirect and parked domains#

Domains that only redirect are easy to forget, but a visitor typing https:// still needs a valid certificate before the redirect can happen. Before the 2027 and 2028 dates:

1. List every domain that redirects, including old brands, typo domains and campaign domains, and both the root and www.
2. For each one, note who issues its certificate and how it renews. "The registrar's forwarding" often means no HTTPS at all.
3. Check that each ACME client supports ARI or renews at two-thirds of the lifetime, not on a fixed 60-day cron.
4. Make sure validation still works at renewal time: the DNS still points where the HTTP challenge is answered, or the DNS challenge credentials still work.
5. Set up expiry monitoring that alerts a shared channel, not one person's inbox.
6. Test against Let's Encrypt staging before each production change.

Or take redirect domains off your list entirely by moving them to a redirect platform that issues and renews HTTPS for each domain it serves.

Conclusion#

The 45-day certificate era is coming, and it's not just a Let's Encrypt policy change — it's an industry-wide shift toward shorter certificate lifetimes driven by security best practices. For enterprise teams, the dividing line between those who feel the impact and those who don't is simple: automation.

If your SSL renewal pipeline is fully automated through ACME — if certificates renew, install, and verify without human intervention — you may not notice the change at all beyond updating a configuration parameter. If your renewal process involves any manual steps, spreadsheets, or human-triggered scripts, the 45-day timeline will expose every gap in your infrastructure.

The practical steps are straightforward: audit your certificate inventory, verify automation coverage, test renewal failure scenarios, and ensure monitoring catches expirations before users see browser warnings. The teams that do this now — before the timeline shrinks — will navigate the transition without incident.

Running redirect domains? See how to redirect a domain over HTTPS without certificate errors.