SSL Certificate Validity Drops to 47 Days by 2029: Automate Now

On 19 April 2025, the CA/Browser Forum passed a ballot that will reshape how every public website and API is secured. The maximum validity of publicly trusted SSL/TLS certificates will drop in three steps: 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. The vote was 29 in favour and zero against; certificate issuers voted 25–0 with five abstentions; Apple, Google, Microsoft, and Mozilla voted unanimously in support. Domain Control Validation (DCV) reuse periods drop in lockstep — to 200 days, then 100 days, then 10 days by 2029. For developers and DevOps, the message is unambiguous: manual certificate renewal will not scale. Automation is no longer optional.

Why the change. Shorter certificate lifetimes shrink the window in which a compromised key can be abused, improve crypto agility for post-quantum transitions, and push the industry toward fully automated certificate lifecycle management. Apple has been a leading driver; browser vendors and CAs have aligned. The 398-day maximum that many teams still rely on is being phased out. Anyone issuing or relying on publicly trusted certs must plan for 47-day validity as the end state.

Who is affected. The rules apply to certificates that chain to roots in system and browser trust stores — in practice, the certs you get from Let us Encrypt, Sectigo, DigiCert, GlobalSign, and similar public CAs. Internal PKI and private roots are not bound by the CA/Browser Forum, but many organisations will align internal practice to avoid confusion. If your domain is on the public internet and users hit it in Chrome, Safari, Edge, or Firefox, assume your certs must comply.

What to automate now. (1) ACME. The ACME protocol (RFC 8555) is the standard for automated issuance and renewal. Let us Encrypt and ZeroSSL offer free ACME endpoints; many commercial CAs support ACME as well. Use ACME clients (certbot, acme.sh, or the cert-manager ACME issuer) to request, validate, and renew certs without manual CSRs or approval emails. (2) cert-manager. On Kubernetes, cert-manager is the de facto standard. Define Certificate resources and ClusterIssuers (or Issuers) that point at your ACME server; cert-manager handles challenge completion (HTTP-01 or DNS-01), issuance, and renewal. Set renewal before expiry (e.g. 30 days before) so 47-day certs still leave margin for failures. (3) DNS-01 for wildcards and hidden services. HTTP-01 requires a reachable web root; DNS-01 uses TXT records and works for wildcards and hosts not exposed on port 80. If you use wildcards or internal-only hostnames that are validated via DNS, automate DNS-01 with a provider (Cloudflare, Route53, etc.) that cert-manager or your ACME client can drive via API. (4) Monitoring and alerting. Treat certificate expiry as a critical metric. Alert on certs expiring in under 30 days; run periodic scans of all hostnames you care about and ensure renewal pipelines are green. The death of manual renewal means the only way to avoid outages is to make renewal automatic and then monitor it.

What fails if you wait. At 47-day validity, renewing by hand means touching certs more than seven times a year per hostname. Miss one cycle and you get hard browser errors, broken APIs, and lost trust. At 100-day validity (2027), the same problem is only slightly less acute. Teams that defer automation will be forced into it under pressure when the first 200-day certs expire in 2026; those that automate now will already have runbooks, monitoring, and rollback experience. The 47-day deadline is the finish line; the starting line is today.