A certificate monitor that reports “expired” whenever a command fails will eventually send you on the wrong investigation. A missing file, a TLS handshake failure and a certificate approaching its expiry are different observations.
Start with a file you already know represents the certificate you intend to monitor. Later, add a separate acquisition step for the live endpoint. Keeping those steps distinct makes failures explainable.
Check the file before checking the threshold
openssl x509 -in server.pem -noout -dates -ext subjectAltName
openssl x509 -in server.pem -noout -checkend 604800
604800 is seven days in seconds. The -checkend option checks whether the certificate expires within that interval and uses a nonzero exit status when it will. The display command gives you the actual dates and names to record. OpenSSL 3.5 — openssl-x509
Do not infer the reason from a nonzero status alone. A parse error also prevents a useful check. Verify that the input can be read, preserve standard error, and classify an unusable input as unknown.
PKI Channel’s monitoring decision map provides a useful model for the states below: a missing measurement and a failed TLS probe need their own investigation paths, separate from the remaining lifetime.
A monitoring result needs a state
| State | Evidence | Action |
|---|---|---|
| Readable, beyond threshold | Parsed dates and a successful threshold check | Record the observation time |
| Readable, inside threshold | Parsed expiry and threshold result | Investigate renewal before the remaining time runs out |
| Input unavailable or invalid | Fetch or parse error | Repair observation and investigate the endpoint |
| Wrong identity | SAN does not cover the intended name | Investigate routing or configuration |
An “unknown” state is operationally useful. It says the monitor lacks evidence, rather than inventing a healthy or expired result. Decide separately when persistent unknown observations should page an operator.
The disk file may not be the served certificate
Suppose renewal writes a new certificate to disk, but a process still holds the old one in memory. Monitoring only the file can report a healthy future expiry while clients receive the old certificate. A CDN adds another possible certificate owner.
For endpoint monitoring, record the hostname, port, network location and certificate obtained from that connection. Validate the peer according to the intended trust configuration. An expiry date extracted from an unverified connection is an observation, not proof of the endpoint's authenticated identity. RFC 8446 — TLS 1.3 / RFC 9525 — Service Identity in TLS
To choose an alert threshold, use the short-lived certificate operations guide to work backward from detection, retry, deployment and recovery time. A fixed number of days is only useful when the team can complete that work within it.
Choosing the threshold
Seven days is an example, not a universal recommendation. Work backward from the time needed to detect a failed update, reach the responsible person, repair validation, deploy the replacement and confirm it from the client side. If that process takes longer than your alert window, a technically correct monitor will still warn too late.
Keep the issued certificate's full lifetime separate from the remaining lifetime at observation time. Shorter issuance limits do not tell you exactly when a particular certificate will expire.
A record worth retaining
Store observation time, target, expiry, remaining time, state, collection error and owner. Avoid overwriting the last known expiry with a blank value when collection fails. Preserve the old observation with its timestamp and add a new unknown result. That makes a gap visible without pretending stale data is current.
Top comments (0)