SSL certificate monitoring: expiry, renewal and unexpected issuance

People commonly search for SSL monitoring, although modern HTTPS uses Transport Layer Security, or TLS. A website certificate connects a public key to a domain name and supports server authentication. The encrypted connection helps protect information travelling between a browser and a server. MDN explains how TLS and certificates work.

For an operational review, record the exact hostname, certificate validity dates, issuer, covered names and the time of the observation. Check whether the connection validates successfully. A certificate for one hostname does not establish that every hostname in your portfolio works.

Keep the question narrow: can a client establish a valid HTTPS connection to this name? That answer does not establish that the application is correct, the business is trustworthy or the underlying domain registration is current.

Treat issuance and deployment as separate steps in your renewal checklist. An automation log can report that a certificate was issued while an older certificate remains configured on a public endpoint. Your final verification should inspect the endpoint, not just the renewal job.

Consider a hypothetical startup moving app.example.com to a new hosting service. The new service obtains a certificate successfully, but the team leaves one old endpoint in its traffic configuration. A check that reaches that endpoint still sees the earlier certificate. Issuing another certificate would not explain which endpoint needs attention.

Compare the observed certificate with the one the hosting provider expects to serve. Record the hostname and observation time when asking the provider to investigate. If traffic is distributed across several endpoints, verify the deployment through the provider's supported diagnostics rather than assuming one successful connection describes every path.

Automatic renewal should be the routine, with a named person responsible for failures. Let's Encrypt recommends using ACME Renewal Information when supported and maintaining an automatic renewal fallback. Its guidance also calls for controlled retries and reporting errors to the responsible administrator. Read the renewal guidance.

Use this checklist when you take responsibility for a domain:

1. Identify who manages HTTPS. Record the hosting account or internal service responsible for issuing and installing the certificate.
2. Check the renewal mechanism. Confirm that the scheduled client or managed hosting feature is enabled and that someone can read its failure logs.
3. Verify access after infrastructure changes. A DNS migration, firewall change or removed credential deserves a renewal review.
4. Leave time to investigate. Choose reminder dates that give your team enough working time to repair the process before expiry.
5. Confirm the public result. After renewal, check the certificate presented by the expected hostname and retain that observation.

An expiry reminder is a prompt to verify the process. It does not renew or install a certificate.

Certificate transparency, often shortened to CT, records certificates and precertificates in public, append-only logs. A CT monitor follows entries in the logs it checks and can surface certificates associated with a domain. The Certificate Transparency project describes this process.

A log entry and a live website observation answer different questions. A new entry is evidence that a certificate or precertificate appeared in a checked log; it is not evidence that the certificate is deployed on your website. Treat that distinction as the starting point for investigation.

Compare an unexpected entry with recent hosting changes and approved certificate providers. Keep the issuer, names, dates and certificate identifier in your investigation notes. Escalate an unexplained entry to the person responsible for the domain and certificate authority relationship. Avoid labelling it an attack before reviewing the evidence. CT visibility also depends on the monitor's log coverage and processing delay.

Start with the observed condition. An approaching expiry, a failed connection and a changed issuer each need a different response. Preserve the original result so that a later successful check does not erase the context.

For an expiry reminder, compare the displayed date with the hosting provider's current certificate. Check for a successful renewal and deployment before deciding whether action remains necessary. For a validation failure, capture the exact error and hostname, then ask the operator to verify the served certificate and chain.

For an issuer change, review the deployment record. A planned migration can explain the change; an unexplained result needs further investigation. After a repair, verify a fresh observation and note what changed.

Assign an owner and a follow-up time to unresolved findings. A reminder delivered to a shared inbox without a responsible person is easy to overlook, even when the monitoring result is correct.

Maintain separate records for certificate validity and domain registration. They have different renewal processes and may have different owners inside your organisation. A completed domain renewal is not a certificate deployment check.

Review certificate findings beside DNS record changes and website uptime observations to form a useful investigation timeline. If the domain's registration itself needs attention, use the domain expiration checklist.

Track.Name's approach places certificate observations alongside the wider domain history. When evaluating monitoring, ask which hostnames and signals are covered, how recent the observations are, and what evidence accompanies a change. Those answers are more useful than a dashboard that simply says everything is secure.