The Expiry Nobody Plans For
Every certificate has an expiry date, and every expiry date is a deadline nobody remembers until a visitor reports it. The browser warning is blunt — "Your connection is not private" — and most visitors do not click through to check whether the site is actually dangerous. They leave. An expired certificate does not just pause your site; it actively tells every visitor to distrust it.
The uncomfortable part is that this failure is entirely preventable, and it is getting harder to prevent by hand. Certificates used to last for years. Today, a publicly trusted certificate issued after March 15, 2026 can be valid for at most 200 days, and the industry has already voted to cut that to 100 days in March 2027 and 47 days in March 2029. The era of "renew once a year and forget about it" is over. If your expiry process still depends on a human remembering, it will fail — the only question is when.
This guide builds a system that makes expiry a non-event: a monitoring layer that catches problems weeks out, an automation layer that renews before anyone notices, and a fallback layer for the day automation itself breaks. If you just want to know where your own site stands right now, run it through Nomlen's free SSL checker — it reports your certificate's expiry date and the domains it covers in seconds.
Why Certificates Expire Faster Than Ever
The shrinking lifetime is deliberate policy, not an accident. The CA/Browser Forum — the body whose Baseline Requirements govern publicly trusted certificates — adopted ballot SC-081v3 in April 2025, setting a phased reduction in maximum validity. Apple, Google and Mozilla all backed it, and browsers enforce it: a certificate that exceeds the limit simply is not trusted.
The reasoning is straightforward. A compromised private key stays dangerous for as long as its certificate is valid, and revocation works poorly in practice. Browsers do not reliably check revocation, so a short lifetime is the most reliable way to bound the damage.
Certificates issued | Maximum validity | What it means for you |
|---|---|---|
Before March 15, 2026 | 398 days | Annual manual renewal just about worked |
From March 15, 2026 | 200 days | Two renewals a year — manual renewal is now a chore |
From March 15, 2027 | 100 days | Four renewals a year — manual renewal is painful |
From March 15, 2029 | 47 days | Eight renewals a year — manual renewal is impossible |
Let's Encrypt, the free certificate authority behind a huge share of the web's certificates, has always issued 90-day certificates — a preview of where the whole industry is heading. Its clients are designed around automation from the start: Certbot, for example, checks for renewal twice daily once a certificate is within 30 days of expiry. That model — renew early, renew automatically, verify afterwards — is the model every site owner now needs, whatever their certificate authority is.
Step 1: Know Every Certificate You Own
You cannot monitor what you have not inventoried. Most expiry outages happen on a certificate the owner forgot existed: a staging subdomain, a marketing landing page, an old API endpoint, a redirect domain, a mail subdomain. The main site is usually fine. It is the forgotten hostname that goes down.
Build the inventory once, then keep it current:
- List every public hostname — your root domain, www, subdomains, staging and API hosts, and any domain that redirects to your site. Check each one with an SSL checker and record its expiry date.
- Include non-web certificates — mail servers, VPN endpoints and internal tools that browsers or apps will reject when their certificates lapse.
- Record the owner and the renewal method for each — who is responsible, and whether it renews automatically or by hand. A reminder with no named owner is a reminder nobody acts on.
- Note the issuer and the validation type — a paid certificate from a commercial authority and a free Let's Encrypt certificate renew through completely different paths, and you need to know which path each hostname is on.
Do this inventory today, not when something breaks. It takes under an hour for a typical small site, and it is the highest-value step in this guide.
Step 2: Set Up Monitoring That Actually Alerts You
Monitoring is the layer that saves you when automation fails — and automation does fail, for reasons ranging from a changed DNS record to a lapsed payment method. Good monitoring gives you weeks of warning, not minutes.
Set alerts at three thresholds, not one:
- 30 days before expiry — the "something is wrong" alert. If automation is working, a certificate should already have renewed by this point, so an alert here means your renewal path is broken and you have a month to fix it.
- 14 days before expiry — the escalation alert. This one should go to a second person or a second channel, not just the same inbox that ignored the first.
- 7 days before expiry — the emergency alert. At this point you renew by hand, whatever it takes, because the next alert is your visitors seeing a warning.
Two rules make monitoring work in practice. First, alerts must go somewhere a human actually reads — an inbox nobody checks is the same as no monitoring. Second, test the alert path: deliberately let a test certificate approach expiry, or set a threshold you can trigger, and confirm the notification arrives. An untested alert is a guess, not a safety net.
Free options exist for all of this: Nomlen's SSL checker gives you an on-demand expiry verdict for any domain, and most uptime monitors include certificate expiry checks. The tool matters less than the thresholds and the owner.
Step 3: Automate Renewal — Then Verify It
Automation is the only strategy that survives the 47-day future, and it is already the right answer at 200 days. The details depend on your setup:
- Let's Encrypt with Certbot: the standard path. Certbot's scheduled task checks twice daily and renews certificates within 30 days of expiry. Run
certbot renew --dry-runat least monthly to prove the path still works — a dry run that fails is a warning you can act on, while a real failure at expiry is an outage. - Hosting panels and managed hosts: many renew automatically, but "automatically" often depends on the domain still pointing at the host and the payment method still being valid. Confirm both after any DNS or billing change.
- Paid certificates: renewal is usually a purchase plus an install, not a single automated step. Calendar the purchase 30 days early, and remember that buying a certificate is not the same as installing it — the installed certificate is what browsers check.
The most important habit: after every renewal, verify the live site serves the new certificate. Renewal tools can succeed at issuing a certificate and still fail to install it, or install it on the wrong virtual host. Open the site, check the expiry date the browser reports, and confirm it moved. A renewal you never verified is a renewal you are assuming.
Step 4: Plan for the Day Automation Breaks
Every automated system fails eventually, usually at the worst moment — during a migration, after a DNS change, when the person who set it up is on holiday. The fallback plan is short:
- Know the manual renewal steps for your setup and keep them written down where someone other than you can find them. A runbook that lives only in one person's head is not a runbook.
- Keep a second admin contact on the certificate account so a single locked-out mailbox cannot block a renewal.
- Never let a certificate expire while you troubleshoot. If automation fails with days to spare, renew by hand first and debug afterwards. An expired certificate costs you visitors immediately; a manual renewal costs you twenty minutes.
- After any incident, fix the cause, not just the certificate. If a DNS record broke renewal, the record is the bug. If nobody saw the alert, the alert routing is the bug.
The Monitoring Checklist, in One Place
Layer | What to do | How often |
|---|---|---|
Inventory | List every hostname and its expiry date, owner and renewal method | On setup, and after any new subdomain or migration |
Alerts | 30 / 14 / 7 days before expiry, to a monitored inbox and a second channel | Continuous, tested at least once |
Automation | ACME/Certbot or host auto-renewal, with a monthly dry run | Twice-daily checks, monthly verification |
Verification | Confirm the live site serves the new certificate after every renewal | After every renewal |
Fallback | Written manual renewal runbook + second admin contact | Reviewed yearly |
That is the whole system. It is deliberately boring: inventory, alerts, automation, verification, fallback. None of it is clever, and all of it works. The sites that get caught out are almost never the ones with exotic setups — they are the ones where nobody owned the expiry date.
When Expiry Has Already Happened
If you are reading this with a warning already live, the fix is the same in every case: renew and install a new certificate, then check the live site. Do not wait for DNS propagation or a convenient window — a renewed certificate takes effect as soon as the server serves it, and a reload of the web server is usually all the "deployment" it needs. Once the warning is gone, set up the monitoring above before you do anything else, while the memory of the outage is fresh. The second expiry is the one with no excuse.
Related reading: our earlier guide to why your site shows "Not Secure" — and how to fix it in 10 minutes covers the other causes of browser warnings, from mixed content to missing redirects, and how long DNS propagation takes explains the delays that can break automated renewal validation.
Frequently Asked Questions
How long are SSL certificates valid in 2026?
Publicly trusted certificates issued from March 15, 2026 can be valid for at most 200 days under CA/Browser Forum ballot SC-081v3, down from 398 days. Let's Encrypt certificates are valid for 90 days. The maximum drops to 100 days in March 2027 and 47 days in March 2029.
What happens when an SSL certificate expires?
Visitors see a browser warning such as "Your connection is not private" and many will leave rather than proceed. Some browsers block access outright. The site itself is usually still running — it is trust, not availability, that breaks.
Can I renew an SSL certificate without downtime?
Yes, in most setups. Issue and install the new certificate, then reload the web server. There is no need to take the site offline, and visitors on the old certificate are unaffected until the reload.
How early should I renew a certificate?
Thirty days before expiry is the standard window — it is when Let's Encrypt clients begin attempting renewal, and it leaves time to fix a failed validation. Treat an unrenewed certificate at 14 days as an escalation, not a routine item.
Does auto-renewal mean I can stop checking?
No. Auto-renewal fails for ordinary reasons: DNS records change, payment methods lapse, validation paths break. Keep monitoring in place and verify the live certificate after every renewal.
What is the difference between renewing and reissuing a certificate?
Renewal extends coverage with a new certificate, usually with the same details. Reissue replaces a certificate before expiry — typically after a key compromise or a change of domains — and the old certificate should be revoked once the new one is live.
Do I need to monitor certificates on subdomains I barely use?
Yes — those are the ones that expire unnoticed. Staging sites, API hosts and redirect domains all show browser warnings when their certificates lapse, and they often share your brand's name.
What tool checks a certificate's expiry date for free?
Nomlen's free SSL checker reports any domain's certificate expiry date and covered domains instantly, with no signup.
