45-Day Let's Encrypt Certificates Are Here: The Renewal-Automation Bar Every Self-Hosted PaaS Now Has to Clear

On May 13, 2026, Let's Encrypt cut the certificate lifetime of its tlsserver ACME profile in half — from 90 days to 45. If your platform renews at the recommended two-thirds mark, that means every certificate you serve now renews roughly every 30 days, and your budget for absorbing a failed renewal shrinks from 30 days to 15. That is the entire story in one table:

The headline math: a 90-day certificate renewed at day 60 leaves you 30 days to notice and fix a broken renewal before users see a browser error. A 45-day certificate renewed at day 30 leaves you 15. A 6-day certificate leaves you about two. If you operate a self-hosted PaaS — a platform that provisions TLS for every custom domain your tenants push — this is not one cron job to check. It is one cron job per domain, times every domain on the platform, on a clock that just started ticking twice as fast.

This post is an audit of what that halved window actually demands from a platform's ACME pipeline: how the renewal margin must be expressed, what retry and alerting have to look like, and where the silent single point of failure usually hides.

What Changed on May 13, 2026 — and What Didn't​

First, precision, because the details determine what you need to do and when.

Let's Encrypt now offers three certificate profiles, selected by ACME clients through the profiles mechanism being standardized with the IETF ACME working group:

• classic — 90-day validity, 7-day authorization lifetime, up to 100 domain names. Still the default today: if your client doesn't request a profile, this is what you get, unchanged.
• tlsserver — now 45-day validity, 1-hour authorization lifetime, up to 25 domain names, and a trimmed certificate body (no Common Name, no Key Encipherment key usage, no Subject Key ID) that tracks current CA/Browser Forum guidance.
• shortlived — roughly 6 days (160 hours), 1-hour authorization lifetime, no revocation pointers at all, and the only profile that supports IP address identifiers. Generally available since January 15, 2026.

So no, your certificates did not silently halve in May if you never opted into tlsserver. But treating this as an opt-in curiosity misses the trajectory, which is now written down in two places:

1. Let's Encrypt's own schedule. The default classic profile drops to 64 days on February 10, 2027, and to 45 days on February 16, 2028. Authorization reuse shrinks alongside it, from 7 days today to 7 hours by 2028.
2. The CA/Browser Forum's ballot SC-081, proposed by Apple and passed in April 2025, which caps maximum TLS certificate lifetime industry-wide: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029 — with domain-validation reuse compressed to 10 days at the end state. This binds every public CA, not just Let's Encrypt.

tlsserver at 45 days is not an experiment. It is a preview of the default that every domain on your platform will be living under within two years, offered early so you can find out whether your automation clears the bar while a failure still costs you an incident review instead of an outage.

The Renewal Math: Your Failure Budget Just Halved​

The industry convention — followed by certbot, cert-manager, and Let's Encrypt's own guidance — is to renew at two-thirds of a certificate's lifetime. The point of renewing early is not tidiness; the remaining third is your failure budget: the time you have to detect a broken renewal, fix it, and retry before the certificate expires in production.

Here is what the shrinking lifetimes do to that budget:

Fifteen days still sounds comfortable — until you remember what has to happen inside it. A renewal that fails on a Friday before a two-week holiday freeze now expires during the freeze. A DNS misconfiguration a tenant introduces (a broken CAA record, a nameserver migration) has half the time to be noticed and half the time to be escalated to a human who can't fix the tenant's DNS themselves.

And there is a subtler trap: absolute renewal margins break when lifetimes change under them. A pipeline configured to "renew 30 days before expiry" — a completely reasonable setting in the 90-day world — does two bad things on a 45-day certificate: it renews at day 15, doubling issuance frequency for no benefit, and it silently converts your intended 33% margin into a 67% one, or worse. Push the same absolute margin toward a 6-day certificate and it renews in a loop. The fix is structural, not numeric: express the margin as a percentage of the actual issued lifetime, read off the certificate itself, not off an assumption about what the CA issues. cert-manager documents exactly this with renewBeforePercentage, and notes the reason with a detail worth internalizing: Let's Encrypt backdates certificates by one hour, so a "90-day" certificate's working lifetime is really 89 days 23 hours — issuers do not owe you the duration you requested.

One piece of good news: renewal frequency doubling does not eat your rate limits. Let's Encrypt confirmed in February 2026 that renewals are exempt from rate limiting, so a platform holding tens of thousands of tenant certificates sees no quota impact from the shorter cadence.

The Five-Point Audit for a Platform ACME Pipeline​

If you run a PaaS on your own hardware, TLS provisioning is not a certificate — it is a fleet of certificates owned by people who are not you. Here is the audit, with a concrete pass/fail for each point.

1. Renewal triggers are percentage-based or ARI-driven — never absolute​

Pass: your renewal decision reads the issued certificate's notBefore/notAfter and fires at a fraction (2/3 is the convention) of the observed lifetime, or defers to the CA's ARI suggestion (next point).

Fail: any config containing a fixed "days before expiry" number, any hardcoded assumption that certificates last 90 days, any renewal schedule expressed as "monthly." Grep your pipeline for 30 and 60 near TLS code; each hit is a place the February 2027 default change can break you.

2. Retries fit inside the failure budget — and one tenant can't block the fleet​

A renewal attempt can fail for reasons that resolve themselves (CA outage, transient DNS flakiness) and reasons that don't (tenant deleted their CNAME, CAA forbids issuance). The pipeline needs both handled:

Pass: failed renewals retry automatically with backoff and jitter; the retry schedule exhausts well inside the 15-day budget rather than, say, retrying weekly; and — critically for a multi-tenant platform — renewals are isolated per domain, so one tenant's permanently failing authorization doesn't head-of-line-block the renewal queue for everyone else.

Fail: a sequential renewal loop that aborts on first error. In the 90-day world this bug can hide for months. At a 30-day cadence it takes down the domain behind the broken one within weeks.

3. Alert on the certificate you're serving, not on the cron job that ran​

This is where the silent single point of failure lives. The classic failure mode of TLS automation is not a loud error — it is a timer that stopped firing: the systemd unit disabled during a migration, the CronJob suspended during an incident and never resumed, the renewal container that's been crash-looping since a base-image update.

Pass: monitoring probes the certificate actually being served on 443 — from outside the renewal path — and alerts when observed remaining lifetime crosses a threshold you derive from the failure budget. For 45-day certificates, alerting at 10 days remaining gives a human two-thirds of the failure budget to act. The renewal system and the monitoring system must not share a failure domain.

Fail: alerting on "renewal job exited non-zero." A job that never runs exits nothing. If your only signal is job success, your first real alert is a tenant screenshotting NET::ERR_CERT_DATE_INVALID.

The math on why this matters more now: monitoring that a human checks "every couple of weeks" was marginal-but-survivable with a 30-day budget. With 15 days, a two-week check interval means the first check after a failure can land after expiry.

4. Speak ARI — the CA is offering to schedule your renewals​

ACME Renewal Information (ARI, RFC 9773) lets your client ask the CA when a certificate should be renewed: the client polls the renewalInfo endpoint and gets back a suggested window. This buys you three things for one integration:

• Load-spreading and correctness: the CA picks the window, so you inherit sane timing across lifetime changes without touching config again.
• Incident-driven early renewal: when a CA must mass-revoke (a misissuance event, a key-compromise incident), ARI is how it tells your client to renew now — days before revocation — instead of your tenants discovering revoked certificates in production.
• Rate-limit exemption: renewals within the suggested window are exempt from all rate limits.

Pass: your ACME client polls renewalInfo and honors the suggested window, with the percentage rule from point 1 as fallback. Certbot, Lego, and cert-manager all ship ARI support today.

Fail: a client last vendored in 2023 that has never heard of ARI. It will keep working — until the first mass-revocation incident, when platforms with ARI renew transparently and platforms without it wake up to a fleet of revoked certificates.

5. Respect the 1-hour authorization lifetime​

The tlsserver and shortlived profiles cut authorization validity from 7 days to 1 hour — and the default profile follows, down to 7 hours by 2028. Two consequences for pipeline design:

Pass: your order flow treats validation and finalization as one prompt sequence — order, validate, finalize within the hour — and your DNS-01 path accounts for propagation delay before requesting validation, not after. Platforms that pre-stage DNS records (or use HTTP-01 where the platform already terminates the traffic) clear this easily.

Fail: any flow that creates authorizations in one batch pass and finalizes in another, hours later, or that leans on authorization caching to paper over slow DNS propagation. Worth watching: Let's Encrypt is developing DNS-PERSIST-01, a validation method (expected in 2026) that lets a DNS record stay static across renewals — which will remove most of the DNS-01 churn from this picture.

Running This on a Platform You Own​

On a self-hosted Kubernetes platform, most of the audit maps onto cert-manager configuration plus one piece of external monitoring:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: tenant-example-com
spec:
  secretName: tenant-example-com-tls
  # Percentage, not absolute: survives 90 -> 64 -> 45 day changes untouched
  renewBeforePercentage: 33
  issuerRef:
    name: letsencrypt
    kind: ClusterIssuer
  dnsNames:
    - app.tenant-example.com

cert-manager retries failed orders with backoff (point 2), supports ARI (point 4), and exports certmanager_certificate_expiration_timestamp_seconds — but that metric reports what cert-manager believes, so the external probe of the served certificate (point 3, blackbox-exporter or any TLS probe from outside the cluster) remains the check that catches the whole system being wrong.

This is also a place where platform design quietly decides your audit results. If TLS provisioning is a shell script per app, points 2 and 3 are seven small projects. If it is a property of the platform — every custom domain gets issuance, renewal, retry, and expiry monitoring from the same controller — you audit once and every tenant inherits the result. That is the approach we take with Bex, the open-source, AI-native Render alternative: a tenant's custom domain is a declared attribute of their app, the platform owns the ACME lifecycle for it on machines you control, and certificate state is exposed as machine-readable status — so an operator, human or AI agent, can ask "which domains have under 10 days remaining and a failing renewal?" instead of discovering the answer from a browser error.

The Ratchet Doesn't Stop Here​

It is tempting to file this under "2028's problem": the default profile holds 90 days until February 2027, and your current setup renews fine. But the schedule is public and it only moves one direction — 64 days next February, 45 the year after, and an industry-wide 47-day cap with 10-day domain-validation reuse by March 2029. At a 10-day validation reuse window, any process with a human in the renewal path is not "risky" — the CA/Browser Forum discussion called it what it is, a recipe for outages.

The bar, concretely: percentage-based renewal margins, per-domain retry isolation, expiry monitoring outside the renewal path, ARI, and order flows that finish within an hour. None of these is exotic; all of them are the difference between a lifetime change you read about in a blog post and one you read about in your incident channel.

The platforms that clear it get something better than survival. A pipeline that renews every domain every 30 days, alerts on observed expiry, and takes CA renewal hints is a pipeline you can finally trust with 6-day certificates — no revocation lists, a two-day compromise window, and TLS that rotates faster than most teams rotate SSH keys. Shorter lifetimes are only a threat to automation that was already broken and hadn't been caught yet. Audit now, while the certificate that catches it is still an opt-in.

Bex is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with custom-domain TLS handled by the platform. Star the repo on GitHub or deploy your first app today.