Your SSL certificate expired. What visitors see and how to stop it happening

A customer rings to say your website “won’t load properly”. You open it yourself and Chrome stops you before the homepage does: a full red screen, “Your connection is not private”, a button marked Advanced hiding the option to carry on anyway. Nothing on the server has changed. The site was fine yesterday. A small file with an expiry date on it has run out.

That file is the SSL certificate, and most site owners never look at it directly. It sits behind the padlock in the address bar, proving to the browser that the site belongs to who it says it does, and it is supposed to renew itself without anyone noticing. When that renewal fails, the warning is not subtle, and it lands on every visitor at once.

What the warning says, and does

The wording depends on the browser, but the effect is the same everywhere. Chrome shows “Your connection is not private” in red, with the technical reason underneath: NET::ERR_CERT_DATE_INVALID. Safari says “This Connection Is Not Private” and calls the certificate expired outright. Firefox goes further and refuses a one-click way past it on some setups, asking the visitor to add a manual exception first.

None of them show your homepage. Every one of them puts the warning first, full screen, before a visitor has seen a word of your content.

A determined visitor can click through on desktop, usually via “Advanced” and then “Proceed anyway”. Most will not. They arrived to book an appointment or check your opening hours, not to read a security warning and decide whether to trust you regardless, and a fair few will decide your competitor’s site is worth trying instead. Google penalises it too: search rankings account for HTTPS working properly, so a certificate that lapses can cost you traffic on top of the visitors who bounce off the warning itself.

None of this needs a certificate to be forged or your data at risk. An expired certificate triggers the same warning as a dangerous one, because to the browser, a certificate it cannot currently verify as valid looks the same either way.

Why renewal fails when it is meant to be automatic

The old model, buying a certificate once a year and installing it by hand, mostly went away with Let’s Encrypt, which issues free certificates that last 90 days and renew automatically about a month before they run out. Automatic renewal is why most site owners have never thought about this: for years, it works without a prompt, right up until the one time it does not.

Three things break it, and all three fail silently. Nobody gets an error message. The old certificate keeps working right up to its expiry date, so the gap between the renewal failing and a visitor seeing the warning can be weeks.

The DNS moved. Some renewal methods prove you own the domain by checking a DNS record. If you switched providers, a domain registrar to a new host, one DNS service to another, and the renewal script still points at the old one, it cannot complete the check. The certificate quietly stops renewing from that point on, and nothing about the site looks wrong until the 90 days run out.

The renewal hook is broken. A new certificate is only half the job. The web server then has to reload to start using it, and that reload step is usually a separate script, a “hook”, that runs after renewal finishes. If that hook fails, silently or otherwise, the new certificate can sit on disk while the server carries on serving the old, expiring one. The renewal log shows success. The visitor still gets the warning.

A CAA record blocks the issuer. A CAA record in your DNS says which certificate authorities are allowed to issue for your domain. It is a sensible security control on its own, stopping somebody else from getting a certificate for your site from a different provider, but a typo in it, or one added for a service you no longer use, quietly refuses the renewal from the very authority you rely on. The failure looks identical to the other two from the outside: the site works today, the certificate expires on schedule, and nobody was told anything had changed.

All three share the same shape. Something moved, or something was locked down for good reasons, and neither the CMS nor most hosting dashboards will tell you a renewal has stopped happening.

How to hear about it before the customer does

The fix is not checking manually. Nobody remembers to look at a certificate’s expiry date on a Tuesday in November, and by the time you do think to check, you are already troubleshooting a live warning.

The fix is a monitor that checks for you and emails you when the picture changes:

• An uptime monitor with SSL checking. Most uptime services, the kind that already ping your site every few minutes to confirm it loads, offer certificate expiry checking as part of the same check. Turn it on and set the alert for 14 to 21 days before expiry, which gives you time to fix a broken renewal hook or a stale DNS record without a customer ever seeing a warning.
• A calendar reminder as a backup, not a substitute. Worth having alongside a proper monitor, not instead of one. A reminder only helps if somebody reads it, and the person who set it up eighteen months ago may not be the person checking email today.
• Know who is meant to be watching. If your host manages certificates as part of the package, confirm that in writing rather than assuming it. If a plugin or a past developer set up automatic renewal and has since moved on, that renewal has no owner, which is exactly the situation that produces a silent failure nobody catches.

None of this needs deep technical knowledge. It needs one thing switched on and one person who knows it is their job to act on the alert when it arrives.

The short version

A certificate that renews itself for two years straight teaches you it does not need watching, right up until a DNS change, a broken hook or a CAA record proves otherwise, and the first sign is a red warning on your own homepage. Put a monitor on the expiry date, give the alert a named owner, and this becomes a five-minute fix instead of a Sunday morning one.

It is one of the things we check as standard for anyone on our Care & Hosting plan, alongside backups, updates and uptime monitoring, for £49 a month. If you want a quick, free look at whether your own certificate and the rest of your site’s basics are in order, our free website review covers it.