Six Days to Renew: What Let's Encrypt's Short-Lived Certificates Do to Your Renewal Margin

Your TLS certificate used to give you a month to fix a broken renewal. Soon it may give you a weekend. Let's Encrypt's short-lived certificates — generally available since January 2026, valid for 160 hours — compress the renewal safety margin that every ACME automation on your platform was tuned around, from thirty days of slack to about two. The cryptography is identical. The operational contract is not.

This post puts the before/after numbers on the table first, then walks what a self-hosted platform issuing certificates on behalf of tenants must change — renewal config, challenge reliability, monitoring thresholds, and the default-or-opt-in decision — before adopting the shortlived ACME profile as its default.

The answer up front: from 30 days of slack to about 53 hours​

Assumptions, stated once so the table is checkable: a standard Let's Encrypt certificate is valid 90 days and renews at two-thirds of lifetime (cert-manager's default when renewBefore is unset; Certbot's default is an equivalent 30 days before expiry). A short-lived certificate is valid 160 hours — just over six and a half days — and under the same two-thirds rule renews at roughly hour 107. Renewals per year are 365 divided by the renewal interval.

Two things to read off this table before the detail. First, the security upgrade and the operational downgrade are the same number: a compromised key stays trusted for 6 days instead of 90, but your automation's error budget shrinks by the same factor of ~14. Second, every threshold your platform currently expresses in days — alert at 21 days, page at 7 — fires after a short-lived certificate is already dead. The migration is not "request a different profile." It is re-tuning every assumption downstream of the number 90.

Why the industry is shrinking lifetimes anyway​

Short-lived certificates are not a Let's Encrypt experiment. They are the direction the whole public-TLS ecosystem is walking, on a fixed calendar. The CA/Browser Forum's Ballot SC-081v3, adopted in April 2025, caps public certificate lifetimes at 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, with domain-validation reuse shrinking alongside. By 2029 every public certificate expires roughly every six weeks. A platform whose renewal automation assumes 90-day certs with 30-day slack is already one ballot step behind the schedule — the shortlived profile is just the far end of the same curve, arriving early.

The reason lifetimes keep shrinking is that revocation does not work at scale, and the industry has the incident reports to prove it. In March 2020 a bug in Let's Encrypt's CAA rechecking code meant roughly three million certificates had to be revoked and replaced on short notice — subscribers who missed the notice faced overnight browser warnings through no fault of their own. The lesson the ecosystem took was blunt: you cannot reliably push "stop trusting this" to every client on the internet, but expiry is automatic and universal. A six-day certificate does not need to be revoked. It just dies.

Let's Encrypt took that logic to its conclusion: short-lived certificates carry no OCSP or CRL URLs at all. There is nothing to check and nothing to revoke — the validity window is the revocation mechanism, and dropping the revocation infrastructure is part of what makes issuing 14× more certificates per subscriber sustainable. Shorter life, less machinery, smaller blast radius. The price is paid entirely in renewal reliability.

What the shortlived profile concretely is​

The timeline: Let's Encrypt announced six-day certificates in late 2024, issued the first one in February 2025, and declared them generally available on January 15, 2026. Requesting one means using an ACME client that supports certificate profiles and selecting the shortlived profile — no separate endpoint, no allowlist anymore. Validity is 160 hours, not exactly 144, giving clients a small amount of breathing room inside the "six days" label.

Three properties matter for platform operators. First, profiles are a client capability: older ACME clients that do not speak the profiles extension cannot request short-lived certificates at all, so the first migration step is auditing every client version touching the CA. Second, short-lived is mandatory for IP-address certificates — Let's Encrypt will only sign a bare IP inside a short-lived profile, which makes the profile the only path to TLS without a domain name. Third, because there is no revocation channel, a mis-issued short-lived certificate cannot be killed early. The window is small enough that this is acceptable. It is not zero.

The automation bar: what has to change on your fleet​

Start with the concrete config. In cert-manager, opting a tenant certificate into the profile looks like this:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: tenant-app
  namespace: tenant-blue
spec:
  secretName: tenant-app-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - app.example.com
  acme:
    profile: shortlived
  renewBefore: 24h

Two lines carry the whole migration. acme.profile: shortlived selects the six-day certificate on an issuer that supports profiles. renewBefore: 24h pins the renewal point explicitly instead of inheriting the two-thirds default — real-world adopters set exactly this, because an explicit, auditable number beats a fraction of a validity period that the CA is allowed to change. With renewBefore: 24h on a 160-hour cert, renewal fires at hour 136 and the slack is exactly one day: predictable, alertable, and independent of any future validity tweak.

Beyond the YAML, four things get harder in proportion to the ~14× issuance volume:

Challenge reliability becomes a weekly event, not a quarterly one. Each renewal re-proves domain control, so an HTTP-01 or DNS-01 path that fails intermittently — a solver pod blocked by a network policy, a DNS credential with the wrong scope — now surfaces every four to five days instead of every sixty. The failure mode the community already knows (a cert-manager HTTP-01 solver silently wedged, discovered only when the 90-day cert finally dies) arrives 14× faster and with 1/14th the time to diagnose. Before switching profiles, prove the challenge path succeeds unattended several cycles in a row; with short-lived certs, "the challenge worked last month" is ancient history.

Renewal timing should follow the CA, not a fixed fraction. ACME Renewal Information (ARI) lets the CA tell each client when to renew, smoothing global load and — critically — pulling renewals earlier when the CA knows an incident is coming. Clients that poll ARI and honor the suggested window ride out CA-side schedule changes; clients on fixed timers discover them as failures. At 90-day lifetimes ARI is an optimization. At six-day lifetimes it is the mechanism that keeps 82 renewals a year from stampeding the same hour.

Volume meets rate limits. Eighty-two renewals per certificate per year is trivial for one service and a different conversation for a platform holding thousands of tenant certificates. Size the renewal fleet — workers, challenge solvers, DNS API quotas — for the steady-state rate, not the old one, and confirm which limits the CA applies to profile-selected renewals before the first mass migration.

Client versions are the gate. Every ACME client in the fleet — cert-manager, Certbot, Lego, custom integrations — must support the profiles extension. The migration inventory is a client-version audit first and a config change second.

Monitoring retuned from weeks to hours​

This is the section most migrations skip, and it is where short-lived certificates actually bite. A typical platform alerts on certificate expiry with thresholds like "warn at 21 days, page at 7 days." Against a 160-hour certificate, the page fires a day after expiry. Every threshold must be re-derived in hours:

And the sensitivity analysis the title promised: what does a CA-side issuance pause consume from each profile's slack? Take a three-hour outage — not a prediction, just the unit of incident worth planning around. Against a 90-day cert's 720-hour slack, three hours is 0.4%: unnoticeable. Against a short-lived cert's 53-hour default slack, it is nearly 6%; against an explicit renewBefore: 24h, it is 12.5% of the entire error budget. A full-day CA incident — the kind every operator should have a runbook for — consumes 3% of the old margin and 45–100% of the new one, depending on renewBefore. That is the number that decides whether "renewal jobs on the order of hours" is a slogan or a staffing plan: with short-lived defaults, a renewal pipeline that pages nobody until morning can wake up to expired tenant certificates.

The corollary: expiry monitoring must watch renewal success, not just time-to-expiry. A cert with 40 hours left that failed its last three renewal attempts is already an incident; a cert with 40 hours left that renews cleanly every cycle is routine. Monitor the job, not just the clock.

Should short-lived be the default for your tenants?​

For a platform issuing certificates on behalf of tenants, the honest answer is staged, not binary:

Default to the 90-day profile, offer shortlived as an explicit opt-in, and make the opt-in a checklist, not a toggle. The checklist: ACME clients current, ARI honored, challenge path proven over multiple unattended cycles, monitoring thresholds re-tuned to hours, renewal-failure paging routed to someone awake. Tenants who clear it get meaningfully better security — a six-day exposure window and no revocation dependency. Tenants who do not clear it get an outage they will blame on the platform, not on the profile.

Revisit the default as the ecosystem moves. SC-081v3 is dragging every tenant toward 47-day certificates by 2029 regardless. Each step down the schedule — 200 to 100 to 47 days — is a rehearsal of exactly this migration with a gentler slope. Platforms that build the hour-scale renewal pipeline and monitoring now, for opt-in short-lived tenants, will absorb the mandated shrinkages as routine. Platforms that defer will meet 2029 as an emergency.

Keep one exception explicit. IP-address certificates have no choice — short-lived is the only profile that signs them. If your platform terminates TLS on bare IPs, that path migrates first and unconditionally.

The arc of TLS lifetimes bends toward zero: 398 days to 200 to 100 to 47, with six-day certificates already generally available for anyone whose automation can hold the line. The CAA-bug revocations of 2020 showed that long-lived trust plus unreliable revocation is the worst of both worlds; short-lived certificates fix the trust half. The renewal half is now yours. Measure your slack in hours, alert on the job instead of the clock, and adopt the profile your automation has earned — then tighten it as the automation improves.

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