The Certificate That Renewed but Did Not Install

Two separate steps

A certificate renewal has two halves that people treat as one.

Issuance: the authority produces a new certificate with new dates.

Installation: the server is configured to serve that new certificate, and the relevant service is reloaded so it takes effect.

Automated systems normally do both. When only the first succeeds, every record you can see says renewed while every visitor sees a warning.

That combination is what makes this failure last longer than it should, because the place you would look to check says everything is fine.

Why the second half fails

• The reload did not happen after the new file was written.
• The renewal wrote to a path the server no longer reads.
• A migration changed the configuration.
• A service in front of the site holds its own copy.
• Multiple domains where only one was updated.
• A manual certificate that nobody renewed at all.

The fourth is increasingly common: a security or caching service sitting in front of the site presents its own certificate, so renewing at the origin changes nothing visitors experience.

Check the live site, not the record

The correction that resolves this, and it is a change of habit rather than a tool.

Open your site in a browser, click the padlock, and view the certificate details. The expiry date shown is what visitors are actually being served.

That takes ten seconds and is the only check that answers the question.

A dashboard reporting a successful renewal is reporting on issuance, which is a different fact.

Online checkers do the same thing from outside and additionally report the full chain, which matters for the case below.

Do this after every renewal cycle, and after any migration, since those are when the two halves separate.

A worked example

A business had automated certificate renewal and had never had a problem with it.

After moving to a new host the automation continued running and reporting success, and the renewal record showed a valid certificate with a future expiry.

Some months later customers began reporting a security warning.

The renewal had been writing the new certificate to the location used by the previous host's configuration, and the new server was reading from elsewhere and still serving the original certificate, which had by then expired.

Both facts were true simultaneously: renewal succeeded, and the site served an expired certificate.

The fix was a configuration correction taking minutes. Finding it took a week, because everybody kept checking the renewal record.

They added a monthly padlock check afterwards, which is what they should have had all along.

The incomplete chain

A related failure that produces inconsistent symptoms and is worth recognising.

A certificate is presented along with intermediate certificates that connect it to a trusted root, and if those are missing the certificate itself is still valid.

Some browsers fetch the missing pieces automatically and show no problem. Others, and many phones and applications, do not, and show a warning.

Which produces the characteristic report that it works for you and not for a customer, and a suspicion that the customer is doing something wrong.

An external checker reports the chain explicitly, and this is the specific case where checking from outside beats looking at your own browser.

Monitor the served certificate

The arrangement that catches this without anybody remembering.

Most monitoring tools can check certificate expiry as a separate item and alert some days before, and many small businesses have monitoring configured only for whether the page loads.

That distinction matters here, because a site serving an expired certificate is still loading. It responds, it returns the page, and an uptime check reports it as healthy while every visitor sees a warning first.

Add a certificate check, set the warning to at least a week before expiry, and send it somewhere a person will read.

Where you have several domains or subdomains, monitor each, since a renewal covering one does not necessarily cover the others.

Do not let it lapse over a weekend

A practical scheduling note, since certificate periods have become short and renewals frequent.

Automated renewal typically attempts well before expiry and retries, which gives room for a transient failure to resolve itself.

What it does not give room for is a failure nobody sees on a Friday, where the window closes over a weekend.

The week-ahead warning is what covers that, and it is the reason to set the alert generously rather than at the last day.

Where a certificate is manual rather than automated, put its expiry in the register with a reminder a fortnight ahead.

What the warning costs

Worth sizing, because it explains why this deserves a monitor of its own.

A browser showing a certificate warning does not display your page. It displays a full-screen interstitial saying the connection is not private, with the site behind a button most people will not press.

Which means the site is effectively unreachable for the cautious majority, while every uptime tool reports it as available.

For anybody arriving from a search result or an advertisement, that is the entire impression, and a proportion will conclude the business is not trustworthy rather than that a certificate lapsed.

It is one of the few faults where the technical severity is low and the commercial severity is high, which is the argument for the week-ahead alert.

The counter-case

On fully managed platforms this is largely somebody else's problem.

Where the host issues, installs, and renews certificates as part of the service, the failure modes above are theirs to prevent, and building elaborate monitoring around it duplicates what you are paying for.

The padlock check still costs ten seconds and is worth keeping as a habit, since managed does not mean infallible.

There is also little value in investigating the technical detail yourself. This is a category to detect and report rather than to fix.

Check what is served, tell whoever runs it, and let them correct the configuration.

The check

1. Click the padlock and read the expiry date.
2. Trust that, not the renewal record.
3. Use an external checker to verify the chain.
4. Check after every migration.
5. Monitor certificate expiry separately from uptime.
6. Warn at least a week ahead.
7. Check every domain and subdomain you serve.

Step five is the gap most monitoring has, since a site with an expired certificate still loads and is reported as healthy.

Setting monitoring up properly is covered in uptime monitoring that tells you first.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.