Skip to content

47-Day TLS Certificates: SC-081 Timeline and Automation Guide

Publicly trusted TLS maximum validity drops in phases to 47 days (March 2029) under SC-081v3; DCV reuse shrinks on the same schedule—this page is the engineer-oriented timeline and scope guide.

47-Day TLS Certificates: SC-081 Timeline and Automation Guide

Section titled “47-Day TLS Certificates: SC-081 Timeline and Automation Guide”

TL;DR: SC-081v3 is live in phases (200 → 100 → 47 days); 10-day DCV reuse by 2029 forces automated challenges every renewal—pair this with ACME + ARI readiness and renewal automation.

The ballot passed 2025-04-11 (CA/B Forum). Apple proposed; Google, Microsoft, Mozilla supported. Two coupled parameters move together: maximum subscriber certificate lifetime and DCV reuse period. For business framing and ROI math, see certificate automation ROI.

  • Renewal frequency jumps toward ~8×/year per cert at 47 days—manual processes collapse.
  • DCV reuse to 10 days means near every renewal needs successful automated DCV.
  • Load balancers / CDNs fail when new certs exist on disk but the edge never reloads.
  • Legacy gear without ACME needs architecture change (proxy, private PKI) or accepts outage risk.
  • OV/EV faces the same lifetime rules; SII reuse drops in phase 1 (see below).

Failure scenario: Team hits 100-day phase still using quarterly manual renewals; DCV email approvals miss one cycle—customer-facing API presents expired cert.

PhaseEffective (approx.)Max TLS subscriber cert lifetime
12026-03-15200 days (~6-month cadence). SII reuse for OV/EV 825 → 398 days.
22027-03-15100 days. DCV reuse 100 days.
32029-03-1547 days. DCV reuse 10 days.

Major CAs may early-adopt (e.g. 199-day issuance before deadlines).

Shorter cert lifetime gets attention; shorter DCV reuse forces automation of proof-of-control at every renewal. A 47-day cert with 10-day DCV reuse is far harsher than 47-day with long reuse—SC-081v3 moves both.

  • Private PKI / internal names
  • S/MIME, code signing, document signing (other BR tracks)
  • IoT / IDevID style identities under their own standards

Only publicly trusted TLS for server authentication in scope of the TLS BRs driving this ballot.

If ACME already renews (e.g. certbot), 200-day phase may feel similar to today’s short-LV DV certs—risk rises at 100d/47d if ARI and deploy hooks are weak. Verify client version, DNS API token expiry, and reload hooks.

Managed (ACM, Cloudflare) often absorb change; self-managed must push + reload on every renewal. At 47 days, a missed reload becomes an outage within weeks.

cert-manager: tune renewBefore; enable ARI where supported (1.15+); validate Issuer/ClusterIssuer ACME endpoints.

Terminate TLS on a modern proxy, or use private CA for names that cannot meet public-BR automation.

ARI lets the CA steer renewal timing and handle incidents; renewals in-window with replaces may avoid rate limits. See Certificate automation readiness for client matrix—Certbot 4.1.0+, Lego, cert-manager 1.15+, etc.

Inventory all public TLS certs: CA, expiry, renewal mechanism, deploy path. Use openssl s_client plus CT for completeness—see inventory and discovery.

No manual production renewals for public TLS at scale; upgrade to ARI-capable clients; test full pipeline quarterly; alert at ~80% of lifetime.

DNS API SLOs and fallback paths; confirm pipeline can sustain ~17-day effective cycle if renewing ~30 days before expiry on a 47-day cert.

Same lifetime caps as DV. SII reuse 398 days from phase 1—expect roughly annual org reverification; CAs often sell subscriptions with unlimited issuance to match.

LE may ship shorter defaults ahead of the mandate (e.g. movement toward 45-day defaults)—ecosystem tooling stress-tests before the global BR floor.

BR threshold for “short-lived” 10 days → 7 days after March 2026—aligns policy with very short experimental lifetimes (e.g. 6-day certs).

  • Exported inventory: name, CA, expiry, renew method, deploy owner
  • ACME client version checked for ARI if using LE-scale public DV
  • DNS API credentials: owner, rotation, monitoring
  • End-to-end renewal drill documented and scheduled
  • External monitoring for expiry and renewal failures
  • Plan for non-ACME gear (proxy, private PKI, or exception list)