How to Monitor SSL Certificate Expiration Before It Breaks Access

Build the inventory from access paths

Record service, public or private hostname, port, certificate binding, issuer, expiry, renewal method and owner. Include proxies and gateways between clients and the application. A certificate stored on an RDS server is not necessarily the one every client-facing endpoint presents.

For private PKI, inventory roots and intermediates separately with a rotation owner. Renewing a leaf certificate does not extend its issuer's lifetime or update every client trust store.

Inspect a standard HTTPS endpoint

This Bash example uses OpenSSL and GNU timeout. Replace example.com with a hostname you administer. It saves certificates to a temporary file and checks the presented leaf's remaining lifetime; it also requires the TLS connection to pass hostname and trust validation.

#!/usr/bin/env bash
set -euo pipefail
cert_host=example.com
cert_file=$(mktemp)
trap 'rm -f "$cert_file"' EXIT

timeout 15 openssl s_client \
  -connect "${cert_host}:443" -servername "$cert_host" \
  -verify_hostname "$cert_host" -verify_return_error \
  -showcerts </dev/null >"$cert_file"
openssl x509 -in "$cert_file" -noout -subject -issuer -dates
openssl x509 -in "$cert_file" -noout -checkend 2592000

The final value is an illustrative 30-day warning window in seconds. OpenSSL x509 (opens in a new tab) documents -checkend; s_client (opens in a new tab) documents the connection and verification options. A nonzero result needs investigation: distinguish collection or trust failure from a successfully collected certificate nearing expiry.

For a private CA, configure the intended trust material explicitly. Do not disable verification merely to clear the monitor. This HTTPS example does not implement RDP's protocol negotiation or verify all RDS role bindings. Use service-specific administration and a real client connection for those paths.

Route warnings early enough to act

Choose warning windows from the renewal and rollout lead time. A routine early warning can create an owned task; a near-expiry condition may need escalation. Avoid sending repeated overnight pages for a certificate that already has a scheduled renewal and ample margin.

Keep failed collection visible too. A DNS error that prevents reading the certificate must not reset its status to healthy.

Verify renewal from the client side

After renewal and the required reload or binding update, reconnect through each relevant endpoint. Compare serial or fingerprint and expiry, then test hostname, chain and normal application access. Check multiple backends where a load balancer can expose inconsistent certificates.

In a test environment, exercise an approaching-expiry certificate, an untrusted chain, a wrong hostname and a connection failure. Confirm distinct findings reach the owner. Save the renewal procedure and CA dependencies in the runbook template.