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.

This guide covers what a monitor has to check, the thresholds that leave time to act, the four ways people usually try to track expiry and why three of them fail, and a process you can run across a whole client roster.

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;
• an expired intermediate certificate in the served chain, even when the leaf looks fine; 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. The monitor must connect to the public hostname with SNI, the way a browser does, and read what comes back.

Chain and name coverage, not just the date

Two failures produce browser warnings with a certificate whose date is fine:

• Broken chain. The server sends the leaf but not the intermediate, or sends an intermediate that has itself expired. Desktop browsers often repair this silently from their cache; mobile browsers and scripts do not. A monitor that only reads notAfter from the leaf misses it. See curl (60) SSL certificate problem: certificate has expired for how that looks from the client side.
• Name mismatch. The certificate covers example.com but the client also uses shop.example.com, or a wildcard was replaced by a certificate listing specific names and one was forgotten. Every hostname a visitor might type needs a check of its own.

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. If you only care about the certificate, the SSL certificate checker leads with validity, chain, and days-to-expiry.

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 -issuer

Replace example.com with the client domain. If the notAfter date is close, investigate before the browser starts blocking visitors. The issuer line tells you which renewal system you will be dealing with: Let’s Encrypt means certbot or a panel’s auto-SSL, Cloudflare means the edge certificate, a commercial CA usually means someone installed it by hand and will have to do so again.

To turn that into a days-remaining number you can put in a spreadsheet:

for d in example.com shop.example.com client-two.com; do
  end=$(echo | openssl s_client -connect "$d:443" -servername "$d" 2>/dev/null \
        | openssl x509 -noout -enddate | cut -d= -f2)
  printf '%-28s %s\n' "$d" "$end"
done

Run it once, record the results, and you have an inventory. Run it by hand every week and you have a monitoring system that works until the week you forget.

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.

One adjustment for Let’s Encrypt: certbot attempts renewal when 30 days remain, so a 30-day alert on a Let’s Encrypt site fires at the same moment renewal is supposed to start. That is fine as a heads-up. The alert that matters is the 14-day one: if a Let’s Encrypt certificate still shows fewer than 14 days, at least a dozen automatic renewal attempts have already failed, and nobody has read the log that says why.

Shorter certificate lifetimes change the arithmetic

Certificate lifetimes are shrinking by industry agreement. Publicly trusted certificates are capped at 398 days today, drop to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. Let’s Encrypt certificates already last 90 days and shorter options are coming. Two consequences:

• A missed renewal becomes an outage in weeks, not a year from now, so the “we’ll get to it” window disappears.
• Manual renewal stops being viable at any scale. Every site needs a working automatic renewal path, and monitoring exists to tell you when that path has broken.

Thresholds expressed in days still work for short-lived certificates, but a 30-day warning on a 47-day certificate is noise. Plan to move to thresholds like 14, 7, and 3 days as lifetimes shorten, and treat any certificate that is past its normal renewal point as a failure rather than a reminder.

Four ways to track expiry, and which ones hold up

Approach	Catches a failed renewal?	Catches CDN/chain problems?	Scales to 20 sites?
Calendar reminder on the expiry date	Only if the human checks	No	No
Registrar / CA expiry emails	Sometimes; they go to whoever bought the cert	No	No
certbot post-renewal hook that emails on failure	Yes, if the hook and the mailer still work	No	Only for sites you shell into
External monitor checking the served certificate	Yes	Yes	Yes

The first three all watch the renewal process from the inside, and they all share the same blind spot: they are silent when the process itself has stopped running, when the site moved, or when a layer in front of the server serves something else. The seven ways auto-renewal fails silently are all failures the inside view cannot see.

An external check reads what the visitor reads. It does not care why the renewal broke; it only reports that the certificate in front of the public has N days left, which is the number you actually need.

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. For the platform-by-platform renewal commands, see Certificate has expired: how to fix it on any platform. 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.

Running this across a client roster

If you look after more than a handful of sites, the process needs to survive staff changes and a busy month. A workable minimum:

1. One inventory. Every hostname you are responsible for, its renewal system, the login or person who can renew it, and the current expiry. The shell loop above produces the last column; the rest is a spreadsheet.
2. Every hostname monitored, not every site. www, the apex, shop, app, mail if it has a web interface. Wildcards cover names but are still one certificate that can expire.
3. Alerts to a shared place. A monitoring email that goes to one person’s inbox is a single point of failure. Send it to a shared address or a channel.
4. A named owner per alert threshold. The 30-day alert can be “check the renewal path”. The 7-day alert is a task with a person’s name on it.
5. Write down why each expiry happened. After the second incident with the same cause, fix the cause.

Where a client has their own hosting login and you do not, the monitoring alert is also the thing that lets you email them two weeks early instead of fielding their call at expiry.

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. SitesRadar’s free plan checks one site’s served certificate daily and emails at 30, 14, and 7 days, together with uptime, broken links, and DNS changes; paid plans do the same across a roster. That is how certificate monitoring becomes a service you can reliably provide rather than an emergency you repeatedly explain.

FAQ

How often should the certificate be checked? Once a day is enough for expiry, since the date only moves at renewal. Uptime needs minutes; certificates need days.

Does monitoring renew the certificate for me? No. Monitoring tells you the renewal did not happen. Renewal is done by certbot, your hosting panel, your CDN, or you.

We use Cloudflare. Do we still need this? Yes. Cloudflare renews its edge certificate, but your origin certificate still expires, and in Full (strict) mode an expired origin certificate takes the site down. Monitor both the public hostname and, if you can, the origin directly.

What about internal or staging sites? Same problem, same fix, with the extra wrinkle that internal CAs and self-signed certificates have no vendor emailing you. Anything with a hostname that people use deserves a check. The TrueNAS default certificate is a good example of an internal one that expires quietly.