TLS Certificate Lifetimes in 2026: 200 Days Now, 47 Days by 2029

Every few years the web decides certificates should live shorter lives, and every time a few teams find out from an outage page. This round is different in scale: the CA/Browser Forum voted in April 2025 to take the maximum lifetime of a public TLS certificate from 398 days down to 47 days by 2029, in three steps, and the first step (200 days) took effect on 15 March 2026. The certificates issued that week are expiring right now. This post explains the TLS certificate lifetime schedule in ballot SC-081, why the browsers wanted it, what Let's Encrypt changed alongside it (OCSP, expiry emails, ACME profiles, six-day certificates, a move to 45 days), and what that means for anything you still renew by hand.

What did CA/Browser Forum ballot SC-081 change?

Ballot SC-081v3 was proposed by Clint Wilson of Apple and endorsed by Sectigo, Google Chrome and Mozilla. Voting closed on 11 April 2025 with 25 certificate issuers in favour, none against and five abstaining, and all four browser vendors (Apple, Google, Microsoft, Mozilla) voting yes. It changes two numbers in the Baseline Requirements: how long a certificate may be valid, and how long a CA may reuse a previous domain control validation (DCV) before it has to check again.

Certificates issued on or after	Maximum validity	DCV reuse period
Before 15 March 2026	398 days	398 days
15 March 2026	200 days	200 days
15 March 2027	100 days	100 days
15 March 2029	47 days	10 days

Sources: endpoints and vote from the CA/Browser Forum ballot page; intermediate steps from Sectigo's summary and DNSimple's announcement.

The dates apply to issuance, not to certificates already in the wild. A 398-day certificate issued in January 2026 stays valid until its natural expiry. I checked a few public sites today with openssl (the loop is further down): www.microsoft.com is serving a certificate issued on 22 January 2026 that runs to 17 January 2027, just under the old cap, while www.digicert.com is already on a 46-day certificate issued on 11 October.

The DCV column matters more than people expect. At 10 days in 2029, the CA effectively has to re-prove you control the domain for almost every renewal. Anything that relied on "validate once a year, issue whenever" stops working.

Why are TLS certificate lifetimes getting shorter?

The ballot's rationale is mostly about revocation. When a key leaks or a certificate is misissued, the CA revokes it, and browsers are supposed to notice. In practice they often do not: the ballot says revocation mechanisms are unreliable and costly at internet scale, and that expiry, by contrast, is something every client enforces. Its own phrasing is blunt: "Certificate validity periods, and their enforcement by relying parties, are incredibly reliable."

The second argument is data freshness. A certificate is a snapshot of facts at issuance (who controls the domain, which organisation asked for it). Domains change hands. A shorter lifetime and a shorter DCV reuse window shrink how long stale facts can sit inside a trusted certificate. The ballot also lists faster algorithm transitions, which is worth taking seriously given the post-quantum migration that everyone will eventually have to roll through their certificate estate.

Automation is described as a side effect, not the goal. I think it is the real consequence for operators, though. At 398 days, a spreadsheet and a calendar reminder were bad practice but survivable. At 47 days, a team with 200 certificates renews about four a day, every day, forever.

What Let's Encrypt changed: OCSP, expiry emails and client auth

Let's Encrypt has been running ahead of the ballot, and its changes land on a lot of infrastructure because it is the CA most ACME clients, cert-manager included, are pointed at by default in their docs and examples.

OCSP is gone. Let's Encrypt announced in December 2024 that it would drop OCSP URLs from certificates on 7 May 2025 and turn off its OCSP responders on 6 August 2025, relying on CRLs instead. Requests for OCSP Must-Staple certificates started failing on 7 May 2025 as well. If you had ssl_stapling on in nginx it simply has nothing to staple now; if you had an internal client that hard-failed without an OCSP response, it needs changing.

Expiry emails ended. The reminder emails stopped on 4 June 2025, with privacy and cost given as the reasons. For many small teams those emails were the monitoring. The 2026 postmortems I read while researching this suggest some never replaced them.

Client authentication was removed. Chrome's root program set a June 2026 deadline to split TLS server and client authentication into separate PKIs, so Let's Encrypt stopped including the Client Authentication EKU in its default profile on 11 February 2026 and retired the transitional tlsclient profile on 8 July 2026. If you used Let's Encrypt certificates for mTLS between services, or something like database replication that presents a server certificate as a client, that path is closed. Use a private CA.

Shorter certificates are on a schedule. The December 2025 announcement moves Let's Encrypt from 90 to 45 days and cuts authorization reuse from 30 days to 7 hours. The opt-in tlsserver profile switched to 45 days on 13 May 2026; the default classic profile goes to 64 days (10-day authorization reuse) on 10 February 2027 and to 45 days (7-hour reuse) on 16 February 2028. Each change hits staging about a month earlier.

ACME profiles: classic, tlsserver and shortlived

The mechanism that makes this manageable is ACME profiles, an extension that lets a client ask for a category of certificate rather than accept whatever the CA defaults to. Let's Encrypt's profiles documentation (updated 4 October 2026) lists three live profiles:

Profile	Validity	Authorization reuse	Notes
classic	90 days today (64 days from Feb 2027, 45 from Feb 2028)	30 days	Default when no profile is requested; keeps Common Name and Key Encipherment for RSA
tlsserver	45 days	7 hours	No Common Name, no Key Encipherment; the future default shape
shortlived	160 hours (about 6 days)	7 hours	Opt-in, generally available since 15 January 2026, required for IP address certificates

Source: Let's Encrypt profiles docs and the ACME directory below.

The authoritative list is the directory itself, which anyone can query:

# Ask Let's Encrypt production which ACME profiles and endpoints it offers today.
# Output captured 2026-10-20 (random directory key and ToS trimmed).
curl -s https://acme-v02.api.letsencrypt.org/directory | jq '{profiles: .meta.profiles, renewalInfo}'
# {
#   "profiles": {
#     "classic":    "https://letsencrypt.org/docs/profiles#classic",
#     "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
#     "tlsserver":  "https://letsencrypt.org/docs/profiles#tlsserver"
#   },
#   "renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info"
# }

# Check what any public endpoint is actually serving: issuer, dates, OCSP vs CRL, EKU.
for h in letsencrypt.org github.com www.digicert.com www.microsoft.com; do
  echo "== $h"
  echo | openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null \
    | openssl x509 -noout -issuer -startdate -enddate
done

When I ran that, letsencrypt.org itself was on a 90-day classic certificate from the new YE2 intermediate, with a CRL distribution point, no OCSP URL, and only the TLS Web Server Authentication EKU. That is the post-2025 Let's Encrypt certificate in one screen.

The shortlived profile is the one to think hardest about. Six days is long enough to survive a weekend but not a long holiday weekend with a broken renewal, and Let's Encrypt says it is meant for people who fully trust their automation. Its real advantage is that a leaked key stops working within days without anyone needing revocation to function.

What is ARI, and why does it matter for short certificates?

Most ACME clients decide when to renew with a rule: a cron job, a fixed number of days before expiry, or a fraction of the lifetime (cert-manager's default is two thirds of the duration). That worked when lifetimes were long and nothing unusual happened. ACME Renewal Information, published as RFC 9773 in June 2025, lets the CA tell the client a suggested renewal window instead. The CA can spread load, and, more importantly, it can pull the window forward for everyone before a mass revocation event.

Let's Encrypt has two practical incentives for using it. Its rate limit page says renewals coordinated through ARI are exempt from all rate limits, and its 45-day announcement tells clients without ARI that a fixed 60-day renewal interval will no longer work. cert-manager added ARI in v1.21.0 as experimental, behind the ACMEUseARI feature gate; certbot, Caddy and lego users should check their client's own docs.

What breaks at 47 days and 10-day DCV reuse?

Not the certificates. The surrounding process breaks. The patterns I would audit:

• Manual installs. Load balancers, appliances, SaaS custom domains and CDN configs where someone pastes a PEM into a web form. At 200 days that is twice a year; at 47 days it is a job.
• Silent renewal failures. ImprovMX's May 2026 postmortem describes automatic renewal failing for weeks after a credential rotation, then about six hours of failed SMTP sending, found through a customer's churn report. Lucidworks' July 2026 incident had a 30-day warning that reached a channel nobody acted on, plus an alert pipeline that had quietly stopped paging. Both are DevOps problems, not PKI problems: the automation existed and nobody watched it.
• DNS credentials. DNS-01 validation every few days means your DNS API token is now production-critical and gets used constantly. Scope it to one zone.
• Pinning and trust stores. Anything that pins a leaf certificate, or ships a fixed bundle on embedded devices, breaks on every rotation.
• Paid CA orders. Organisation-validated certificates still need the CA to re-check details more often as reuse periods shrink; the ballot cuts non-domain validation reuse from 825 to 398 days.

Let's Encrypt is also adding a new validation method aimed at the DNS problem. DNS-PERSIST-01 uses a single TXT record at _validation-persist.<domain> that names the CA and binds to a specific ACME account, so it does not change on every renewal. The February 2026 post targeted staging in late Q1 and production some time in Q2 2026; I could not find a confirmed production launch notice, so check before you design around it. The trade is clear either way: the DNS write disappears, and the ACME account key becomes the thing to protect.

If you run cert-manager, the companion cert-manager and Let's Encrypt setup and troubleshooting guide walks through issuers, profiles, the Order and Challenge chain and the alerts I would add. For Ingress users there is an extra wrinkle: the Ingress NGINX retirement means many HTTP-01 setups will move to Gateway API at the same time.

FAQ

When do 47-day TLS certificates start?

Certificates issued on or after 15 March 2029 can be valid for at most 47 days under CA/Browser Forum ballot SC-081. Before that, the cap is 200 days from 15 March 2026 and 100 days from 15 March 2027. Certificates issued before each date keep their original expiry.

Do 200-day certificates affect Let's Encrypt users?

Not directly, because Let's Encrypt certificates are already 90 days or shorter. What affects Let's Encrypt users is its own schedule: 64-day default certificates from 10 February 2027 and 45 days from 16 February 2028, with the opt-in tlsserver profile already at 45 days.

Does the 47-day limit apply to private or internal CAs?

No. The Baseline Requirements cover publicly trusted TLS certificates. A private CA used for service mesh or internal mTLS can set whatever lifetime you choose. The automation lessons apply anyway, and internal certificates are often the ones nobody inventoried.

Should I enable ARI?

Yes, if your client supports it. ARI lets the CA move your renewal earlier during incidents, and Let's Encrypt exempts ARI-coordinated renewals from rate limits. In cert-manager it is still experimental, so turn it on in staging first.

This quarter I would do three things. First, inventory every certificate that is not renewed by an ACME client, because those are the ones that will hurt at 100 days in March 2027, and that date is only five months away. Second, put expiry and failed-renewal alerts on a paging path, not in a channel, and test them by breaking a staging issuer on purpose. Third, move ACME clients that support it onto ARI and the tlsserver profile now, so the 2027 and 2028 Let's Encrypt changes are a non-event rather than the first time 45-day certificates touch production.

Related: Post-Quantum Migration in 2026: What's Done, What's Stuck, and What to Do This Quarter, DevOps Still Matters in 2026: AI Cut Delivery Stability 7.2%, Then Doubled Merged PRs and Added 91% to Review Time and CRA Reporting Went Live on 11 September: 24 Hours to ENISA, 3.08 Billion Rekor Entries, 17% of PyPI Attested, 92% SBOM False Positives.