Short Lived TLS Certificates: What the 47 Day Future Means for Your Site

The timeline, in plain English

The CA/Browser Forum (the body that sets baseline rules for public CAs and major browsers) approved a phased reduction of TLS certificate validity. The exact dates and caps are tracked by browsers and CAs, but the direction is clear. Today public certs are capped at 398 days. A first step takes that down to around 200 days. The following step lands near 100 days. The final step in 2029 caps validity at 47 days, with reduced limits on the age of domain validation data as well.

In practice, every public cert your site uses will be reissued multiple times per quarter by 2029. The only way this works at scale is automation. Manual renewal, shared wildcards handed around in chat, and once a year calendar reminders become liabilities, not safeguards.

What to fix now

You do not need to be on 47 days today, but you want your renewal path to be automated end to end. Concretely:

• Use ACME everywhere: Let's Encrypt, ZeroSSL, Google Public CA, and others all support ACME. Your web server, load balancer, or platform should request and rotate certs on its own.
• Drop long lived wildcards you renew by hand. They are convenient at 12 months. They are a pager at 47 days. Replace with per host automated certs or provider managed certs.
• Test the full chain after each renewal. A server that serves only the leaf will break clients that do not cache intermediates. See our certificate chain fix guide.
• Pin monitoring to health, not to days left. Track whether renewal ran successfully in the last N days and whether the current cert was issued recently, not only how many days it has left.
• Verify OCSP and CT logs. Shorter lifetimes mean more issuances, so CT visibility and any pinning strategy need to keep up.

Internal and private CAs

The 47 day cap targets publicly trusted certificates. Internal CAs (corporate roots installed on devices) are not bound by the CA/Browser Forum rules, so you technically can still issue long lived certs inside a private network. That said, most teams copy the public practice for internal services too, because short lived certs reduce blast radius when a key leaks and they force you to build proper rotation pipelines.

What changes for our tool

On every check, our SSL certificate checker shows issuer, validity window, and days to expiry. As lifetimes shrink, the "days to expiry" field becomes less meaningful on its own. We are shifting emphasis to issuer, issuance date, chain completeness, and automation health signals (Alt names, SAN count, reused serials across checks). Our security configuration monitor tracks grade, header presence, and HTTPS redirect on a weekly cadence, so you notice regressions even when the cert itself is rotating under the hood. See SSL and security headers monitor.

Expiry reminders: still useful, for now

We still offer a one shot expiry reminder email, sent roughly 30 days before expiry, for domains with a cert older than 35 days. As 200 day and 100 day maxima roll in, the window moves with them, and by the time 47 days is the cap, one shot reminders no longer add meaningful warning time. Treat the reminder as a transition tool, not a long term strategy. The long term answer is automation plus monitoring, not a bigger calendar.