March 15, 2026 is the day SSL – or more precisely public TLS server certificates – stop feeling like “annual housekeeping” and start behaving like routine operations work for hosting platforms.
Nothing explodes on March 15 at 00:00, and existing certificates keep their original expiry dates. The change hits when you issue or reissue certificates from that point on: the maximum lifetime drops to 200 days, and the industry is already committed to shrinking it further.
The timeline you need on one screen
Here’s the schedule as it’s been set for publicly trusted TLS certificates (the ones browsers accept for HTTPS). “DCV reuse” is the window in which you can reuse prior domain validation instead of proving control again.
| Effective date (for certs issued on/after) | Max certificate lifetime (DV/OV/EV) | Max DCV reuse | OV/EV subject identity reuse |
|---|---|---|---|
| Until Mar 14, 2026 | 398 days | 398 days | 825 days |
| Mar 15, 2026 | 200 days | 200 days | 398 days |
| Mar 15, 2027 | 100 days | 100 days | 398 days |
| Mar 15, 2029 | 47 days | 10 days | 398 days |
One practical note for hosting teams: some CAs are already effectively enforcing a ~199-day ceiling in places, so you may be seeing “the future” early depending on your issuer and product mix.
Why this is happening, and what really lit the fuse
This isn’t a random CA decision. It comes out of the CA/Browser Forum’s rules, pushed by browser root programs and proposed by Apple. In plain terms: browsers decide what they will trust, and they want the trusted window to be shorter.
The logic is not complicated, even if it’s painful operationally:
Certificates are a snapshot of “who controls this domain and which key is valid” at issuance time. The longer that snapshot remains trusted, the longer you’re exposed if something changes – a key leaks, a domain changes hands, or a certificate was issued incorrectly. Shorter lifetimes reduce the blast radius.
The point that keeps coming up as the underlying tension is revocation. In theory, a bad certificate should be revoked quickly. In practice, revocation checking at internet scale has messy reliability and privacy tradeoffs, and browsers don’t treat it as a perfect safety net. Shorter lifetimes are the ecosystem’s blunt, dependable alternative: if you can’t count on every client checking revocation every time, reduce how long a mistake stays usable.
There were also explicit concerns raised about smaller operators falling off HTTPS if the process becomes too hard. The direction didn’t change anyway – the industry is choosing “force renewal to be easy” over “keep long lifetimes because some people renew manually.”
What this means for hosting providers, starting now
If you’re a hosting company, the story isn’t “certificates got shorter.” The story is “your platform will touch certificates more often, and failures will surface more often unless you redesign around that reality.”
At 200 days, you’ve roughly doubled the renewal cadence. At 100 days, renewals become a steady stream. At 47 days, you are basically living in continuous rotation. That affects a few very specific parts of your business:
First, issuance and deployment become high-volume plumbing. It’s not just calling the CA API more often. It’s pushing the new cert chain everywhere it needs to land – edge proxies, load balancers, ingress controllers, customer panels, CDN integrations, and any legacy endpoints still hanging around. The weak link is usually not “getting a certificate,” it’s “deploying it everywhere without one forgotten corner serving an expired cert.”
Second, DCV reuse tightening is the sleeper issue. Hosting platforms that rely on domain validation being “mostly done already” are going to feel pain as the reuse window shrinks, especially by 2029 when it drops to 10 days. That forces you to keep validation paths healthy all the time, not just during an annual renewal. If you use HTTP-based validation, your routing, redirects, WAF rules, and maintenance modes must not accidentally block challenges. If you use DNS-based validation, you need dependable DNS automation and clean permission boundaries, especially in multi-tenant setups and for customers who bring external DNS.
Third, product packaging has to match what browsers will accept. A “1-year certificate” can still be a 1-year purchase, but it cannot be a 1-year artifact anymore. You’ll be reissuing within the term, and customers should not be asked to care. If they do have to care, your support load goes up and your outage risk goes up.
Fourth, you’ll need better early-warning signals. When lifetimes are long, you can survive sloppy monitoring because you have time to notice and fix. When lifetimes are short, you need monitoring that catches renewal failures fast, plus safe retries and rollback paths so a single broken validation route doesn’t turn into a customer-facing incident.
If you already run fully managed renewals for most customers, this is still work, but it’s mostly scaling and hardening what you already do. If you still have a large “upload your cert and remember to renew it” population, March 15 is when that model starts generating more visible failures – and by 2027 it becomes a recurring headache.
Closing: treat it like routine operations, not a one-off migration
March 15, 2026 is the first step, not the whole event. The direction is clear: shorter lifetimes, tighter validation reuse, more frequent reissuance.
Hosting providers who treat certificates like any other operational lifecycle – automated issuance, automated deployment, constant validation readiness, and tight monitoring – will mostly turn this into a non-event for customers. Everyone else will experience it as a steady increase in avoidable outages and support tickets, year after year, as the timetable moves from 200 to 100 to 47 days.
Kamil Kołosowski
Author of this post.