SSL Certificate Monitoring: How to Stop Certificates Expiring Unnoticed

An expired SSL certificate is one of the most frustrating outages there is. The server is up, the application is healthy, and yet every visitor gets a full-page security warning instead of your website. Your shop, your customer portal and your API are, for all practical purposes, offline. And the expiry date was written into the certificate from day one. With proper SSL certificate monitoring, you see the problem coming weeks in advance.

This article explains why certificates still expire even when renewal is automated, how to check the expiry date yourself, why shorter certificate lifetimes make the topic more pressing, and what reliable monitoring needs to cover.

What happens when an SSL certificate expires

Strictly speaking, these are TLS certificates. The original SSL protocol was retired many years ago, but "SSL certificate" is still the term most people use, so we'll stick with it here.

Once a certificate has expired, browsers refuse to open a normal connection. Chrome shows NET::ERR_CERT_DATE_INVALID, Firefox shows SEC_ERROR_EXPIRED_CERTIFICATE. Visitors can often click past the warning, but very few will do that on a checkout page or a login form, and rightly so. If your domain uses HSTS, browsers don't even offer the option.

Machines are hit even harder. API clients, webhooks, mobile apps, payment and shipping providers: most HTTP libraries abort the connection the moment they see an invalid certificate. An integration that worked yesterday fails today, and the error ends up in a log nobody reads.

Why certificates expire despite automation

Since Let's Encrypt, automatic renewal has become the default. Certbot, Caddy, Traefik, Laravel Forge and most hosting control panels renew certificates on their own. Certificates still expire, because there are plenty of places where automation fails quietly:

• Domain validation fails. With the HTTP-01 challenge, the certificate authority has to fetch a file from /.well-known/acme-challenge/. A new firewall rule, geo-blocking, a proxy in front of the site, or a maintenance mode that answers every request with an error page can all get in the way. With DNS-01, an expired API token at your DNS provider is enough.
• The domain points somewhere else. After a server move, the old server keeps trying to renew its certificate while the domain already points to the new one, and nobody set up renewal on the new server.
• The renewal job doesn't run. Certbot's systemd timer or cron job is missing after a reinstall, a container is rebuilt without the renewal process, or a deployment overwrites the crontab.
• The new certificate is never served. Web servers such as Nginx and Apache read certificates when they start or reload their configuration. If the certificate on disk is renewed but the server isn't reloaded, it keeps serving the old one until it expires. The same applies to load balancers and CDNs where a certificate was uploaded by hand.
• A CAA record blocks issuance. If a CAA record in DNS only allows one specific certificate authority, every attempt by another one fails. This often happens when a client or a previous agency set the record years ago.
• Manually purchased certificates. When a certificate is bought and installed once a year, everything depends on one person and one calendar reminder. When that person leaves, so does the knowledge.
• Reminder emails no longer arrive. Let's Encrypt stopped sending expiration notification emails on 4 June 2025. If those emails were your safety net, it's gone. For purchased certificates, reminders often go to an address nobody checks any more.

What all of these have in common is that everything looks fine on the server right up to the moment the certificate expires.

Shorter lifetimes make monitoring more important

In April 2025, the CA/Browser Forum, where certificate authorities and browser vendors set the rules for publicly trusted TLS certificates, adopted Ballot SC-081, a schedule for much shorter certificate lifetimes. Until March 2026, certificates could be valid for up to 398 days. The schedule looks like this:

At the same time, the period for which a domain validation can be reused drops to 10 days by 2029. In practice, a yearly manual certificate swap is already impossible, and twice a year won't be enough for long either. Automation is no longer optional. And every extra renewal is one more chance for something to go wrong. The more often certificates are renewed, the more you need an independent check that the result actually reaches your visitors.

How to check a certificate's expiry date

In the browser, the icon to the left of the address bar lets you open the certificate details, including the issuer and validity period. For several domains, or for scripts, the command line is more practical:

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

The output looks roughly like this:

subject=CN=example.com
issuer=C=US, O=Let's Encrypt, CN=R11
notAfter=Dec  3 14:34:31 2026 GMT

Don't leave out -servername. It sets the Server Name Indication (SNI). Without it, a server that hosts several sites may return its default certificate, and you end up checking the wrong one.

For scripts, use -checkend. It takes a number of seconds and exits with code 1 if the certificate expires within that time. 1209600 seconds is 14 days:

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

openssl x509 -noout -ext subjectAltName shows which hostnames the certificate covers. That's useful when www or a subdomain suddenly goes missing after a change.

If you use Certbot, three commands on the server tell you most of what you need:

sudo certbot certificates         # all certificates and their expiry dates
sudo certbot renew --dry-run      # test renewal without issuing real certificates
systemctl list-timers | grep certbot

To make sure the web server actually picks up a renewed certificate, add a deploy hook, for example an executable script in /etc/letsencrypt/renewal-hooks/deploy/ that runs systemctl reload nginx. Certbot only runs deploy hooks after a successful renewal.

What a look at the server can't replace is a check from the outside. What matters is the certificate your visitors receive, not the file sitting on disk.

What good SSL certificate monitoring covers

A one-off check helps today, not three months from now. In our view, reliable monitoring meets these requirements:

• It checks the served certificate from the outside. That way you also catch a certificate that was renewed but never loaded.
• It warns early and in stages. A first warning several weeks ahead gives you time to deal with validation problems or wait for a client's sign-off. Further warnings close to the expiry date make sure it doesn't get lost. Many ACME clients renew Let's Encrypt certificates around 30 days before they expire, so if you get a 14-day warning for one of them, automatic renewal has clearly failed more than once.
• It catches invalid certificates, too. A hostname mismatch, a self-signed certificate or a missing intermediate chain cause errors as well. The missing chain is the sneaky one: some browsers work around it, but many API clients and curl don't.
• It reaches the right person. A warning that disappears into a shared inbox isn't a warning. Send it to wherever the responsible team already works, without constant repeats that eventually get ignored.
• It covers every hostname. Besides the main domain, think of www, the API, the customer portal, staging environments and old landing pages. Each hostname can have its own certificate.

A checklist for agencies and small teams

If you look after many client websites, you quickly end up with dozens of certificates. These habits have proven themselves:

1. Keep a list of every hostname per client, subdomains included. Only what's on the list gets monitored.
2. Agree on responsibilities. If the client manages DNS, a change on their side can break renewal without you knowing. Write down who is allowed to change records in an emergency.
3. Test after every server move with certbot renew --dry-run, or your ACME client's equivalent, to confirm that renewal works on the new server.
4. Make sure the new certificate is loaded. Check that the web server, load balancer or proxy picks up the certificate after renewal.
5. Monitor the renewal job itself. If renewal runs from your own cron job, you can protect it with a heartbeat. Our guide on how to monitor cron jobs with heartbeats shows how.
6. Don't forget other services. Mail servers use certificates too, for example for IMAP on port 993. Check them with openssl s_client -connect mail.example.com:993, and for SMTP with STARTTLS add -starttls smtp.

How Kaspar helps

In Kaspar, you can turn on SSL expiry warnings for any uptime monitor with an HTTPS address. Once a day, we read the certificate your server actually serves and warn you 30, 14, 7 and 1 day before it expires, by email, Slack or Telegram. Each stage is sent exactly once, and as soon as the certificate has been renewed, Kaspar closes the open warning automatically.

Separately, the uptime monitor checks your site at your plan's interval. If the certificate has expired or is invalid, the check fails with a TLS/SSL error. As with any other failure, we re-check within seconds before we alert you. SSL expiry checks are included in both plans, and heartbeats for your renewal jobs are part of the Pro plan. You'll find every feature on our home page and the plans on the pricing page.

Conclusion

Expired certificates aren't bad luck; they're a planning problem. Automate renewal, make sure the web server loads the new certificate, and monitor the served certificate from the outside. With certificate lifetimes getting shorter over the next few years, that outside check goes from nice to have to essential. If you'd also like to keep an eye on your site's availability and find broken links before they hurt your SEO, Kaspar covers it all in one account.