Expired SSL certificate: what your visitors see

An expired certificate does not produce a discreet warning. It produces a full-page interstitial, usually red, saying your connection is not private and that attackers may be trying to steal information. Most visitors do not click through it. Many conclude the site has been hacked.

Meanwhile your server is perfectly fine. It is serving pages exactly as it did yesterday, it answers in milliseconds, and none of your logs report anything at all.

The exact message tells you which of the four problems you have

Before touching anything, read the error code shown under the message. Browsers hide it behind an "advanced" link, and it carries all of the information.

The first two rows are fixed with one command. The third is the sneakiest and deserves its own section. The fourth is not a certificate problem at all.

Why it happens to sites that work

The reminder went to an address nobody reads. Certificate authorities warn you by email, at whatever address was entered when the certificate was issued: often a generic mailbox, sometimes a developer who left two years ago.

Automatic renewal failed silently. The renewal is scheduled and it errors out. Nothing fails loudly; the certificate simply stops being replaced. This is the most common cause on modern servers, and it has three classic variants.

The certificate was renewed but not deployed. A new file exists on disk, dated today, perfectly valid. The web server is still holding the old one in memory, because nobody reloaded it. Genuinely maddening, and very common.

A subdomain was forgotten. The certificate covers example.com and www, but not the shop. you added in March. The main site is fine, and a slice of your traffic hits a wall.

What a visitor does in front of that page

They do not read the error code. They see a crossed-out padlock, a red background, and a sentence about stolen information. Three reactions cover almost all of it: close the tab, go back to the search results and click the next one, or write to someone to report that your site has been hacked. The third one is the only one you ever hear about, which is why this failure always feels rarer than it is: the two silent reactions leave no trace anywhere.

None of those three can be repaired afterwards. That is what separates this failure from an ordinary server error: a page returning a 500 or a 503 worries a visitor, a page announcing an attempted theft makes them leave and leaves them with a memory.

Be wary of the figures circulating about how many people click through: they come from old samples and from contexts that are not yours. What is certain is that the button to continue is deliberately hidden behind two clicks, and that the whole design of that page exists so nobody crosses it.

The half-day that costs the most

The block appears at the exact moment the certificate expires, often at night, often on a weekend, because that is when the ninety days happened to end. By the time someone notices on Monday morning, the site has been showing a security warning to every visitor for thirty-six hours.

Nobody will call you during that time: your internal tools see nothing, and neither does your host, since from their point of view the machine is answering perfectly. This is the failure that looks most like an outage without being one, which is why it belongs in the same reflex as the first fifteen minutes of any incident: look from the outside before looking at the code.

Checking in thirty seconds

One command gives you the expiry date of the certificate actually presented to the public, which is not always the one sitting on your disk:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject

notAfter gives the deadline, subject and the alternative names tell you which hosts are covered. Repeat it for every subdomain you serve: each one is a separate question.

If you do not have a terminal handy, or you just want the number: our certificate reader does the same thing from the browser, and gives you the date, the hosts covered and the state of the chain.

The incomplete chain case

This is the trap that wastes the most time, because it does not show up on the machine of the person checking.

A certificate does not stand alone: it is signed by an intermediate, itself signed by a root. Your server must serve the certificate and the intermediate. If it omits the second, desktop browsers often cope, because they cached that intermediate during an earlier visit to some other site. Mobile devices refuse.

The result: the site works perfectly on your machine and shows a warning to a share of your visitors. The test is done from a phone on mobile data, or with the command above from a machine that has never visited the site.

What short lifetimes changed

Ten years ago a certificate lasted a year or more, and a reminder in a shared calendar did the job. Today's free certificates last ninety days, and the general trend is towards shorter lifetimes still, for good security reasons.

That shifts the problem entirely. An annual renewal is an event somebody remembers; a quarterly renewal is an automatic routine nobody watches. The question is no longer "who remembers to renew" but "who verifies that the automation still works".

It is a reversal worth stating, because it makes two old habits useless. Writing the expiry date in a calendar no longer helps: it changes four times a year. Trusting the renewal log no longer helps either: the three classic failures leave a trace nobody opens, and the third one does not even leave an error.

One check keeps its meaning, and it is the one that looks from the outside.

What actually prevents it

Watch the expiry date, not the renewal job. A monitor that reads the certificate presented by your server and counts the days remaining tells you the truth: it sees the certificate a visitor would get, not the one on disk. All three causes above end in the same place, and this single measurement catches all three.

Alert with real margin. Thirty days, then seven, then one. Thirty days is enough to fix a broken renewal calmly; one day is enough to catch a deployment that silently did not reload.

Check every hostname you serve. Each subdomain is a separate certificate question, and the forgotten one is always the one that was added later. A wildcard certificate solves that for one level of subdomain and for one level only, which is a detail that surprises people at the worst possible moment.

Put a human address on the certificate. It costs nothing and it is the last line of defence when everything else has been forgotten.

What it is not

It is not a hack, and saying so plainly to whoever reported it saves an hour of pointless panic. It is not a server outage: nothing to restart, nothing to restore. And it is not primarily a ranking problem.

What HTTPS actually changes for search engines is more modest than the urgency of this page suggests. The reason to fix a certificate is the visitor seeing red, not the algorithm.