SSL certificate monitoring that catches more than expiry

SSL certificate monitoring checks the certificate a live service presents and warns when it will expire or when clients cannot trust it. For an IT team, the job also includes detecting failed renewal and installation attempts. A certificate can be valid in the CA portal while the VPN gateway continues serving yesterday's certificate.

“SSL” remains a common search term, although modern secure connections use TLS. This guide covers server TLS certificates on HTTPS services, including VPN portals and reverse proxies. Other protocols may need different probes.

Monitor the endpoint users actually reach

Start with a hostname and port, not a certificate file on disk. Include the public application, remote desktop gateway, firewall portal, and other user-facing services in the certificate inventory.

Choose the monitoring location deliberately. An external probe tests the internet-facing route. An internal probe can reach private services. Both may be needed when split DNS sends users to different endpoints. Record when a CDN or load balancer terminates TLS before traffic reaches the origin.

If a hostname has several addresses or backends, one successful connection may only verify one path. Monitor the user-facing endpoint and add checks for individual nodes where your architecture allows them. Keep the expected hostname in those checks so an IP-based probe does not accidentally test the default virtual host.

Check five things on each connection

An expiry date is necessary, but it does not establish a healthy service. A useful probe checks:

1. Reachability. Can the probe establish a connection to the expected port?
2. Validity dates. Is the certificate valid now, and how much lifetime remains?
3. Hostname coverage. Does the certificate cover the name users requested?
4. Trust. Can the probe validate the chain against its intended trust store?
5. Deployment identity. After a renewal, does the live certificate match the replacement you expected?

Record the observation time and the endpoint tested. A green status without a timestamp can conceal a probe that stopped running. Decide what “unknown” means and alert when monitoring itself goes stale.

Inspect a live certificate with OpenSSL

For a read-only inspection of a service you administer, replace the example hostname with your own:

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

This prints the leaf certificate's details. It is an inspection command, not proof that the service passes trust or hostname validation. To request those checks with OpenSSL, use:

openssl s_client -connect vpn.example.com:443 \
  -servername vpn.example.com \
  -verify_hostname vpn.example.com -verify_return_error \
  -brief </dev/null

Use an appropriate trust store for your environment. Private PKI may require an explicit CA file. OpenSSL's s_client reference documents these flags. A successful TLS check still needs an application check when the renewal affects a VPN, gateway, or business application.

Alert on failed attempts before the expiry countdown

If renewal fails today and the certificate expires in several weeks, investigate today. Waiting for a final expiry alert wastes the recovery window.

Keep separate events for issuance failure, deployment failure, verification failure, and upcoming expiry. They have different owners and remedies. The renewal troubleshooting guide follows that sequence.

Avoid a single universal alert threshold. Choose lead time based on certificate lifetime, the normal renewal window, retry behavior, and how long your team needs to recover. A 30-day reminder behaves very differently on a 47-day certificate than on a longer-lived one. The public TLS schedule explains the forthcoming limits.

Make every alert actionable

An operator should be able to act without first searching three consoles. Include the customer and service name, failing endpoint, stage, remaining validity, latest error, and link to the runbook. Name the primary owner and the escalation path.

Group repeated failures from the same incident. Escalate when the certificate moves closer to expiry or a previously reachable service stops answering. Resolve the alert when a fresh check confirms recovery, rather than when someone acknowledges the notification.

Test the notification route with a harmless test event and confirm another technician receives it. Do not deliberately break a production certificate to prove that monitoring works.

Monitoring and automation work together

Monitoring tells you what happened. Automation performs the renewal and install. Keep evidence of both: the job result and an independent observation of the live endpoint.

When evaluating Certonomy founding access, compare the published renewal workflow with your monitoring requirements. Its planned launch scope includes firewalls, Windows roles, and web servers. Start with a service that has a clear owner and a documented recovery path, then expand once a full renewal has been observed.