Some links here are affiliate links — if you buy through them we may earn a commission at no extra cost to you. It never changes what we recommend. Full disclosure.
For years, a public SSL/TLS certificate could last a little over a year — 398 days — and renewing it was an annual chore. That's over. In 2025 the CA/Browser Forum, the industry body whose rules every public certificate authority and major browser follows, approved a schedule that cuts the maximum certificate lifetime in stages until it reaches 47 days in 2029. The first step took effect on 15 March 2026, so if you've renewed a certificate this year you've probably already noticed it doesn't last as long as it used to.
This matters for every site owner, not only for people who buy commercial certificates. It changes how often things can break, what "set and forget" means, and which certificate setups are still sensible. Here's the schedule, what it means in practice, and how to get ahead of it.
The Schedule
| Certificates issued from | Maximum validity | Domain validation can be reused for |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
Two separate clocks are shrinking:
- Certificate validity — how long one issued certificate works before it expires.
- Validation reuse — how long the CA can rely on an earlier check that you control the domain before it must check again. By 2029 that's ten days, which effectively means domain control is re-proven at almost every issuance.
For OV and EV certificates, the verified organization details (company name, address and so on) can also be reused for a shorter period than before — 398 days under the new rules — so identity re-vetting comes round roughly once a year. If you're unsure what those levels are, see DV vs OV vs EV SSL Certificates.
Why the Industry Is Doing This
The short version: a certificate is a promise that, at the time it was issued, the holder controlled the domain. The longer that promise lasts, the more likely it is to be stale. Domains change hands, servers get decommissioned, keys get copied to places they shouldn't be, companies get acquired.
Revocation — the mechanism for cancelling a certificate early — has never worked reliably across browsers and devices. Shorter lifetimes limit the damage by making every certificate expire soon anyway. They also force the industry toward automation, which makes it much easier to replace certificates quickly when a CA or an algorithm has to be retired.
Does a Multi-Year Certificate Still Make Sense?
Yes, but it means something different now. Commercial CAs and resellers sell multi-year subscriptions: you pay once for, say, two or three years of coverage, and you reissue the certificate within that subscription each time the current one approaches expiry. No new purchase and, for OV/EV, no full re-vetting each time — just a new certificate file.
What a subscription no longer gives you is one file that lasts for years. Whatever you buy, plan for replacing the installed certificate several times a year now, and roughly every month and a half from 2029.
What Actually Breaks
Expired certificates rarely fail quietly. Browsers show a full-page warning that most visitors won't click past, APIs and webhooks reject the connection, and email servers using the certificate can stop accepting mail over TLS. For SEO, an expired certificate means crawlers hit errors too; a lapse of a day or two is usually recovered quickly, but it's lost traffic and conversions you can't get back. Understanding HTTPS and Its Role in SEO covers the wider HTTPS checklist.
The places most likely to be forgotten:
- Load balancers and CDNs where someone uploaded the certificate by hand
- Mail servers (SMTP, IMAP) and VPN appliances
- Staging, internal tools and old marketing microsites nobody owns any more
- Wildcard or multi-domain certificates installed on many servers — renewing one copy doesn't renew the others (see Wildcard vs Multi-Domain SSL Certificates)
How to Get Ahead of It
1. Inventory every certificate
List every hostname that serves HTTPS, which certificate it uses, where that certificate is installed, and who's responsible. Public Certificate Transparency logs (searchable through tools such as crt.sh) show every certificate issued for your domains, which is a good way to find ones you'd forgotten.
2. Automate issuance and installation
The standard protocol for automated certificates is ACME, the one Let's Encrypt made popular. Most hosting control panels, web servers, CDNs and Kubernetes ingress controllers support it, and many commercial CAs now offer ACME too, so you can automate OV and EV certificates as well as free DV ones. Anywhere a certificate is still installed by hand is a future outage; either automate it or put it behind something that is automated (a CDN or load balancer that handles TLS for you).
3. Use DNS validation where you can
Since domain control has to be re-proven more often, validation that relies on an email to admin@ or a file uploaded by hand becomes a bottleneck. DNS-based validation through your DNS provider's API is the easiest to automate.
4. Monitor expiry independently
Automation fails silently — an expired API key, a changed firewall rule, a DNS record someone deleted. Use an external check that alerts you when any certificate is within, say, 14 days of expiry, separate from the system that renews it.
5. Keep OV/EV company details tidy
Re-vetting goes fastest when your legal name, address and listed phone number match public records. Fix any mismatches before your next renewal, not during it.
What This Means If You Use a Free Certificate
If your host already issues and renews free DV certificates automatically, very little changes: renewals simply happen more often in the background. Let's Encrypt has long issued 90-day certificates and has been moving to shorter options of its own. The thing to check is the edge cases — custom domains, a CDN in front of the host, or a mail server — where the automation may not reach.
What This Means If You Buy Commercial Certificates
Commercial certificates still offer things free ones don't: OV and EV identity, warranties, support, and management dashboards across many certificates. The change is in how you use them:
- Prefer a provider and setup that supports ACME or an API, so reissues within your subscription can be installed automatically.
- Treat the subscription term (one, two or more years) as the billing period, not the lifetime of the installed file.
- Keep a renewal owner for every certificate — even automated ones.
Options at each level are available through The SSL Store, from DV certificates such as RapidSSL and Sectigo SSL to OV and EV options like DigiCert Secure Site. If installation is the sticking point, a paid SSL installation service can handle the first setup.
Platform-by-Platform: Where Renewal Usually Lives
The right fix depends on where your certificates are actually served from. The common setups:
Shared hosting and cPanel
Most cPanel hosts run AutoSSL, which issues and renews free DV certificates for every domain on the account. Check under SSL/TLS Status that every domain and subdomain shows as covered. The usual gaps are domains whose DNS points somewhere else (so validation fails) and paid certificates you installed by hand, which AutoSSL won't renew for you.
Managed WordPress hosting
Managed WordPress hosts generally handle certificates entirely. The risk is custom setups: a domain added outside the host's dashboard, or a CDN or firewall in front of the site that has its own certificate.
Your own server (Nginx, Apache)
Use an ACME client — Certbot is the best known, acme.sh and Caddy's built-in support are common alternatives — and confirm two things: that the renewal job actually runs (a systemd timer or cron entry), and that the web server reloads afterwards so it serves the new file. A renewal that succeeds but never reloads the server is a classic silent failure.
CDNs and load balancers
Cloud load balancers and CDNs can usually issue and renew their own certificates. If you uploaded a certificate manually, it will not renew itself; either switch to the platform's managed certificates or automate the upload through its API.
Mail servers, VPNs and appliances
These are the most often forgotten. Many appliances still expect a certificate pasted into a web form. Put them at the top of your inventory, find out whether they support ACME or an API, and if not, give each one a named owner and a calendar reminder until it can be replaced or automated.
Automating Commercial OV and EV Certificates
Automation isn't only for free certificates. Many commercial CAs and resellers now support ACME with External Account Binding (EAB): you get a key ID and secret from your certificate account, give them to your ACME client, and it can request and renew certificates under your paid subscription, including OV, where the organization has already been vetted. The identity vetting still happens on the CA's side at the intervals the rules require; what's automated is issuing and installing the file.
Where ACME isn't available, look for an API or a management dashboard that can push renewed certificates to your servers, and check whether your reseller offers an installation service for the first setup.
Setting Up Expiry Monitoring
Monitoring is the safety net when automation fails. A good setup:
- Checks from outside, connecting to each hostname the way a browser does, rather than reading files on the server
- Covers every hostname, not just the main site — include API, mail and staging hostnames
- Alerts early: 30 days for manual certificates, 14 days for automated ones (an automated certificate within 14 days of expiry means renewal has already failed at least once)
- Alerts a team, not one person's inbox
- Watches CT logs for new certificates issued for your domains, which catches both forgotten systems and certificates you didn't request
Many uptime monitoring services include certificate expiry checks, so you may already be paying for this without having switched it on.
What to Tell Clients and Stakeholders
If you manage sites for clients or run a team, the change needs a short explanation, because "the certificate expired" is the kind of outage people remember:
- Certificates now last months, not years, by industry rule, and will last weeks by 2029. This affects every provider, free or paid.
- Paying for a multi-year certificate still makes sense for OV/EV and support, but the installed file will be replaced several times a year.
- The plan: every certificate is listed, renewed automatically, and monitored independently. Anything that can't be automated has an owner and is scheduled for replacement.
That framing turns a technical change into a simple maintenance commitment rather than a recurring emergency.
A Practical Timeline
- Now (200-day certificates): inventory every certificate, and automate the ones still installed by hand. You have roughly two renewals a year per certificate.
- Before March 2027 (100-day certificates): every production certificate should renew without a person touching it. Three to four renewals a year makes manual renewal a reliable way to get an outage.
- Before March 2029 (47-day certificates, 10-day validation reuse): domain validation should be fully automated (DNS API or HTTP), and monitoring should be in place for every hostname.
Frequently Asked Questions
Do existing certificates stop working early?
No. A certificate issued before a deadline keeps its original validity. The limits apply to certificates issued on or after each date.
Does this apply to private or internal certificates?
The rules apply to publicly trusted certificates. Certificates from your own internal CA aren't covered, although many organisations follow the same direction for their internal ones too.
Will a shorter certificate affect rankings?
No. Search engines only care that the certificate is valid when they crawl. The risk is an expired certificate, which shorter lifetimes make more likely if renewal isn't automated.
Is a 47-day certificate less secure?
No — the encryption is identical. It's arguably more secure, since a leaked key or a mis-issued certificate stops working sooner.
Bottom Line
The certificate you install today won't last a year, and by 2029 it won't last two months. That's manageable with automation and an inventory, and painful without them. Treat 2026 as the year to find every certificate you run and make sure none of them depend on someone remembering a date.
Printed from seo-serps.com — https://seo-serps.com/online-business/ssl-certificate-lifetimes-are-shrinking-the-200-100-and-47-day-schedule/ — updated November 5, 2026.