How do you monitor TLS certificate expiry on bare metal servers?

TLS certificate expiry monitoring on bare metal requires connecting to each TLS endpoint and reading the certificate's notAfter field directly from the live handshake — not from an inventory record. This approach catches chain errors, hostname mismatches, and misconfigured deployments that inventory-only monitoring misses. Tools like CertLocker run continuous endpoint probes and alert at configurable thresholds before expiry.

What is the difference between certificate inventory monitoring and endpoint probing?

Inventory monitoring reads certificate records from a database or spreadsheet. Endpoint probing connects to the live TLS endpoint and reads the certificate actually being served. Inventory is often wrong — a renewed certificate may not have been deployed, or may have been deployed to some servers but not others. Endpoint probes tell you what clients actually experience.

How far in advance should you alert before a TLS certificate expires?

Industry practice is to alert at 30 days, 14 days, and 7 days before expiry. For certificates with automated renewal, 30 days is the primary trigger. For certificates with manual renewal processes, 60 days gives enough time. With 47-day certificate lifetimes becoming standard, alert thresholds need to shift earlier — 14 days is too late to catch a renewal failure with a short-lived certificate.

How to Monitor TLS Certificate Expiry Across a Bare Metal Fleet

The problem with inventory-only monitoring

Most teams start certificate monitoring by tracking the expiry dates of certificates in a spreadsheet, a database, or a secrets manager. The spreadsheet shows "expires 2026-09-15" so the team creates a calendar reminder for September 1st. This approach is wrong in a specific, predictable way.

The inventory record tells you what certificate was issued. It does not tell you what certificate the endpoint is actually serving. The two are frequently different:

A certificate was renewed but not deployed — the old certificate is still running
A certificate was deployed to one server in a load-balanced pool but not others
A certificate was deployed to the wrong path and the old configuration is still active
A deployment script ran but failed silently — the service reloaded with the old certificate
A server was rebuilt and the renewed certificate was not included

In each of these cases, inventory monitoring shows "expires September 15" while the endpoint is actually serving a certificate that expired weeks ago.

Endpoint probing: connecting to check what is served

Endpoint probing connects to the TLS endpoint — the actual IP and port — performs a TLS handshake, reads the certificate chain presented by the server, and extracts the notAfter date from the leaf certificate. This is what clients experience. The probe can also check:

Chain validity: Are the intermediate and root certificates present and valid? A certificate with a valid leaf but a missing intermediate will fail in some clients.
Hostname match: Does the Subject Alternative Name (SAN) or CN match the hostname in the probe request? A certificate deployed to the wrong virtual host will pass an inventory check and fail this one.
Protocol and cipher: Is the server offering deprecated TLS versions or weak ciphers?
OCSP stapling: Is the server providing a valid OCSP response?

CertLocker runs these checks continuously, at configurable intervals, against every registered endpoint. The expiry alert threshold is configurable — most teams use 30 days, 14 days, and 7 days as alert tiers.

Manual approach: using openssl

For teams that want to understand the underlying check before automating it, the standard manual approach is:

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

This prints the notAfter date of the certificate served by the endpoint. Pipe it through date to calculate days remaining:

EXPIRY=$(echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))
echo "Days until expiry: $DAYS_LEFT"

This works for a single endpoint. For a fleet, running this script against 100+ endpoints, collecting results, and alerting on thresholds is a maintenance burden. It also only checks expiry — it does not check chain, hostname, or OCSP.

What changes with 47-day certificate lifetimes

The CA/Browser Forum is moving toward 47-day maximum certificate validity. At 47-day lifetimes, the standard 30-day alert threshold leaves only 17 days before expiry when the first alert fires. If renewal fails and the next alert fires at 14 days, you have 2 days to debug a renewal problem and redeploy.

With short-lived certificates, the alert thresholds need to shift proportionally:

For 90-day certificates: alert at 30, 14, 7 days
For 47-day certificates: alert at 20, 10, 5 days — and treat a failed automated renewal as a P1 immediately
For certificates shorter than 30 days: automated renewal is not optional, it is the only operational model

The direction of travel is clear: certificate lifetimes are getting shorter, and manual renewal processes are being automated out of existence. Teams that have not set up ACME automation will face increasing pressure as 47-day lifetimes become the baseline.

HAProxy-specific considerations

HAProxy presents TLS on its frontends and optionally verifies certificates on its backends. Monitoring for HAProxy environments requires checking both layers:

Frontend certificates: The certificate presented to clients. This is the most visible — a frontend certificate expiry is an immediate client-facing outage. Probe the HAProxy listener directly.

Backend certificates: When HAProxy is configured with ssl verify required on backends, it validates the certificates presented by upstream servers. A backend certificate expiry causes HAProxy to mark the backend as DOWN and return 503 errors — which looks identical to a backend process crash in monitoring.

CertLocker endpoint probes can be configured to check both the frontend listener and each backend server individually. The ownership model in CertLocker allows assigning different alerting thresholds to frontend vs backend certificates based on their impact profile.

Multi-environment bare metal fleets

Bare metal fleets often span multiple environments: production racks, staging, disaster recovery, and colocation sites. Each environment may use different certificates — different CAs, different validity periods, different renewal processes.

A common failure mode is renewing the production certificate correctly and forgetting the DR environment. The DR environment runs with an expired certificate until a failover reveals the problem at the worst possible moment.

The fix is the same for all environments: endpoint probes registered against every TLS endpoint, not just production. CertLocker's group and ownership model allows labelling endpoints by environment so that DR and staging alerts can be routed to the right team without noise in production channels.

Putting it together: a monitoring stack for bare metal

A practical certificate monitoring setup for a bare metal fleet:

Inventory: Register all TLS endpoints in CertLocker, including the certificate subject, issuer, and owner. This is the baseline — you need to know what exists before you can monitor it.
Endpoint probes: Configure a probe for each registered endpoint. Set alert thresholds appropriate to the certificate lifetime (see the 47-day section above).
Alert channels: Route alerts to the team that owns each certificate. Certificates owned by the networking team should not page the application team.
ACME automation: For any certificate that can be renewed via ACME, configure automated renewal. Treat a renewal failure alert as a P1 — a certificate that did not renew is an expiry incident in slow motion.
Renewal verification: After each automated renewal, verify the endpoint probe shows the new certificate. Renewal without deployment verification is not renewal.

Further reading: CertLocker endpoint probes · What happens when a TLS certificate expires · The 47-day certificate · CertLocker for bare metal infrastructure