SSL Certificates Drop to 200-Day Validity on March 15, 2026. Here's What Developers Must Fix.

On 15 March 2026, the maximum validity of public SSL/TLS certificates drops from 398 days to 200 days. This is not a rumour; it comes from CA/Browser Forum ballot SC-081v3, which browser vendors and certificate authorities have already committed to. It is the first step in a staged schedule: 200 days in 2026, 100 days in 2027, and 47 days in 2029. Only publicly trusted certificates are affected — internal PKI can keep longer lifetimes — but for most internet-facing apps, APIs, and dashboards, your renewal frequency is about to double. If your team is still renewing certs with calendar reminders and copy-pasted CSRs, you are signing up for outages.

Why This Is Happening

Shorter certificate lifetimes are a security and agility play. They shrink the window in which a compromised key can be abused and make it easier to rotate keys in response to new crypto requirements, including post-quantum algorithms. Browser vendors have also been pushing toward a world where certificates are effectively disposable infrastructure — cheap, frequent, and fully automated. The days of "set a three-year cert and forget" are long gone; the 200-day limit is just the latest turn of the ratchet.

Who Is Affected

The 200-day rule applies to publicly trusted certificates that chain to roots in browser and OS trust stores — in practice, the certs you get from providers like Let's Encrypt, Sectigo, DigiCert, GlobalSign, and others. Internal-only certs issued by your own CA (for service-to-service traffic inside your VPC, for example) are not directly subject to CA/B Forum rules, but many organisations will align internal practice to avoid confusion. If your domain is on the public internet and users access it via Chrome, Safari, Edge, or Firefox, assume your certs must comply.

What Developers and DevOps Must Do Now

1. Inventory your certificates. Build or adopt a tool that can scan your domains, subdomains, and APIs, list all certificates, and show expiry dates. Include wildcard certs, legacy marketing domains, admin panels, and staging environments that someone exposed to the internet.

2. Automate issuance and renewal. Use ACME (e.g. Let's Encrypt, ZeroSSL) or your provider's API to fully automate certificate lifecycle: request, validate, install, reload. For Kubernetes, integrate with cert-manager or your ingress controller; for traditional stacks, script renewal and reload of nginx/Apache/Envoy.

3. Remove humans from the critical path. Calendar reminders and manual CSR generation do not scale when you are renewing every 200 days (and soon every 100, then 47). Treat certificates as code: check configuration into version control, run automated checks in CI, and alert on upcoming expiries from monitoring rather than personal calendars.

4. Plan for even shorter lifetimes. Do not design processes that just barely handle 200 days. Assume 47-day certificates are the end state. That means automation, strong observability on expiry, and safe rollback paths when issuance fails.

The 200-day deadline is not a one-day event; it is the start of a permanent change in how we run HTTPS. Teams that invest in automation now will barely notice the transition. Teams that do not will be paged at 3 a.m. when their login page throws "NET::ERR_CERT_DATE_INVALID" in front of every user.