45-Day Certificates Are Here: What Let's Encrypt's Shrinking Validity Window Demands From Your Renewal Automation

On May 13, 2026, the 90-day certificate era started ending. That morning, Let's Encrypt flipped its opt-in tlsserver ACME profile to issuing 45-day certificates — half the lifetime every piece of renewal automation on the internet was tuned for. If your TLS setup is a cron job you configured once and a calendar reminder you snooze, the runway for a failed renewal just got cut in half, and the schedule only tightens from here.

This post lays out the full timeline, the renewal-window math that actually changes, and a concrete checklist for making your ACME automation boring again. If you run a self-hosted platform or a fleet of VPS boxes with hand-rolled certbot, this is the one operational shift in 2026 you cannot afford to treat as somebody else's problem.

The timeline is no longer hypothetical​

Shorter certificate lifetimes have been discussed for years. Now they have ship dates — from Let's Encrypt and from the CA/Browser Forum, whose Ballot SC-081v3 (passed unanimously in April 2025) binds every public CA. Here is the complete schedule in one place:

Two things stand out. First, Let's Encrypt is ahead of the industry curve: its default hits 45 days a full year before the Forum mandates 47. Second, the authorization-reuse column matters as much as the validity column — by 2028, a cached domain validation lasts 7 hours instead of 30 days, which means nearly every renewal re-proves the domain from scratch. Renewal stops being a quiet background refresh and becomes a full validation round-trip, twice as often.

The math that actually changes: your fix window just halved​

The standard guidance — from Let's Encrypt itself — is to renew at roughly two-thirds of a certificate's lifetime, or to follow the CA's suggested window via ACME Renewal Information (ARI). That ratio stays the same. What changes is the absolute number of days between "renewal should have happened" and "the site is down." That gap is your fix window, and it is collapsing:

Read that table as an on-call story. Under 90-day certs, a broken renewal cron, a drifted DNS-01 credential, or a firewall change that blocks HTTP-01 gives you a month of red alerts before users notice. Engineers fix that kind of thing on a Tuesday afternoon. Under 45-day certs, the same failure gives you two weeks — one vacation, one holiday weekend, one alert routed to a decommissioned PagerDuty schedule, and you are explaining an outage. Under 6-day certs, there is no human-in-the-loop escape hatch at all: a renewal failure pages someone within 48 hours or the certificate dies.

This is the entire argument in one sentence: shorter lifetimes don't change what your automation does, they change how much sloppiness it tolerates. Every manual step, every unmonitored cron, every "we'll notice the email" in your renewal path was already a bug. It just had a 30-day grace period, and now it has 15.

Expiry outages are already routine — shorter lifetimes raise the stakes​

If you think "we'd notice," the industry's track record disagrees. Expired-certificate outages keep hitting sophisticated teams:

• Tailscale, March 2024. tailscale.com went dark for about 90 minutes on an expired TLS certificate — at a networking company whose entire product is connectivity.
• Bank of England, July 2024. An expired certificate halted CHAPS high-value payments and CREST settlement. It was the bank's second certificate outage that year, after a 39-minute RTGS stoppage in January.
• Jenkins, August 2025. issues.jenkins.io went unavailable on an expired TLS cert until the infra team could complete a DNS ACME challenge and renew.
• The background rate is grim. One 2025 industry survey found weekly certificate outages hitting 45% of organizations, up from 12% in 2022. CSC research put 40% of enterprises at risk of an outage from SSL expiration.

And the failure mode isn't only on your side. On May 8, 2026 — five days before the 45-day switch — Let's Encrypt halted all issuance for hours after a problem surfaced with the cross-signed certificate linking its Generation X root to the new Generation Y root. Browsers don't phone home to the CA on every handshake (and Let's Encrypt shut down its OCSP responders back in August 2025), so existing certificates kept working. The casualties were renewals: any certificate inside its fix window that needed a fresh issuance during those hours simply failed. Shorter lifetimes mean more of your fleet is inside its fix window at any given moment, so a CA-side incident of the same duration catches more victims. Your retry discipline has to assume the CA is occasionally unreachable, because occasionally it is.

The renewal-automation checklist​

Here is what to verify, concretely, before February 2027 makes 64-day certs the default. Work through it per certificate, per environment — the one you skip is the one that pages you.

1. Confirm your ACME client supports ARI, or pin renewal to two-thirds of lifetime. ACME Renewal Information (now an IETF standard Let's Encrypt actively recommends) lets the CA tell your client exactly when to renew, including early-renewal signals during mass-revocation events. cert-manager, recent certbot, lego, and Caddy all speak ARI or equivalent logic. If your client predates ARI support, configure renewal at two-thirds of validity — day 30 for a 45-day cert, not "30 days before expiry" carried over from the 90-day world. Audit every client version in your fleet; the renewal schedule lives in the client, not the CA.

2. Move alerting thresholds earlier in absolute days. An alert that fires "14 days before expiry" was a comfortable backstop under 90-day certs — renewal should have happened 16 days earlier, so 14 days meant something was already wrong with two weeks to fix it. Under 45-day certs, 14 days before expiry is one day before the scheduled renewal. Recalibrate: alert when a certificate passes its expected renewal point without renewing (day 31 for 45-day certs), escalate a few days later, and treat "7 days to expiry" as a sev-1, not a warning. Alert on renewal failure events, not just approaching expiry — by the time expiry approaches, the window is gone.

3. Assume revalidation on every renewal. The shrinking authorization-reuse periods — 30 days today, 10 days in 2027, 7 hours in 2028 — mean the DNS-01 credentials, HTTP-01 reachability, and CAA records your validation depends on get exercised on nearly every renewal instead of being cached past minor breakage. That IAM role allowed to write _acme-challenge records, that firewall rule permitting port 80 to the solver pod: if either drifts, you find out at the next renewal, which is now every few weeks. Monitor the validation path itself (credential freshness, challenge reachability), not just the certificate.

4. Retry with backoff and survive CA outages. The May 2026 issuance halt is your design input: renewals must retry across hours, not attempt once and wait for tomorrow's cron. cert-manager's exponential backoff on failed issuances is the right shape; a daily certbot renew cron with no failure alerting is the wrong one. And every retry path needs an alert attached — silent cron failure is how 30-day windows get burned without anyone knowing.

5. Force a renewal in staging before you depend on it. AWS's guidance for the 45-day transition says it plainly: force a manual renewal against a non-production endpoint and confirm your client, monitoring, and on-call runbooks behave before the shortened windows turn a failed renewal into a disruptive event. Do a game day. Break the DNS credential on purpose, watch the alert fire, confirm the runbook works. The teams that discover their renewal path is broken during a drill write a postmortem nobody reads; the teams that discover it at 2am write one everybody reads.

6. Inventory every certificate, including the ones you forgot. Shorter lifetimes punish unknown certificates hardest — the internal dashboard, the staging wildcard, the cert a departed contractor provisioned by hand. Enumerate them (Certificate Transparency logs are your friend), get each one under automation or explicitly accept its risk, and delete the ones nobody owns. A certificate nobody owns is an outage with a timer, and the timer just got faster.

Own the ACME client, absorb the shift​

Step back and notice who feels this transition and who doesn't. A platform that owns its ACME client end-to-end — issuance, renewal scheduling, ARI handling, challenge solving, cert storage, reload-on-renew, monitoring — absorbs the 90-to-45 shift as a configuration change: adjust a ratio, move an alert threshold, re-run the staging drill. The machinery doesn't change shape because there was never a human in the loop to squeeze out.

The team that feels it is the one with a certbot cron on a VPS, a DNS credential in one person's password manager, and expiry emails going to a mailing list nobody reads. For them, every halving of the lifetime halves the odds that a human notices in time. The 2028 end state — 45-day certs, 7-hour authz reuse, revalidation every renewal — is simply incompatible with human-in-the-loop TLS. That is the point of the whole exercise: the ecosystem is automating the human out of certificate management by making the manual path unsurvivable.

So the real question this timeline asks isn't "are your certs 45-day ready." It's "is there any step in your renewal path that requires a person to notice something." If the answer is yes, you have until February 2027 before the default moves under you. Spend it well.

Running apps on infrastructure you own shouldn't mean hand-rolling TLS renewal on every box. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with certificate lifecycle handled by the platform instead of a cron job you hope still works. Star the repo on GitHub or deploy your first app today.

Sources​

• Let's Encrypt, "Decreasing Certificate Lifetimes to 45 Days" (Dec 2025) — the tlsserver/classic rollout schedule: letsencrypt.org/2025/12/02/from-90-to-45
• Let's Encrypt, "6-day and IP Address Certificates are Generally Available" (Jan 2026): letsencrypt.org/2026/01/15/6day-and-ip-general-availability
• CA/Browser Forum Ballot SC-081v3 schedule (200 → 100 → 47 days by March 2029)
• Let's Encrypt, "ACME Renewal Information (ARI)" (Mar 2026)
• AWS Security Blog, "Automate certificates with ACME support in AWS Certificate Manager"
• Tailscale, "About the Tailscale.com outage on March 7, 2024"
• Jenkins Infra status, "JIRA TLS expired" (Aug 2025)
• Security Boulevard / Stack report on the Bank of England CHAPS certificate outage (Jul 2024)
• SSL Dragon / CSC research on 2025 certificate-outage rates