Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — The First Deadline Has Already Passed
What SC-081v3 Actually Set — Two Tables from the Source
What the Vote Tallies Tell You — 2019 vs. 2025
Let's Encrypt's Actual Transition Dates — 90 → 64 → 45
6-Day Certificates and IP Certificates — Already in General Availability
Stop Hardcoding Renewal Timing — ACME ARI (RFC 9773)
What Hasn't Arrived Yet — Where DNS-PERSIST-01 Stands
So, What Should You Prepare?
Closing
References

Introduction — The First Deadline Has Already Passed

On March 15, 2026, the maximum lifetime of publicly-trusted TLS certificates dropped from 398 days to 200 days. As of this writing, that was four months ago. If your team has been getting by on once-a-year manual renewal, you've already felt it at this year's renewal cycle — and if you haven't yet, you will, the day your current certificate expires.

And this is only the start. The ballot SC-081v3, passed by the CA/B Forum in April 2025, locks in a schedule that brings the maximum lifetime down to 47 days by March 2029. Yet the dates on this topic tend to drift slightly from one summary article to the next. So this post starts by verifying the step-by-step dates directly from the ballot text and the TLS Baseline Requirements (BR) source. From there, it lays out Let's Encrypt's actual announced transition dates, and the tools that let you survive this schedule — ACME profiles, 6-day short-lived certificates, ARI (RFC 9773), and DNS-PERSIST-01 — together with their real support status as of today.

For context, the other major shift happening on the certificate side — the post-quantum transition — is covered separately in Why PQ Certificates Aren't Here Yet. The two trends are linked — the shorter the lifetime, the faster algorithm rotation becomes. This post sticks to lifetime and automation.

What SC-081v3 Actually Set — Two Tables from the Source

Here's the maximum-lifetime schedule from BR Section 6.3.2. I confirmed the current BR (v2.2.8, 2026-06-16) still carries the exact wording from when the ballot passed.

Based on issuance date	Before this date	Maximum validity
—	2026-03-15	398 days
From 2026-03-15	2027-03-15	200 days
From 2027-03-15	2029-03-15	100 days
From 2029-03-15	—	47 days

Each stage carries a SHOULD NOT ceiling one day lower (397, 199, 99, 46 days). The BR defines a day as 86,400 seconds and specifies that exceeding it by even one second counts as an extra day — which is why the "SHOULD NOT issue right at the maximum" clause is written in alongside it. That's where Let's Encrypt's 45-day figure, covered later, comes from.

And here's the domain/IP validation data reuse schedule from the same ballot's revision to Section 4.2.1.

Based on issuance date	Before this date	Validation data reuse limit
—	2026-03-15	398 days
From 2026-03-15	2027-03-15	200 days
From 2027-03-15	2029-03-15	100 days
From 2029-03-15	—	10 days

Look at the last row again. The lifetime is "shrinking" to 47 days, but domain validation (DCV) reuse "collapses" to 10 days. This is the first point where the reuse window becomes shorter than the certificate lifetime itself. It means that for a 47-day certificate, there's a good chance you won't be able to reuse the previous validation on renewal — renewal effectively becomes "re-validate every time." Reuse of subject identity information that isn't domain/IP (things like an OV certificate's organization data) also shrinks, from 825 days to 398 days, starting 2026-03-15.

The ballot text states its own goal directly — a certificate is a snapshot proving facts at the time of issuance, and the gap between that snapshot and reality only widens over time; and since revocation infrastructure hasn't scaled reliably or cost-effectively at internet scale, the plan is to make protection "certain" by shortening lifetime itself instead. One interesting detail — the ballot text itself describes wider automation adoption as an "ancillary benefit." The order isn't "shorten lifetimes to force automation" — it's "shorten lifetimes, and automation follows as a side effect."

What the Vote Tallies Tell You — 2019 vs. 2025

This isn't the first attempt. The 2019 SC22 ballot proposed cutting the maximum lifetime to one year, and it failed on the CA side, 11 in favor to 20 against (2 abstentions) — a 35% approval rate. The browser side (Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360), by contrast, voted unanimously in favor, all 7. Despite that failure, the BR revision history shows a 398-day maximum took effect anyway as of 2020-09-01 — the root programs effectively set the direction outside the forum's own vote.

The picture for 2025's SC-081v3 is completely different. Proposed by Apple's Clint Wilson and endorsed by Sectigo, Google Chrome, and Mozilla, it passed in a vote that closed 2025-04-11 with the CA side going 25 in favor, 0 against, and 5 abstentions (Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems, TWCA) out of 30 votes. The browser side was unanimous, all 4. GoDaddy, GlobalSign, D-TRUST, Izenpe, and SwissSign — all of which voted against in 2019 — flipped to yes this time, and of the 2019 opponents, SECOM and TWCA stepped back to abstain. Zero votes against reads partly as the industry accepting the direction, but honestly it's probably also the 2020 lesson sinking in — that the root programs can force the issue regardless of how the forum votes.

Let's Encrypt's Actual Transition Dates — 90 → 64 → 45

The BR schedule is a ceiling; what operators actually feel is their own CA's schedule. In December 2025, Let's Encrypt announced its plan to go from 90 days to 45 days and pinned down dates. The transition rolls out per ACME profile.

2026-05-13 — the tlsserver profile moves to 45-day certificates. It's an opt-in profile, meant for early adopters and testing. This has already taken effect, and the current profile documentation already reflects 45 days.
2027-02-10 — the default classic profile moves to 64-day certificates plus 10-day authorization reuse. This covers everyone who hasn't picked a different profile.
2028-02-16 — classic moves to 45-day certificates plus 7-hour authorization reuse.

Each change ships to staging roughly a month ahead of production. Two things stand out — 45 is smaller than 47 (margin against the 86,400-second rule and the "don't issue right at the max" clause noted above), and 2028-02-16 lands about thirteen months ahead of 2029-03-15, the date the BR mandates 47 days. Let's Encrypt is moving a full year ahead of the BR deadline.

Here's how the three profiles the current production directory advertises compare, per the docs (as of the 2026-07-14 revision).

Property	classic	tlsserver	shortlived
Certificate lifetime	90 days	45 days	160 hours (just over 6 days)
Authorization reuse	30 days	7 hours	7 hours
Challenge completion deadline	7 days	1 hour	1 hour
Order lifetime	7 days	8 hours	8 hours
CN / KE-KU / SKID	included	removed	removed
Max name count	100	25	25
Identifier types	DNS	DNS	DNS, IP

There's a reason tlsserver's authorization reuse is set to 7 hours — the BR requires CAA re-checking within 8 hours before issuance, so setting reuse to 7 hours means you never need to re-check at all. As for worries about renewal volume, Let's Encrypt addressed that separately — going from renewing a 90-day certificate at day 60 to renewing a 45-day certificate at day 30 doubles renewal requests, but renewals are exempt from rate limits, so the daily new-domain issuance cap (300 per account per day) is unaffected.

6-Day Certificates and IP Certificates — Already in General Availability

There's already an option that goes further out than the end of the schedule (47 days). Let's Encrypt's shortlived profile has been generally available since January 15, 2026. At a 160-hour lifetime, it falls within the 7-day (604,800-second) ceiling the BR recognizes as a "Short-lived Subscriber Certificate" starting 2026-03-15. Classification as short-lived makes revocation support optional under the BR rather than mandatory. Even if a key leaks, expiration at 6 days closes the window, so instead of leaning on unreliable revocation infrastructure, protection comes from lifetime itself. That said, CRL URLs are currently still included on certificates from this profile — the discussion to drop them is open at boulder#7673.

IP address certificates, which reached GA alongside shortlived after their first issuance in July 2025, must use shortlived. That's a policy Let's Encrypt set because IP ownership changes hands more often than domain ownership. certbot's support for this landed this past March — the profile-selection flag --preferred-profile shipped in certbot 4.0, the --ip-address flag in 5.3, and webroot-mode IP support in 5.4. Note that the nginx and apache installer plugins still don't support IP certificates, so you have to wire them up directly via deploy hooks.

It's worth carrying over verbatim that Let's Encrypt itself says the short-lived profile "is not for everyone" and has explicitly stated it has no plans to make it the default. A 160-hour certificate means a renewal pipeline that's been down for roughly four days already leads to expiration. Don't pick it until you fully trust your automation.

Stop Hardcoding Renewal Timing — ACME ARI (RFC 9773)

Hardcoding something like "renew 30 days before expiry" is a relic of the 90-day era. Rather than keep tuning that threshold as lifetimes move 90 → 64 → 45, there's already a standard for the CA to tell you when to renew — RFC 9773, ACME Renewal Information (ARI), published in June 2025. It took four years to reach standardization from its first draft in September 2021, and Let's Encrypt's server side (Boulder) has supported it since late 2021, back when it was still a draft. I also confirmed that the renewalInfo endpoint is live on the current production directory right now.

The mechanism is simple. The client builds an identifier from the certificate's AKI and serial and asks for it; the server returns a recommended renewal window.

GET {renewalInfo}/base64url(AKI keyIdentifier).base64url(Serial)

HTTP/1.1 200 OK
Retry-After: 21600

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end":   "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}

The client picks a random point inside the window and renews there, then checks again after the Retry-After interval to see if the window has shifted. A renewal order can name the certificate it's replacing via the replaces field, which a CA can use for renewal identification and rate-limit handling per its own policy. The RFC even specifies that a client MUST NOT keep asking about an expired certificate.

This protocol's real value shows up not in normal operation but during incidents. When a CA has to do a mass revocation — Let's Encrypt revoked roughly 2 million certificates in January 2022 after a TLS-ALPN-01 validation bug — the CA can respond with a pulled-forward renewal window, and clients watching ARI finish replacing their certificates before the revocation is enforced. A human-in-the-loop process doesn't reach most sites within a 24-hour or 5-day revocation deadline. Shopify's case is the textbook example — they were running millions of domains on "renew 30 days before expiry plus 0–72 hours of jitter," then contributed ARI support directly to the Ruby acme-client gem and handed renewal timing decisions off to the CA (the description of the effect is Shopify's own account — no quantified figures have been published).

Here's where client support stands, all confirmed from the original changelogs and docs.

certbot — as of 4.1.0 (2025-06-10), certbot renew checks ARI automatically. With Let's Encrypt, that works out to renewal at roughly two-thirds of the lifetime, and as of 5.0.0, Retry-After is preserved across runs.
lego — the CLI checks ARI unless explicitly disabled, and even implements the replaces field.
Caddy/CertMagic — the README states full support for RFC 9773.
cert-manager — the most recent to join. v1.21.0 (2026-07-08) added ARI support behind the ACMEUseARI feature gate. This is a request issue opened in May 2023 finally moving three years later, and it's still not on by default. If you're running certificates on Kubernetes — the same stack covered in the cert-manager deep dive — that means you have to handle the upgrade and enabling the gate separately.

For clients without ARI, the fallback Let's Encrypt recommends is sticking to "renew at two-thirds of lifetime." For a 45-day certificate, that's day 30. A fixed 60-day cycle configuration is simply an outage waiting to happen in the 45-day era.

What Hasn't Arrived Yet — Where DNS-PERSIST-01 Stands

The last piece of the lifetime-shortening puzzle is validation automation. As the reuse window collapses, validation has to happen more often — and today's DNS-01 requires writing a fresh token as a TXT record on every renewal, which means DNS API credentials keep flowing through various parts of the issuance pipeline. That's what DNS-PERSIST-01 is for — a standing authorization record naming the CA and the ACME account that, once planted, doesn't need to change on every renewal.

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
)

Adding policy=wildcard covers wildcards and subdomains too, and if a standing authorization feels uncomfortable, persistUntil can set an expiration. The standards side is done — CA/B Forum ballot SC-088v3 passed unanimously in October 2025 and is now in the current BR as Section 3.2.2.4.22 ("DNS TXT Record with Persistent Value"), which also carries the _ip-validation-persist variant for IP addresses.

But it doesn't exist in practice yet. The February announcement targeted "staging by end of Q1, production in Q2," but the actual state as of now is this — staging has a draft implementation (the late-April draft-01 update made accounturi a required field on the challenge object), and production hasn't opened. A Let's Encrypt engineer's reply on the community forum on June 25 sums up the current state accurately — they won't deploy until draft issue #64 (whether to include client-computed information in the record) is resolved. There was also a May reply noting that "if IETF consensus is delayed, this could slip to Q3." It hasn't been listed in the official challenge type documentation yet, either. In short, you shouldn't architect around DNS-PERSIST-01 right now — staging experiments are as far as it goes.

The announcement itself notes the design tradeoff honestly, too — moving DNS write credentials out of the pipeline comes at the cost of tying the standing authorization to the ACME account, which makes the account key the new most-critical secret. Using this without a proper account-key storage and rotation setup just moves the risk elsewhere.

So, What Should You Prepare?

Translating the schedule into operational terms looks like this.

Start with inventory. The first job is finding certificates that get renewed manually — an annual calendar reminder, a quarterly ticket, a file uploaded through a device console. Manual work can get by on twice-a-year effort in the 200-day era, but that's four times a year at 100 days, and roughly monthly at 47 days. The problem with manual work isn't the count itself — it's that the probability of a single miss multiplies as the count grows.
Client versions and ARI. If you're on certbot below 4.1, a homegrown script without ARI, or a fixed-interval cron job, upgrade now. Delegating the renewal-timing decision to the CA is the cheapest insurance available for this entire schedule.
Monitoring should watch for looming expiry, not renewal success. A renewal pipeline that dies silently is more dangerous than one that fails loudly, and the shorter the lifetime, the shorter the window during which "silently dead" can go unnoticed. On a 45-day certificate, a two-week holiday-season outage is an expiration incident.
Automate the validation path. Starting 2027-02-10, Let's Encrypt's default profile cuts authorization reuse to 10 days, and to 7 hours in 2028. A setup where renewal is automated but validation — especially DNS-01's TXT record updates — is semi-manual breaks right here. Until DNS-PERSIST-01 reaches production, you need to decide whether to live with managing DNS credentials or move to HTTP-01/TLS-ALPN-01.
Save the short-lived profile for last. A 6-day certificate that erases revocation worries is tempting, but the right order is to first get through several incident-free quarters at 45 days.

And to be clear about the other side of this — what this schedule does not force. The BR's scope is publicly-trusted certificates used "for server authentication accessible on the internet." Internal PKI run on a private CA, closed-network equipment, and internal mTLS certificates set their own lifetimes independent of this schedule. If an internal system that doesn't strictly need public trust can't handle a 47-day cycle, moving to a private PKI instead of automating is also a valid answer — and that judgment call itself is an extension of the operating principles covered in the zero-downtime renewal playbook.

Closing

To sum up: the dates are locked in — 200 days (already in effect), 100 days from 2027-03-15, 47 days from 2029-03-15, and 10-day validation reuse on that same date. Let's Encrypt has layered its own schedule on top — 64 days by default at 2027-02-10, 45 days by default at 2028-02-16. Most of the tooling is already here too — ARI is a finished RFC and is in the major clients, and 6-day certificates are GA. The one thing still missing is DNS-PERSIST-01's production rollout, and even there the standards work and staging are done.

So the remaining variable isn't the standard or the CA — it's each team's own operations. The failure mode of the 47-day era isn't "forgot to renew," it's "automation died silently." What you need to build right now isn't a tighter calendar reminder — it's a pipeline that runs without needing reminders, and an alarm that fires when that pipeline dies.