SSL Certificate Monitoring: What to Check and When to Alert

SSL certificate monitoring is a scheduled check, run from outside your infrastructure, that connects to each of your HTTPS endpoints and looks at the certificate it presents. A useful check answers four questions: is the certificate still valid and how long until it expires, does it cover the host name being requested, does the server send the full chain of intermediate certificates, and is it the certificate you expect from the issuer you expect. Expiry gets the most attention because it is predictable, but the other three cause just as many outages.

This guide covers what to check, how expiry monitoring works under the hood, how far ahead to alert, and where renewal automation tends to break.

What to monitor about a certificate

Expiry date

Every certificate has a notBefore and a notAfter date. After notAfter, browsers show a full-page warning and most API clients refuse to connect. You can read both dates with OpenSSL:

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

Certificate lifetimes are getting shorter. Publicly trusted certificates issued since March 15, 2026 can be valid for at most 200 days, and the limit falls to 47 days by 2029, so expiry is no longer a once-a-year event. See the 47-day certificate schedule for the dates.

Host name coverage (SANs)

Browsers check the requested host name against the certificate's Subject Alternative Name (SAN) list, not the old Common Name field. A certificate for example.com does not cover www.example.com unless that name is also listed, and a wildcard such as *.example.com covers one level of subdomain but not the bare domain. List the names on a live certificate with:

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

When a name is missing, Chrome shows NET::ERR_CERT_COMMON_NAME_INVALID. Our guide to that error explains the wildcard rules and common causes in detail.

The certificate chain

Your server should send its own certificate plus the intermediate certificate (or certificates) that link it to a trusted root. If an intermediate is missing, some browsers quietly fetch it and the site looks fine, while curl, mobile apps and server-to-server integrations fail with "unable to get local issuer certificate". This is easy to miss with a browser test alone. See missing intermediate certificates for how to detect and fix it.

Self-signed and untrusted certificates

A self-signed certificate, or one issued by a private CA, is fine on an internal service where clients are configured to trust it. On a public site it produces NET::ERR_CERT_AUTHORITY_INVALID in Chrome and SEC_ERROR_UNKNOWN_ISSUER or a self-signed warning in Firefox. A common way this happens by accident is a web server or appliance falling back to its default "snakeoil" certificate after a configuration error.

Issuer and key changes

If your certificates normally come from one CA and a new one suddenly appears from another, that is worth knowing about. It may be harmless (a hosting provider switched CAs) or it may mean someone issued a certificate for your domain without your knowledge. Two tools help:

• Certificate Transparency logs. Public CAs log every certificate they issue. Searching the logs for your domain, for example on crt.sh, shows every certificate issued for it, including ones you did not request.
• CAA records. A DNS CAA record lists which CAs may issue for your domain. Publicly trusted CAs are required to check it before issuing.

Key changes matter too if any client pins your public key, which some mobile apps do. A renewal that generates a new key can break those apps even though the certificate is perfectly valid.

How expiry monitoring works

An external expiry monitor does roughly what the commands above do:

1. Opens a TCP connection to port 443 and starts a TLS handshake, sending the host name through SNI so the server picks the right certificate.
2. Reads the leaf certificate the server presents and takes its notAfter date.
3. Compares that date with today and the alert thresholds you set.
4. Repeats every day, because the date only changes when the certificate is replaced.

The important detail is that it checks the certificate being served, not the file on disk or the order in your CA account. A renewed certificate that was never deployed, or deployed to only one of three load-balanced servers, still shows up as expiring.

If you want a quick look at a single site without setting anything up, our free SSL certificate checker shows the expiry date, issuer and covered host names.

A do-it-yourself check

OpenSSL's -checkend option exits with a non-zero status if the certificate expires within the given number of seconds, which makes a cron-friendly script easy:

#!/bin/sh
# Warn if the certificate for $1 expires within 14 days (1,209,600 seconds).
host="$1"
if ! echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -checkend 1209600 >/dev/null; then
  echo "Certificate for $host expires within 14 days (or could not be read)"
  exit 1
fi

The weakness of a home-grown script is that it runs on your own server and only reports when it runs. If the server is down or cron stops, nothing tells you. Pairing it with a heartbeat monitor closes that gap.

How far ahead to alert

The right lead time depends on how the certificate is renewed.

For automated certificates the first alert is really an alarm that automation has failed. If a certificate that should renew 30 days out is still unrenewed at 14 days, something in the pipeline is broken and needs a person. Alerting earlier than the automation's own renewal point only produces noise.

For manually handled certificates, allow time for the slow parts: purchase approval, domain or organization validation, and a change window to deploy. Then keep alerting daily in the final days, because a single email is easy to lose.

Automation pitfalls

Automated renewal is the right default, but "it renews itself" is not the same as "it is fine". These are the failures to plan for.

Renewed but not reloaded

Certbot and other ACME clients write the new certificate to disk, but nginx, Apache and HAProxy keep serving the old one from memory until they are reloaded. Use a deploy hook:

certbot renew --deploy-hook "systemctl reload nginx"

Validation breaks after an unrelated change

HTTP-01 validation needs /.well-known/acme-challenge/ reachable over port 80. A new redirect rule, a WAF policy, a move behind a CDN or closing port 80 can all break it. DNS-01 validation breaks when nameservers move or API credentials for the DNS provider expire. Test with:

certbot renew --dry-run

Some servers renewed, others not

With several servers behind a load balancer, each may hold its own copy of the certificate. One stale node means a fraction of visitors see an expired certificate, which looks random and is hard to reproduce. Monitor each public endpoint, and if possible check individual nodes too.

Forgotten certificates

The certificates that expire in practice are often the ones nobody thinks of: a mail server, a staging site that a client still uses, an old API host name, a status or admin subdomain. Keep an inventory, ideally generated from Certificate Transparency logs or your DNS zone, and monitor everything on it. A list of which URLs to monitor is a good starting point.

Hard-coded renewal schedules

A cron job that renews "every 60 days" worked when certificates lasted 90 days. With shorter lifetimes it will eventually renew too late. Renew based on the certificate's actual remaining lifetime, or use an ACME client that supports ACME Renewal Information (RFC 9773), which lets the CA suggest when to renew.

Putting it together

A practical setup for a small team looks like this:

• Automated renewal everywhere it is supported, with a reload hook.
• An external daily check of every public HTTPS endpoint, alerting at 14 days for automated certificates and 30 days for manual ones.
• A periodic look at Certificate Transparency results for your domains.
• A check of the chain and host names after every certificate or infrastructure change.

PingRobot includes SSL certificate expiry reminders on every plan: each HTTPS monitor reads the certificate daily and emails you 7, 14 or 30 days before it expires, whichever you choose, then every day in the last three days.

Start monitoring free — 10 monitors, no credit card.