SSL Certificates Now Expire Faster: What Owners of Older Servers Must Automate

Your SSL certificate used to last a year. Soon it will last six weeks. The CA/Browser Forum, the group that sets the rules every browser and certificate authority follows, voted through ballot SC-081v3 in April 2025, and the maximum lifetime of a public TLS certificate is now on a fixed countdown: 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. The ssl certificate validity 200 days change is the one that lands first and affects every public-facing site, API and internal tool with a certificate issued by a public certificate authority.

If your servers already renew certificates automatically through a modern load balancer or a managed platform, this is mostly a non-event. If any part of your infrastructure still has someone logging in once a year to paste a new certificate into an old appliance, a legacy load balancer, an internal admin tool or a payment terminal, that yearly task is about to become a job that runs six times a year, then eight, and eventually every 47 days. Missed renewals do not fail quietly. A browser or API client simply refuses the connection, and whoever depends on that system finds out when it is already down.

The ssl certificate validity 200 days deadline, and what follows it

The 398-day maximum has been in place since 2020. SC-081v3 shortens it in three steps, and the shorter windows apply to new certificates issued on or after each date, not retroactively to ones already in service. The first step cuts validity from 398 days to 200 days starting 15 March 2026. Twelve months later, on 15 March 2027, it drops again to 100 days. The final step, on 15 March 2029, brings it down to 47 days, which is roughly a month and a half.

A second, less visible part of the same ballot shortens how long a certificate authority can reuse a domain validation check before re-verifying it: from 398 days down to 200, then 100, then 10 days on the same schedule. That matters because it removes a shortcut some automation scripts quietly relied on. A renewal process built around "validate once, reissue for a year" will need to validate far more often, which is one more reason a manual process will not keep up.

Why this hits older infrastructure hardest

Most teams running a current content delivery network, a managed Kubernetes ingress, or a hosting platform with built-in Let's Encrypt integration will barely notice. Those systems already request and install certificates automatically, usually well before expiry, with no human in the loop.

The risk sits with everything that was set up before automated renewal was the default: a network appliance bought eight years ago, an internal reporting tool nobody has touched since the person who built it left, a VPN concentrator, a payment gateway integration, a staging environment that quietly became production. These systems tend to have certificates uploaded by hand through a web console, often by whoever happened to be available that week. Shrinking the renewal window from once a year to six or more times a year turns a rare, forgettable task into a recurring one that a busy team will eventually miss. One missed renewal on a customer-facing checkout page or an API partners depend on is the kind of outage that shows up as a support ticket flood, not a gentle warning.

Start with an inventory, not a tool

Before buying or configuring anything, find out what you actually have. List every domain and subdomain with a public certificate: the main website, the API, admin panels, VPN endpoints, anything a partner or customer connects to over HTTPS. For each one, note who issued the certificate, how it gets renewed today, and who would notice if it expired. Most organizations that go through this exercise find at least one system nobody remembered still had a certificate attached to it, and that is usually the one still being renewed by hand.

This inventory step overlaps with the broader hygiene question of which systems in your stack are still running without anyone clearly responsible for them; our end-of-life software checklist and the piece on who's actually on the hook for security updates both cover that gap, and a certificate inventory is a good excuse to close it. It usually takes an afternoon, not a project, and it is the single most useful hour you can spend before the 200-day window arrives.

Automating renewal before the window gets tighter

Once you know what you have, the fix for almost everything on the list is the ACME protocol, the same automated issuance process Let's Encrypt popularized. A small renewal client, commonly certbot, requests a new certificate, proves domain control, and installs it on a schedule, with no one needing to remember a date. Web servers like Caddy and reverse proxies like Traefik go further and handle the whole cycle internally: point them at a domain and they request, renew and reload certificates without a separate client or cron job.

For infrastructure that cannot run ACME directly, such as a locked-down appliance or a legacy on-premises system, the usual pattern is a small proxy or load balancer in front of it that terminates TLS with an automatically renewed certificate, so the old system itself never has to deal with certificate management at all. That is also the point at which it is worth asking whether the appliance should still be exposed directly to the internet in the first place.

Alongside automated issuance, set up expiry monitoring that is separate from the renewal process itself, a simple check that alerts a real person if a certificate is within a set number of days of expiring and has not renewed. Automation reduces the chance of a missed renewal; monitoring catches the cases where automation itself silently failed, which does happen when a DNS record changes, a rate limit gets hit, or a config drifts without anyone noticing.

What to ask your hosting provider or developer

If you outsource hosting or maintenance, ask directly: which of our certificates renew automatically today, and which still depend on someone remembering to do it by hand? Ask for the inventory list, not a verbal assurance. If the honest answer is "we're not fully sure," that is worth fixing now, while the renewal window is still 200 days and there is room to test a new process without a certificate expiring mid-fix. Waiting until the 100-day or 47-day stages to find out is a far more stressful way to learn the answer. A provider that cannot answer the question clearly today is unlikely to handle the tighter 100-day and 47-day stages any better without some outside pressure to fix it.

This is the kind of gap that shows up when nobody has a standing arrangement covering ongoing maintenance, which is exactly what we walk through in what a software maintenance retainer should include. A retainer that explicitly names certificate renewal and expiry monitoring as covered work means this stops being a surprise every March.

If you want a second set of eyes on which parts of your stack are still running on manual processes like this, or help setting up automated renewal and monitoring across an older environment, our tech stack strategy work covers exactly this kind of audit. Reach out at hello@wolf-tech.io or visit wolf-tech.io, and we'll help you find out what's still being renewed by hand before the next deadline finds it for you.