How to monitor SSL certificate expiry (and never get caught by an expired cert)

Why certificates expire

Every public TLS certificate has a fixed end date, its notAfter date. After that moment, browsers refuse it. Short lifetimes are deliberate: they limit the damage of a stolen key or a domain that changed owners.

Lifetimes are getting shorter. In April 2025 the CA/Browser Forum adopted ballot SC-081: the maximum lifetime drops in steps from 398 days to 47 days between March 2026 and March 2029. Let's Encrypt issues 90-day certificates today and plans 64 days from February 2027 and 45 days from February 2028. More renewals mean more chances for one to fail.

How automatic renewal fails

An ACME client such as certbot, acme.sh, Caddy, Traefik or cert-manager renews a certificate long before it expires. When a certificate still expires, the cause is usually one of these:

• The renewal job stopped. A server move, an OS upgrade or a removed cron entry or systemd timer, and nobody noticed.
• The challenge fails. HTTP-01 needs port 80 to reach the client; a new firewall rule, CDN setting or redirect can block it. DNS-01 needs a working DNS API token, and tokens expire.
• The server did not reload. The new certificate is on disk, but the web server or load balancer still serves the old one from memory.
• Only one copy was renewed. A second server, a load balancer or a CDN has its own copy.
• Nobody saw the warning. Let's Encrypt stopped its expiry emails on 4 June 2025. Other warnings go to an address nobody reads.

Other ways a certificate breaks

• Incomplete chain. The server sends its certificate without the intermediate. Many browsers work around it; curl, API clients and many apps fail.
• Wrong host name. The certificate does not cover the name visitors use, for example www, or a new subdomain.
• Self-signed or private CA. Fine on an internal network, an error for the public.

Check a certificate with openssl

Read the subject, the issuer and the expiry date. -servername sends the host name (SNI); without it, a shared server can return another site's certificate.

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

Find out if it expires within 14 days (1,209,600 seconds). The command prints “Certificate will expire” and exits with 1 when it does, so a script can act on it:

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

List the host names the certificate covers (OpenSSL 1.1.1 or later):

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

Check the chain and the host name in one step:

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com </dev/null 2>/dev/null | grep "Verify return code"

0 (ok) is good. Common errors are 10 (certificate has expired), 21 (unable to verify the first certificate) for a missing intermediate and 62 (hostname mismatch).

These commands check one host, from one place, once. In a cron job they become a small monitor, which then needs its own alerting and someone to notice when the cron job stops.

What to alert on

• Days left. Warn at 14 days or more. ACME clients usually renew with about 30 days left, so at 14 days the renewal has failed for over two weeks, and you still have time. Certificates you renew by hand need a longer warning.
• Expired. A critical alert: the site is unusable for most visitors.
• Chain not trusted, or wrong host name. Alert at once: some visitors fail today.
• Renewed. One “all clear” message, so you know the fix worked.

Check every host name you serve, from outside your own network, the way visitors reach it. Send the alert to a channel a person reads, not to the address in the ACME account.

How UptimeVanguard checks certificates

• Every monitor with an https:// address gets a certificate check, on every plan. It runs at least once a day; you can choose every 1, 6, 12 or 24 hours.
• The check reads the certificate even when it is expired or untrusted, and a second, verified handshake decides trust. It reports valid, expires soon, expired or not valid: an untrusted chain, self-signed, the wrong host name or not yet valid.
• You get one alert when the certificate is within 14 days of expiry (the API setting tls_expiry_threshold_days changes this, from 1 to 365). Expired and not valid alerts are critical, and the monitor shows a warning with the reason. After a renewal you get one “renewed” alert.
• Alerts go to email, Slack, Microsoft Teams, Telegram, SMS through your own provider account and more, on the Free plan too.
• SSL score grades the TLS setup of a domain with testssl.sh. Scans run weekly, monthly or quarterly, or daily on a paid plan.

To check one certificate now, without an account, use the free SSL checker. It shows the expiry date, the issuer, chain trust, the host name match and the chain the server sends. To watch for downtime as well, read how to get an alert when your website goes down, or start for free.