Monitoring TLS certificate expiry on every endpoint, not only the main website

Goal

Never learn about an expired certificate from a user. Every certificate the organisation serves has a known expiry date and an alert that fires early enough to repair renewal by hand.

Prerequisites

An inventory of hostnames and ports that terminate TLS (443, but also SMTP, IMAP, LDAP, database ports, admin panels, load-balancer listeners, VPN endpoints); a monitoring system that runs probes on a schedule; knowledge of how each certificate is issued (ACME client, provider-managed, manual).

Steps

1. Build the inventory from what is actually served, not from what is documented: scan the owned addresses and DNS names for TLS listeners and record host, port, subject and issuer.
2. For each endpoint, probe from outside the host and read the chain as a client sees it. RFC 5280 defines the validity period by notBefore and notAfter; the leaf and each intermediate carry their own.
3. Compute days until notAfter for the leaf and the intermediates and export it as a metric. For a script, the OpenSSL manual documents openssl x509 -checkend <seconds>, which exits nonzero when the certificate expires within that many seconds; the 3.6 manual adds -multi, with which -checkend fails if any certificate in the input (for example a saved chain) expires within the period. The 3.5 manual does not list -multi, so on older releases check the leaf and each intermediate separately.
4. Set the threshold relative to the issuance mechanism. Let's Encrypt states that its default certificates are valid for 90 days and recommends renewing them every 60 days, and that its short-lived certificates are valid for six days with renewal every three. For the 90-day case, renewal at day 60 leaves 30 days; an alert at 20 days remaining therefore means automated renewal has already missed a cycle while a person still has time. Six-day certificates need a threshold measured in hours.
5. Alert also on probe failure (port closed, handshake error) and on a certificate whose subject or issuer differs from the expected one.
6. Test the alert by probing a deliberately short-lived certificate or by raising the threshold above the current remaining days for one endpoint.
7. Record for each endpoint who renews it and how; the runbook for the alert is "run the renewal, then re-probe".

Expected result

One view of every certificate's remaining lifetime, an alert that fires while renewal by hand is still comfortable, and no endpoint whose certificate is a surprise.

Limits and test basis

Probing from inside the host misses certificates presented by a fronting load balancer or CDN. Client certificates and code-signing certificates need the same inventory but different probes. Lifetimes follow the cited issuer statements; no failure statistics are claimed.