What crt.guru Checks After TLS Auto-Renewal

crt.guru remains available as an externally hosted TLS monitoring service. It complements rather than replaces ACME, Certbot or another renewal mechanism: its role is to inspect the certificate and TLS configuration that a remote client can reach, then alert the responsible team when that observed state needs attention.

The current capability set extends beyond expiry warnings. The official crt.guru product page lists multi-region scans, email alerts 30, 14, seven and one day before expiry, security checks, PDF compliance reports, a free tier for three assets and an MCP server with 11 tools, alongside a REST API, webhooks, a command-line tool and Shields.io badges.

Renewal success does not prove the public endpoint is healthy

Automated issuance solves an essential but narrower problem: obtaining a replacement certificate before the old one expires. It does not prove that every production listener has loaded the replacement, that a CDN edge is serving the intended chain or that the public hostname still negotiates an acceptable TLS configuration.

A renewal task can finish while deployment fails later in the pipeline. The new files may reach one server but not another, a reload may fail, a load balancer may retain an older certificate, or a hostname may resolve differently from separate locations. Internal automation can therefore look healthy while an external connection still receives the wrong certificate.

This distinction matters at the browser boundary. Chrome’s security documentation identifies an expired certificate as a cause of broken HTTPS and explains how to inspect certificate and origin details. A visitor encountering that state sees the certificate presented over the network, not the successful status recorded by the operator’s renewal task.

What crt.guru observes from outside

crt.guru accepts a hostname and port without requiring an agent, source-code change or server login. It can inspect HTTPS, LDAPS, SMTP with STARTTLS and IMAPS endpoints, so its monitoring model is not limited to websites using the standard HTTPS port.

Its scans cover the certificate chain, protocols, ciphers and related configuration. The capability set includes checks associated with Heartbleed, ROBOT and CCS Injection, as well as HSTS, OCSP stapling, DNSSEC and CAA. These are product-defined checks rather than independent certification of an endpoint’s security, but they provide more information than a countdown to the certificate’s expiration.

Multi-region observation is particularly useful when traffic passes through geographically distributed infrastructure. A probe near the origin may verify only that local path; checks from separate regions can reveal differences in the certificate or chain delivered through remote routes and edge nodes.

External monitoring is a backstop, not a renewal system

A sound operating model has two layers. The first issues, deploys and reloads certificates automatically; the second independently tests the resulting public service. An alert from the second layer should direct the team to the first layer’s logs and deployment state rather than attempting to substitute for them.

This separation is consistent with the Let’s Encrypt integration guide, updated in June 2025, which recommends checking ACME Renewal Information at least twice daily, using automatic renewal with one-third of the certificate’s lifetime remaining as a fallback, retrying failures and sending errors to the responsible administrator. Automation still needs failure handling and accountable notification.

Escalating notice is useful only if it reaches an attended channel and leaves enough time for the team’s change process. crt.guru supports email and messaging-platform notifications, while its API and webhooks can feed an existing incident system. The command-line interface can support inventory or pipeline workflows without turning the monitor into the component that performs renewal.

A practical deployment pattern

Start with endpoints whose failure would interrupt authentication, payments, APIs or customer access. Record the exact hostname, port and expected owner for each endpoint; a single apex domain does not necessarily represent every certificate-bearing service.

Add each externally reachable production hostname and its actual service port.
Confirm that the initial scan observes the expected subject names, issuer, chain and expiration date.
Test delivery into the channel staffed by the team responsible for certificate changes.
Assign an owner and an intervention threshold earlier than the final warning.
After renewal, verify that the externally presented certificate has changed on every relevant path.

The earliest notification should be treated as an investigation point, not permission to wait for the final warning. The response window needs to accommodate failed validation, deployment retries, change approval and rollback.

Consider a conditional example: the renewal task marks its work successful, but the monitor still sees the previous serial number from one remote location. That mismatch does not prove the CDN is at fault. It narrows the investigation to DNS answers, edge configuration, certificate deployment and reload state along that route.

What the service cannot establish

An external TLS scan cannot establish that an application is functionally healthy, that private keys are stored safely or that every internal service is covered. It also cannot guarantee customer retention or quantify revenue protected by avoiding a browser warning. Those outcomes depend on traffic, user behaviour and the importance of the affected endpoint.

The same caveat applies to audit evidence. A generated PDF artifact can preserve useful details about the TLS configuration observed at a particular time, but it is not equivalent to certification against PCI DSS, NIST guidance or another framework. Auditors may still require evidence about scope, ownership, remediation and controls outside TLS.

Inventory remains the decisive input. Monitoring a known certificate does not reveal every forgotten hostname, private listener or newly created service unless the organisation adds or discovers it. APIs, webhooks, command-line access and MCP tools can make that workflow easier to automate, but teams still need a system of record and a rule that brings new endpoints under monitoring.

Where crt.guru fits

crt.guru is most useful when a team wants independent evidence of what its public TLS endpoints are serving, particularly across multiple regions or non-HTTPS services. Keep automated renewal, add external observation, route discrepancies to a named owner and investigate the first unexpected result rather than waiting for expiration.

Auto-Renewal Can Succeed While TLS Still Fails: What crt.guru Checks