Let's Encrypt Won't Make 6-Day Certificates the Default: the 6-Question Automation Exam Before You Opt In

On January 15, 2026, Let's Encrypt made 160-hour certificates generally available. Any subscriber can now ask for a certificate valid for just over six days by selecting the shortlived ACME profile — and in the same announcement, Let's Encrypt said the quiet part out loud: "Short-lived certificates are opt-in and we have no plan to make them the default at this time." Not because the cryptography is unproven. Because most of the internet's renewal automation cannot be trusted on a six-day clock.

Here is the verdict up front, for the question every platform team should be asking — could we flip our tenants to six-day certs tomorrow?

Six-day certificates do not ask for slightly better automation. They convert renewal from a background chore with a month of forgiveness into a control loop with about two days of it — and they move the alert that matters from "sometime this month" to "within hours." Everything below is what that control loop actually demands, and why a platform that owns the whole TLS path end-to-end is the one kind of operator ready to run it first.

A note on scope: in July we covered the fleet-scale side of this migration — why the binding constraint at 10,000+ tenant domains is your DNS provider's API rate limit, not Let's Encrypt's, and why nightly batch renewal has to become continuous staggered renewal. This post answers the adjacent question the GA announcement itself raised: why Let's Encrypt refuses to make six-day the default, and the six-question exam your automation must pass before you opt your tenants in.

Why Let's Encrypt itself won't flip the default​

Read the GA announcement's reasoning carefully, because it names the blocker precisely. Subscribers "that have fully automated their renewal process should be able to switch to short-lived certificates easily if they wish, but we understand that not everyone is in that position." The profiles documentation is blunter: "We recommend this profile for those who fully trust their automation to renew their certificates on time. This profile is not for everyone."

Note what is not on the list of blockers: client support, protocol readiness, CA capacity. Certbot 4.0 shipped --preferred-profile and --required-profile flags for exactly this, and Certbot 4.1 added ACME Renewal Information (ARI) support. The cryptography is done. The ecosystem's operations are not.

A CA that defaults seven million websites onto a six-day clock before their cron jobs, monitoring, and retry logic can hold it would manufacture the largest self-inflicted outage in web PKI history. So Let's Encrypt keeps the aggressive option opt-in while it tightens the default on a slower fuse (more on that fuse below).

Two scope notes worth getting right. First, shortlived spent its early-access period behind an allowlist — not because issuance couldn't scale, but because each six-day subscriber generates roughly 15× the renewal traffic of a 90-day one (about 91 renewals per cert per year versus about 6). Let's Encrypt wrote about that load explicitly in its February 2026 rate-limits post: shorter defaults ultimately double daily renewal requests across the CA. GA removed the gate but kept the warning, and the warning is load-bearing.

Second, the IP-address certificates that went GA in the same announcement must be short-lived — IPv4 and IPv6 identifiers are only issued under the shortlived profile, because IP assignments are more transient than domain ownership and need re-validating more often. If your internal endpoints, node addresses, or load-balancer IPs will ever carry real certificates, your automation has to speak shortlived regardless of what you choose for customer domains.

The six-question exam: pass/fail before you opt in​

If the table above didn't disqualify you, here is the concrete bar, phrased as exam questions with explicit pass criteria. Every item has a number attached — that is the point. "Fully automated" is not a vibe; it is these six properties holding simultaneously. (Where our July post already taught a topic in depth — ARI mechanics, retry-vs-duplicate-budget math, DNS batching — this exam states the pass criterion and moves on.)

1. A profile-capable ACME client everywhere certs are issued. The shortlived profile travels inside the ACME order object (ACME profiles), so any client that cannot send a profile name cannot get a six-day cert at all. Concretely: Certbot ≥ 4.0, or a cert-manager recent enough to set an ACME profile on the issuer, or lego/acme.sh equivalents with profile support. Audit every issuance path — edge gateway, wildcard issuer, staging, internal tooling — because one legacy client in the fleet means one hostname class that silently stays on 90-day certs while you believe you migrated.

2. Renewal anchored to lifetime fraction, not fixed days. The ⅔ rule that renews a 90-day cert at day 60 renews a 160-hour cert at about hour 107. Any renewBefore / renew_before_expiry expressed as a fixed "30 days" is longer than the entire certificate and will either renew in a hot loop or never fire, depending on the client. Express renewal as a fraction of validity — cert-manager's renewBefore needs recomputing per profile, as the worked example below shows.

Then let ARI override it. ACME Renewal Information (RFC 9773) lets the CA pull renewal earlier than your schedule during mass-revocation or key-rollover events — Certbot 4.1 honors it, cert-manager has been converging on "CA-suggested window wins." Pass criterion: a CA-directed early renewal lands inside your slack window instead of colliding with it. (Mechanics and the rate-limit exemption covered in July.)

3. Retry with backoff measured in minutes, verified in hours. A 90-day renewal can fail for three weeks before anyone cares. A six-day renewal that fails at hour 107 has ~53 hours before expiry, and the failure modes are mundane: an ACME endpoint having a bad afternoon, a DNS-01 propagation delay, a challenge solver wedged after a deploy. Your retry loop must start within minutes and escalate within hours — and "escalate" must mean a page, not a log line (item 4). Cap retries against the Duplicate Certificate budget (5 per exact identifier set per rolling week — the July post works the burn-through math). Test this the way you'd test backups: block outbound ACME traffic for six hours in staging and watch whether every cert still renews with margin to spare.

4. Alerting on failed issuance within hours, not days. This is the item most teams fail. The standard "certificate expires in < N days" monitor with N = 7 or 14 never fires usefully for six-day certs — by the time a 7-day threshold trips, the cert may already be dead. Your expiry alert threshold must drop below the slack window: alert at < 72 hours, page at < 48.

And you need a second, better signal: alert on failed or skipped renewal attempts themselves, not just on approaching expiry. Expiry monitoring tells you the house is on fire; renewal-attempt monitoring tells you the stove was left on. On a six-day clock you need the stove sensor.

5. Rate-limit headroom for ~15× issuance volume. Fifteen times the renewals means fifteen times the exposure to too many certificates, too many failed authorizations, and duplicate-certificate limits — across every tenant domain simultaneously, on correlated schedules. Stagger renewal times: ARI's suggested windows help here, and uniform-random selection inside the window de-spikes the thundering herd.

Keep failed-validation budgets in mind, too — five failures per account per hostname per hour adds up fast when a fleet retries aggressively per item 3, which is exactly why items 3 and 5 must be designed together. And run the whole fleet against staging first: same profile, same 160-hour lifetime, none of your production Duplicate Certificate budget spent while you find the bugs in your own scheduling.

6. No manual-renewal escape hatch anywhere in the runbook. If any hostname class still depends on a human running a command, a calendar reminder, or a wiki page, six-day certs will find it — within a week, not within a quarter. The migration test is simple: can every certificate in the fleet renew correctly while the entire platform team is on a plane with no Wi-Fi for 48 hours? On 90-day certs the answer is trivially yes. On six-day certs it is the whole exam. Until the answer is yes, keep those hostnames on classic and say so explicitly; a mixed fleet with a documented boundary beats a "fully migrated" fleet with three manual exceptions nobody wrote down.

Worked example: cert-manager on the shortlived profile​

For a Kubernetes-based platform, the migration is one field plus arithmetic most teams get wrong on the first try. The field is the ACME profile on the issuer; the arithmetic is renewBefore, which must shrink from "30 days" thinking to "a fraction of 160 hours":

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: tenant-example-com
  namespace: tenant-workloads
spec:
  secretName: tenant-example-com-tls
  issuerRef:
    name: letsencrypt-shortlived   # ClusterIssuer with ACME profile: shortlived
    kind: ClusterIssuer
  dnsNames:
    - tenant.example.com
  # 160h validity: renew at ~2/3 => ~107h in, ~53h slack.
  # renewBefore counts BACK from expiry, so 53h keeps the 2/3 anchor.
  renewBefore: 53h
  # Usable the moment the new cert is issued, so a renewal
  # that lands minutes before expiry still helps.
  revisionHistoryLimit: 1

Three things to notice. First, renewBefore: 53h is the entire migration for this object — anyone copying the fleet's 90-day renewBefore: 720h (30 days) onto a shortlived certificate has written a config longer than the cert, and will find out how their client handles that at 3 a.m.

Second, pair this with ARI enabled (ACMEUseARI or your distribution's equivalent) so CA-directed early renewals land inside the slack window instead of colliding with it. Third, this manifest is also your monitoring contract: the alert from checklist item 4 fires when cert-manager_certificate_expiration_timestamp_seconds - now < 72h for any shortlived cert — a PromQL one-liner that falls directly out of the numbers above.

Why a self-hosted PaaS can go first​

Here is the structural reason this post lives on a platform-engineering blog rather than a general TLS roundup. Every item on the checklist gets harder the more parties split ownership of the path: the CDN owns edge certs, the cloud vendor owns the load balancer, a contractor set up DNS-01 three jobs ago, and nobody can answer "what happens if renewal fails on a Friday."

A self-hosted PaaS inverts that: the gateway, the ACME client, the DNS, and the observability stack are one automation path under one team's control. Checklist items 3–6 stop being cross-vendor negotiations and become a single controller plus two alerts. That is precisely the "fully trust their automation" posture Let's Encrypt's profiles page demands — and a platform team can verify it with the 48-hour-no-Wi-Fi test in a way no shared-responsibility setup can.

There is also a forcing function coming regardless of enthusiasm. The default-lifetime fuse is already lit: the opt-in tlsserver profile switched to 45-day certificates in May 2026, the default classic profile drops to 64 days in February 2027 and 45 days in February 2028, and the CA/Browser Forum ceiling heads toward ~47 days by 2029.

Nobody will be running 90-day automation forever; the only choice is whether your renewal loop, alerting thresholds, and rate-limit math get rebuilt deliberately now — with six-day certs as the strictest test case — or under duress later, one deprecation notice at a time. Teams that pass the shortlived exam early will find the 45-day default a non-event. Teams that don't will re-live this migration at every step of the fuse.

The security payoff is real, and worth one paragraph: short-lived certificates shrink the key-compromise exposure window from up to 90 days to about six, and they do it by removing machinery — expiry replaces revocation, so the fleet stops depending on OCSP and CRL distribution that browsers increasingly don't check anyway. That is the actual prize behind the operational pain: not fashionably short lifetimes, but one fewer unreliable global system in your tenants' trust path.

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.

Sources​

• Let's Encrypt, "6-day and IP Address Certificates are Generally Available" (Jan 15, 2026) — 160-hour validity, shortlived profile opt-in, "no plan to make them the default," IP certs must be short-lived.
• Let's Encrypt, "Decreasing Certificate Lifetimes to 45 Days" (Dec 2025) — tlsserver 45-day opt-in May 13, 2026; classic → 64-day Feb 2027; classic → 45-day Feb 2028.
• Let's Encrypt, "Shorter Certificate Lifetimes and Rate Limits" (Feb 24, 2026) — renewal-request doubling, issuance-volume load.
• Let's Encrypt, ACME Profiles documentation — "fully trust their automation… not for everyone," allowlist history.
• EFF, "Certbot 4.0: Long Live Short-Lived Certs!" (Apr 2025) — --preferred-profile / --required-profile; Certbot 4.1 ARI support.
• cert-manager, ACME ARI design doc (Mar 2026) and ACMEUseARI gate (v1.21) — CA-directed renewal timing.
• RFC 9773 — ACME Renewal Information (ARI).