SSL Certificate Monitoring Guide

An expired or misconfigured TLS certificate can make a healthy service appear unavailable. Certificate monitoring turns that surprise into an operational check.

What SSL certificate monitoring should cover

Browser-facing certificates are often called SSL certificates, although modern deployments normally use TLS. The naming matters less than the outcome: a client must be able to establish a trusted, encrypted connection to the hostname it requested.

A useful monitoring process checks more than the date shown in a certificate portal. It should confirm:

• the certificate has not expired and is not approaching its renewal window;
• the hostname is present in the certificate's Subject Alternative Name (SAN) list;
• the certificate chain can be validated by ordinary clients;
• the endpoint presents the intended certificate after redirects, load balancers, and proxies; and
• renewal changes actually reach every serving endpoint.

Expiry is the clearest failure mode, but it is not the only one. A certificate can be valid for www.example.com while the application is reached at app.example.com. A deployment can update one node while an older certificate remains on another. An incomplete intermediate chain can also work in one environment yet fail in another.

For broader context, see website monitoring alongside certificate checks. A certificate alone does not establish that the application behind it is useful to visitors.

Start with an accurate inventory

You cannot monitor certificates you have not listed. Build a small inventory before choosing thresholds or tooling. Record every public hostname, the service owner, the renewal method, the certificate authority, and where the certificate is terminated.

Include names that are easy to overlook:

• alternate www and non-www names;
• API, admin, staging, and customer-specific subdomains;
• regional or legacy domains still used in links;
• endpoints behind a CDN or reverse proxy; and
• services on nonstandard TLS ports.

The termination point is particularly important. TLS may end at a CDN, cloud load balancer, ingress controller, web server, or application process. The certificate stored on a virtual machine is not necessarily the one clients receive. Monitor from the network path your users take, using the exact hostname and port.

Keep ownership current. Renewal automation reduces work, but it does not remove the need for a person or team to investigate a failed renewal. An inventory gives an alert a destination and gives incident responders a clear starting point.

Check a certificate from the command line

openssl is useful for an immediate inspection from a Linux shell. The -servername option sends Server Name Indication (SNI), which is essential when several sites share an address.

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

The output includes notBefore and notAfter dates, plus the issuer and subject. To inspect the SAN names, run:

openssl s_client -connect example.com:443 -servername example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -text \
  | grep -A1 "Subject Alternative Name"

Use these commands for diagnosis, not as a complete monitoring program. They do not by themselves track a fleet, notify an owner, or verify each edge location. They are, however, valuable when an alert arrives: compare what the endpoint serves with the expected hostname, issuer, dates, and SANs.

Choose alert windows that support action

An expiry alert is useful only if it leaves enough time to investigate and renew. Select several milestones rather than one final warning. The right windows depend on your renewal process, approval steps, and change controls.

At an early milestone, verify ownership and renewal automation. At a nearer milestone, create or escalate a work item and test the renewal path. In the final window, treat an unresolved certificate as an operational risk with a named owner.

Avoid treating every validation failure as an expiry issue. Separate conditions where possible:

1. Certificate expiration is approaching.
2. The certificate is already expired.
3. The hostname does not match.
4. The chain is untrusted or incomplete.
5. The endpoint cannot complete a TLS handshake.

Distinct conditions make the first response faster. A hostname mismatch usually calls for deployment or routing investigation; an approaching expiry calls for renewal verification.

CloudStats can provide SSL certificate monitoring and send its current alert notifications by email. Route those emails to an address watched by the responsible team, and make the alert include enough endpoint context to identify the affected domain.

Make renewal observable

Automatic renewal is only one half of the job. The other half is successful installation and propagation. A reliable runbook makes both visible.

Before the renewal window

Confirm the certificate request method still works. For domain validation, verify that the expected DNS record or HTTP challenge path is controlled by the renewal system. For DNS automation, verify that its credentials and permissions remain valid. Do not wait for the certificate to be close to expiry to discover an integration was removed.

Also check the certificate's intended names. Adding a subdomain after the last issuance may require a new certificate request rather than a routine renewal.

After a renewal or deployment

Query the public endpoint again. Check the new expiry date, SAN list, and issuer. If traffic is served by several instances, verify all of them. A rolling deployment, cached certificate, or missed listener reload can leave a subset of users seeing the old certificate.

Record the change and preserve the output needed for troubleshooting. This is especially helpful when a proxy and origin use separate certificates.

Pair certificate checks with service checks

A valid certificate does not guarantee a working site, and an HTTP check does not always exercise the intended hostname. Use both.

Certificate monitoring answers whether the TLS identity is acceptable. Uptime monitoring answers whether the endpoint is reachable over time. An HTTP or website check can additionally validate status codes, redirects, and a meaningful response.

When an alert fires, work from the outside in: confirm the hostname, test the handshake with SNI, inspect the presented certificate, then check the proxy or server configuration that owns it. This sequence prevents a local file inspection from being mistaken for evidence about the public endpoint.

Keep the process small and repeatable

The goal is not a complicated certificate program. It is a dependable loop: inventory endpoints, monitor the public presentation, warn early, test renewals, and verify deployment after changes.

Review the inventory after migrations and CDN changes.