Why Does an SSL Certificate Expire Without Warning?

In short

An SSL certificate expires silently because renewal is usually automated, and automation fails quietly — a plugin gets disabled, a cron job stops running, or the renewal notice goes to an inbox nobody reads. The certificate then lapses with no warning until a visitor's browser blocks the page outright. SiteHealth checks your certificate's expiry date every hour on paid plans and tells you in plain English when the countdown gets low, so you catch it before a customer does.

Why does an SSL certificate expire without warning?

It expires without warning because the "warning" step depends on a machine job that nobody is watching. Most hosts renew certificates automatically through Let's Encrypt, whose own documentation explains why certificates are issued for just 90 days — short enough that a broken renewal gets caught fast, but only if something is actually watching for the break. When the job silently fails, nothing alerts a person, because the renewal is a machine talking to a machine.

Common ways that machine-to-machine job breaks without anyone noticing:

• An expired API key or credential at the certificate authority
• A DNS record changed for an unrelated reason that the renewal check depends on
• A plugin or auto-renew cron job disabled during a routine server update
• A rate limit hit after too many failed retries in a short window

If your certificate instead came from a paid certificate authority rather than a free automated one, the story is different but the outcome is the same. The renewal reminder goes to whatever email address was on file when someone bought the certificate two or three years ago — often a developer who has left, an agency that was fired, or a placeholder inbox nobody checks anymore.

What actually breaks when a certificate expires?

The browser stops your visitors before they ever see your page. Chrome, Firefox, and Safari all show a full-page warning, something like "Your connection is not private," the moment a certificate's expiry date passes, and most visitors close the tab rather than click through it. Any checkout, login, or contact form on that page usually fails outright too, because the browser blocks the underlying request until the certificate is valid again.

This is different from a slow page or a typo in the copy. There is no gray zone: the certificate is either valid or the page is blocked, and it happens at midnight or at noon with equal indifference to your business hours.

The damage compounds the longer it sits. A visitor who hits the warning once may try again later and forgive it. A visitor who hits it twice usually assumes the business itself is gone, not just the certificate, and looks for a competitor instead. Search engines that re-crawl a page during the outage can also drop it from their index temporarily, which means the cost is not just the visitors who saw the warning directly but the ones who never saw the page at all that week.

How do you find out who actually gets the renewal notice?

Ask whoever manages your hosting, then verify the answer yourself instead of trusting it at face value.

1. Log in to wherever the certificate was issued — your host's control panel, Certbot, or the paid certificate authority's portal — and check the "on-file" contact email.
2. Confirm that inbox is still monitored, not a former employee's account or an agency you no longer use.
3. Check the certificate's actual expiry date directly, by clicking the browser's padlock icon, not the renewal schedule someone told you about secondhand.
4. Write the expiry date down somewhere outside the renewal system itself, because if the system is broken, its own reminders are broken too.

That last step is the one people skip, and it is the one that matters most. A reminder that lives outside the automation is the only warning that survives the automation failing.

Does the certificate expire the same way on www and the bare domain?

Not always, and this is where a "renewed" certificate can still show a warning to some visitors. A certificate can be issued for example.com, for www.example.com, or for both as a single certificate covering multiple names. If a renewal job only re-issues one variant — often because a redirect was added later and the automation was never updated to match — visitors who land on the other version see the expired-certificate warning while the "main" address looks completely fine.

The reliable check is to open both https://example.com and https://www.example.com directly, not through a redirect, and read the padlock on each address separately.

Isn't my host already handling this for me?

Most hosts renew automatically, most of the time, and that is exactly why this catches people off guard. "Usually working" and "monitored" are not the same thing. A host's automation can fail for a reason that has nothing to do with your site — a rate limit at the certificate authority, a DNS change made for an unrelated reason, a plugin update that broke the renewal hook — and the host has no obligation to notice on your behalf. Checking the actual expiry date yourself, on a fixed schedule, is the only way to close that gap without assigning someone to watch it by hand.

SiteHealth's certificate check runs on its own schedule and reports the number of days left in plain language, independent of whatever your host's automation is or is not doing. Agencies managing several client sites can see the same picture across all of them; see how that works on /for-agencies. The full list of checks, including the security certificate and domain renewal check, is on /features.

What about the domain name itself, not just the certificate?

A domain and its certificate expire on separate clocks, and losing the domain is worse. Registrars typically send renewal notices to the email address on the registration record, which drifts out of date the same way a certificate contact does — an old employee, a closed company inbox, a spam filter that quietly ate it. Under ICANN's Expired Domain Deletion Policy, registrars must send multiple notices before a domain lapses and hold it in a grace period afterward, but a notice sitting in an unread inbox has done nothing. Once that grace period ends, getting the domain back can mean a redemption fee, or in the worst case the domain becomes available for anyone else to register.

If you are about to point a brand-new domain at a site for the first time, read through what else to verify before you do in our domain checklist for AI-built sites — most of it applies to any new domain, not only AI-built ones.

Treat the domain's expiry date as a separate fact to check, on the same schedule as the certificate, not as something covered "because the certificate looked fine." Registrars usually offer auto-renew as a setting, not a default, and it silently does nothing if the payment card on file has expired since you turned it on — which means "I already turned on auto-renew" is not the same guarantee it sounds like either.

What should you check today?

Open your site in a private or incognito browser window and click the padlock to read the certificate's actual expiry date, then check your registrar account for the domain's renewal date directly. If either one is inside 30 days and you are not certain the renewal is automated and actually working, fix the contact email now, before you need it. For an ongoing answer instead of a one-time check, start a free SiteHealth check — it reads both dates for you and tells you in plain English exactly how many days are left.