SSL certificate expiry monitoring (and why it bites you)
Uptime & monitoring

SSL certificate expiry monitoring (and why it bites you)

2026-09-02 5 min read

Expired certificates mean red warnings and lost customers. Why auto-renewal fails, how to check with openssl, and how to monitor expiry.

Few things are as needlessly painful as an expired SSL certificate. One morning visitors are met by a big red warning in the browser, search engines lose trust and conversions collapse, all because of a date that passed. The worst part is that it's almost always preventable. Here we cover why certificates expire despite auto-renewal, and how to check and monitor them.

Why certificates expire even though they "auto-renew"

Almost everyone assumes auto-renewal means never having to think about it again. The reality is that the automation fails more often than people think, and silently. Common causes:

  • The renewal job stopped running. A cron job or system service handling renewal can stop working after a server move or an update, without anyone noticing.
  • Validation fails. Let's Encrypt must prove you own the domain. If a DNS record changes, a redirect is added or the validation directory is blocked, renewal fails.
  • The certificate renewed but was never reloaded. A new certificate was created correctly but the web server was never restarted, so the old expired one is still in use.
  • Manual certificates. Purchased certificates valid for one or two years have no automation at all, and the reminder email ends up in the spam folder.

Why an expired certificate costs so much

The consequence of an expired certificate is rarely just a warning. Modern browsers show a full-screen page that most visitors don't know how to get past, and many won't dare to. And if you've enabled HSTS, a security setting that forces HTTPS, it's not even possible to click past the warning. Search engines treat an insecure connection as a quality signal and can lose trust in the site. For an online store it means sales effectively stop entirely, often in the middle of the night when nobody notices until the morning reports come in.

Chain and issuer changes that break trust

A certificate can be valid and still cause errors. The browser trusts a certificate through a chain up to a trusted root. If the intermediate certificate is missing from the server's configuration, or the issuer changes its intermediate or root certificate, some clients can suddenly stop trusting the site. It often only shows up in certain browsers or on older devices, which makes it sneaky to troubleshoot. An issuer change, for example when you migrate between providers, is exactly the moment to be extra vigilant.

How to check a certificate manually

The fastest way in the browser is to click the padlock in the address bar and look at the certificate's validity period and issuer. But for a real check, the command line is superior. With OpenSSL you can see the expiry date, the full chain and the issuer:

  • Run openssl s_client -connect example.com:443 -servername example.com to see what the server actually sends, including the chain.
  • Append | openssl x509 -noout -dates -issuer to quickly read out the validity dates and issuer.

Check that the notAfter date is far enough ahead, that the issuer is the one you expect, and that the full chain is sent, not just the server's own certificate.

Don't forget subdomains and separate services

Another common trap is watching only the main domain. But www, shop, an API on a subdomain and your mail server can all have their own certificates with different expiry dates. A wildcard certificate covers many subdomains but still has a single expiry date that must be renewed. Make a list of every hostname that uses HTTPS and check each one. It only takes one forgotten API certificate expiring for your app to stop working while the website itself looks perfectly healthy.

Why manual checks aren't enough

The problem with manual checks is that they rely on someone remembering. Certificates expire in the middle of a holiday, in the middle of the night, or precisely the week you're busy with something else. What you need is a silent guard that warns you in good time, not a warning from a visitor after it's already too late. A good rule of thumb is to be warned at least two to three weeks before expiry, so you have time to troubleshoot a stubborn auto-renewal before it becomes urgent.

How Ravnsight helps

Ravnsight's SSL monitoring checks your certificates continuously and warns you a set number of days before they expire, so you have time to act before visitors see a warning. We also watch the chain itself and alert you if the issuer changes, which is often an early sign that something went wrong in a renewal or migration. That way an expiring certificate becomes a reminder you receive calmly, not an emergency in front of a red warning screen.

Tags:

Share:

Related Articles