SSL Certificate Monitoring: Catch Expiration Before Your Users Do

A certificate expires at a precisely defined time. This makes the resulting outage one of the few incidents that brought its own calendar invitation. The difficulty is making sure somebody receives it before the browser does.

SSL certificate monitoring checks the certificate a service actually presents and gives its owner time to act. “SSL” remains the familiar search term; modern HTTPS uses TLS. In RMON, certificate information and expiration warnings are part of an HTTPS check.

Monitor the certificate users receive

Start with the public hostname and port your users connect to. If a CDN or load balancer terminates HTTPS, its certificate is the one those users see. A newly renewed file on the application server does not prove the public endpoint has started presenting it.

Use the hostname in the URL. Replacing it with an IP can change certificate selection or cause a hostname mismatch. Where several entry points matter, monitor those entry points deliberately rather than assuming that one successful connection covers every listener.

Different monitoring locations can reach different endpoints. This is useful evidence after a rollout, but a handful of probes cannot certify every node in a large delivery network. Record which paths you have actually tested.

Separate expiration, trust and HTTPS policy

These checks answer related but distinct questions:

• Expiration: how much time remains before the presented certificate expires?
• Certificate verification: does the connection validate for the requested name and the trust available to the agent?
• HTTPS policy: does the final URL use the protocol required by the check?

A certificate can have months remaining and still be unsuitable for the requested hostname. An untrusted issuer can also cause a failure long before expiration. Keep Ignore TLS/SSL errors disabled for normal monitoring so those failures remain visible.

RMON’s Require HTTPS policy evaluates the final URL after allowed redirects. It does not replace certificate verification. If your purpose is checking a particular HTTPS endpoint, use that endpoint directly and review whether following redirects would take the request somewhere else.

Configure the HTTPS check and warning periods

1. Create an HTTP(s) check using the intended HTTPS URL and monitoring locations.
2. Set the expected response and keep certificate verification enabled. Confirm a fresh successful result.
3. Review certificate validity and the days remaining on the check’s results page.
4. Open Admin area → Settings → RMON and review the warning and critical certificate-expiration periods.
5. Assign a tested notification channel to the check and identify the team responsible for renewal.

The standard initial warning and critical settings are 14 and 7 days. Read your installation’s saved values before relying on those numbers: administrators can change them. These periods are managed in Settings, not as a separate pair of expiry fields on each HTTP check.

Choose a warning period that leaves time for your renewal and deployment process. A seven-day reminder is less helpful if a change requires two weeks of coordination. The HTTPS check guide covers the request and validation options.

Verify renewal at the endpoint

After renewal, verify that the service has loaded the replacement certificate. Wait for new measurements from the intended locations and inspect the reported expiration information. A certificate file on disk and a certificate served over the network can have an awkwardly distant relationship.

When a warning remains, inspect the presented certificate, hostname, chain, termination point and result timestamp. Consider whether different locations reach different listeners. Avoid changing thresholds simply to make an unresolved warning disappear.

For an end-to-end exercise, use a controlled test endpoint with a certificate approaching your configured warning period. Verify the notification, replace the certificate, and allow fresh checks to confirm the updated state. Keep production-wide thresholds unchanged during this test.

Keep renewal ownership and monitoring scope explicit

RMON observes and reports; this check does not renew your website certificate. Keep renewal automation or procedures with the service owner, and include a runbook explaining where HTTPS terminates and how to verify a replacement.

An HTTPS check also does not inventory every certificate file or private key in your infrastructure. Certificates used for agent-to-receiver mTLS have their own lifecycle. Monitoring a website’s certificate does not establish that those client credentials are about to be renewed.

Use the mTLS operations article for that separate connection and the notification guide to verify delivery. The practical outcome is enough notice, a named owner and evidence that the replacement is being served.