The 47-Day Certificate Era: TLS Automation Becomes Mandatory for Self-Hosted Infrastructure

On March 15, 2026, every publicly trusted TLS certificate issued anywhere in the world got a lot shorter. That date marks the first step in a schedule that shrinks maximum certificate validity from 398 days down to 47 days by 2029 — an 88% cut. If your renewal automation was built around "certs last about a year," it has already started lying to you.

Here is the full schedule, because the dates matter more than the headline number.

The Timeline, in Full​

Two separate but overlapping schedules are driving this. The CA/Browser Forum's Ballot SC-081v3, passed unanimously in April 2025, sets the industry-wide ceiling every public CA must obey. Let's Encrypt, the CA that issues certificates for most self-hosted infrastructure, is moving faster than the floor requires.

CA/Browser Forum ceiling (applies to every public CA):

Let's Encrypt's own schedule (faster, and the one that actually governs most self-hosted stacks):

Source: Let's Encrypt, "Decreasing Certificate Lifetimes to 45 Days", Let's Encrypt Community — profile changes.

Read that second table again: by February 2028, the domain-validation proof your ACME client relied on is only good for seven hours. Today it's good for 30 days. That's not a tooling upgrade, it's a different validation model entirely — closer to continuous reauthorization than periodic renewal.

Why "Renew Every 60 Days" Cron Jobs Are Already Broken​

A lot of TLS automation in the wild was written once, for 90-day Let's Encrypt certs, and never revisited. The typical pattern: a cron job or systemd timer fires every 60 days, calls certbot renew, and reloads nginx. That job has 30 days of slack — plenty of room to survive a flaky run, a maintenance window, an on-call engineer who's out for a week.

Do that same math against a 47-day certificate. A renewal job on a 60-day interval will fire after the certificate has already expired. Even a well-intentioned "renew at the halfway point" policy — 23-24 days — leaves almost no slack for a failed DNS API call, a rate limit, or a broken webhook to get fixed before the site goes down with a browser warning. At enterprise scale, where a fleet of certificates renews on staggered schedules, manual or loosely-monitored renewal at this cadence is close to statistically guaranteed to produce an outage somewhere eventually.

The domain-validation reuse cut compounds this. Today, most ACME clients can renew a certificate without re-proving domain control, because the CA remembers your last validation for up to 30 days. Once that window shrinks to 10 days (2027) and then 7 hours (2028), your renewal automation isn't just running more often — it's re-running the entire proof-of-control flow almost every time. A DNS-01 challenge that updates a TXT record and waits for propagation, done every renewal, at monthly-or-faster frequency, is a fundamentally heavier automation requirement than what most self-hosted setups run today.

Concretely, three assumptions baked into a lot of existing self-hosted TLS tooling stop holding:

• "Renew twice a month is aggressive." It's now the minimum viable cadence, not a conservative buffer.
• "DNS propagation delay is a one-time setup cost." It becomes a per-renewal cost that has to complete reliably, unattended, dozens of times a year per domain.
• "A missed renewal has weeks of grace before it matters." The grace window is now single-digit days, trending toward hours.

What a Self-Hosted PaaS's TLS Layer Needs to Look Like​

If your platform auto-provisions HTTPS for tenant apps and custom domains — which is table stakes for anything git-push-to-deploy — this schedule is a forcing function on architecture, not just on renewal frequency. cert-manager, the CNCF project that's become the de facto standard for in-cluster certificate automation (deployed in an estimated 86% of new production Kubernetes clusters), is the right foundation, but the defaults most tutorials ship need tightening for this cadence.

Split platform subdomains from tenant custom domains. A wildcard certificate (*.yourplatform.com) covers every app on your own subdomain with one ACME transaction via DNS-01, issued against DNS records you already control. That's cheap to renew at any frequency because there's no per-tenant coordination involved. Tenant-supplied custom domains are different: each one needs its own certificate, typically via HTTP-01 (proving control by serving a token at a well-known path) since you don't have API access to a customer's DNS zone. That means your renewal automation has two different reliability profiles to manage, not one — and the custom-domain path is the one that breaks silently when a tenant's DNS or CDN configuration drifts.

Tune duration and renewBefore deliberately, not by default. cert-manager's Certificate resource lets you set spec.duration and spec.renewBefore (or renewBeforePercentage) explicitly. Leaving these at cert-manager's defaults, tuned for a world of 90-day certs, is exactly the stale assumption from the previous section baked into your platform instead of a customer's script. At 47 days, a renewBefore of even 10 days is cutting it close once you account for a failed attempt needing time to retry.

Budget for renewal volume, not just renewal correctness. cert-manager's own best-practice docs note that clusters with a high volume of CertificateRequest resources — which is exactly what "every cert renews 4-8x more often" produces — need more controller memory headroom, and that the webhook (which doesn't use leader election) should be scaled to three or more replicas once CR churn goes up. A single-replica cert-manager install that worked fine at annual renewal cadence is undersized for monthly-or-faster churn across a multi-tenant fleet.

DNS-PERSIST-01: The Fix for the Worst Part of This​

The part of this schedule that should worry self-hosted operators most isn't the 47-day expiry — automation handles frequent renewal fine once it exists. It's the domain-validation reuse window collapsing to 7 hours, because DNS-01 challenges typically require writing a new TXT record on every single validation. At that frequency, DNS-01 stops being "occasionally update a record" and becomes "your renewal pipeline needs live write access to a DNS zone, working correctly, constantly."

Let's Encrypt's answer, announced in February 2026, is DNS-PERSIST-01: a standing TXT record that names both the CA and the specific ACME account authorized to issue for a domain, published once, then reused for every subsequent issuance and renewal without ever needing to change. It directly targets the operational pain of the shrinking reuse window — you still need DNS write access to set it up the first time, but not on every renewal cycle after that.

For a platform that already runs wildcard DNS-01 for its own subdomains, DNS-PERSIST-01 is worth adopting as soon as your ACME client and DNS provider support it — it converts a per-renewal dependency (DNS API call succeeds, propagates, gets cleaned up) back into a one-time setup cost, which is the property the old 30-day reuse window used to give you for free.

Monitoring Has to Change Cadence Too​

When certificates renewed annually, "check expiry dates weekly" was a reasonable cadence for a Prometheus alert. At 47 days, weekly checks mean a renewal can fail on Monday and you find out on the following Monday — potentially after the certificate has already expired. cert-manager exposes certificate readiness and expiry-time metrics natively; wire them into whatever you already run (Prometheus + Grafana is the common self-hosted pairing) and alert on days-until-expiry thresholds scaled to the new cadence — not the old one. A threshold tuned for "warn 30 days out" on a 47-day certificate is a warning that fires with barely two weeks of runway; tune it closer to renewal-attempt-failed-twice than to a fixed day count.

The throughline across all of this: the CA/Browser Forum's schedule isn't really a certificate-management change, it's a statement that manual and semi-automated TLS is no longer a viable operating model for anyone running public HTTPS endpoints — self-hosted platform or not. By 2029, a 47-day certificate with 10-day validation reuse simply cannot be kept alive by a human checking a dashboard periodically.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with per-app and per-custom-domain TLS provisioned and renewed automatically on cert-manager underneath. Star the repo on GitHub or deploy your first app today.

Sources​

• CA/Browser Forum — Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• Let's Encrypt — Decreasing Certificate Lifetimes to 45 Days
• Let's Encrypt Community — Upcoming Profile Changes on May 13, 20th, and 27th
• Let's Encrypt — DNS-PERSIST-01: A New Model for DNS-based Challenge Validation
• cert-manager — Best Practice documentation
• TechTarget — TLS certificate lifetime changes: What CISOs must do now
• Encryption Consulting — Kubernetes Certificate Management With Cert-Manager