SSL Certificate Expiration Monitoring for Client Sites

An expired SSL certificate turns a healthy site into a browser warning screen. For a client, that is indistinguishable from an outage. The practical fix is not another calendar reminder: it is a repeatable way to see certificate expiry before a visitor does.

What SSL certificate expiration monitoring should catch

At minimum, a useful monitor should check the certificate a visitor actually receives for each client domain and alert you before its notAfter date. That catches more than a forgotten renewal:

• a failed ACME or hosting-panel renewal;
• a DNS or CAA change that prevents a new certificate from being issued;
• a new certificate on the origin while a CDN or load balancer still serves the old one;
• a site moved to a new host without its renewal process; and
• the wrong certificate presented for a subdomain.

Checking the live certificate matters. A certificate file can be valid on a server while the public site still serves an expired one from another layer.

Start with a baseline for every client site

If you do not yet know which certificates are close to expiry, run a one-time check first. SitesRadar’s free website checker checks the live SSL certificate alongside reachability, broken links, and DNS records without requiring a signup. Use that snapshot to find the sites that need attention now.

For a manual verification, this command shows the certificate currently served to visitors:

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

Replace example.com with the client domain. If the notAfter date is close, investigate before the browser starts blocking visitors.

Set alert thresholds that leave time to act

SSL renewals fail at inconvenient times: after a migration, a DNS change, or a hosting move. An alert the day before expiry is an outage notification, not monitoring.

A practical starting policy is:

Time remaining	What to do
30 days	Confirm which system renews the certificate and who owns it.
14 days	Verify the renewal path and the certificate served publicly.
7 days	Treat it as an active client task; fix the cause or renew manually.
Expired	Restore a valid certificate, then document why the warning was missed.

The exact dates matter less than having an owner and a visible queue. If you manage several sites, keep the same policy for every client instead of relying on a mixture of registrar emails, hosting notices, and memory.

What to do when an alert fires

Work from the outside in:

1. Confirm the public certificate with openssl or a browser certificate viewer.
2. Check the renewal system: certbot timer, hosting panel, CDN, or managed platform.
3. Verify DNS and CAA records still allow the expected certificate authority to validate the domain.
4. If a renewal succeeded, reload the web server or check the CDN/load balancer certificate separately.
5. Run another live check and record the new expiry date before closing the task.

For the detailed recovery steps and common renewal failures, read why SSL certificates expire without warning. If the report is really that the site is unavailable, use the client-site downtime triage checklist to rule out DNS, hosting, and CDN problems in order.

Turn the snapshot into a monitoring habit

A one-time SSL check is useful after a migration or before handing a site back to a client. It cannot catch the DNS change, deploy, or hosting move that happens next month. The goal of SSL certificate expiration monitoring is simple: know that a certificate is about to fail while there is still time to fix it calmly.

If you are responsible for multiple client sites, use a scheduled monitor that keeps the expiry date visible and alerts you before it becomes a customer-facing warning. That is how certificate monitoring becomes a service you can reliably provide rather than an emergency you repeatedly explain.