How the check works

The check reads two things: the certificates a domain's servers send now, and the domain's public certificate history. From the history it infers how renewals have been running, and asks whether that rhythm holds when certificates get shorter. This page explains each step and what the check cannot see.

Why lifetimes matter now

Public TLS certificates are getting shorter, and shorter certificates need renewals that come on time, every time:

From 10 Feb 2027 almost every Let's Encrypt renewal also needs a fresh validation, so a firewall, DNS or proxy change that breaks validation shows up as a failed renewal within one cycle.

1. What the servers send now

For the name you type and its www twin, and later for up to 20 names found in the history, we look up the address in DNS and open a TLS connection to port 443. We read the certificate chain and close the connection. Then we check:

• whether the chain reaches a trusted root using only the certificates the server sends (browsers may repair a missing intermediate; curl, Java, mail servers and many APIs will not),
• whether the certificate covers the name, and whether it is valid now,
• when it is due for renewal (below), using the CA's own renewal window where the CA publishes one (ACME Renewal Information, ARI),
• whether the domain's CAA records allow the CA that issued it, and
• the domain's security.txt (RFC 9116), if there is one.

Names without a public address are shown as not reachable from the internet. We connect over IPv4 only for now.

2. When a renewal is due, overdue or critical

We never use fixed day counts such as "30 days before expiry". A reminder like that fires on every cycle of a healthy 47-day certificate. Instead, each certificate is measured against its own lifetime:

• Due from half its lifetime, or from the start of the CA's renewal window.
• Overdue at two thirds of its lifetime, or at the end of the CA's renewal window, plus a short grace (a thirtieth of the lifetime, between 12 hours and 3 days). This is the one that matters: the renewal should have happened by now.
• Critical in the last tenth of its lifetime (between 2 and 14 days).

Certificates of 180 days or more are almost always bought and installed by hand, so they get two plain reminders instead. Certificates under 10 days are evaluated the same way but only best-effort: rely on your ACME client's own failure alerts for those.

3. The certificate history

Every public certificate is logged in Certificate Transparency. We ask the public search at crt.sh for the domain and its subdomains, keep the last 13 months, drop duplicate entries, and group the certificates per hostname into series: certificates that replace each other. Two servers renewing on their own show up as two series.

crt.sh allows only a few requests a minute, so the history waits in a shared queue; the page shows your place. When crt.sh does not answer, we show the live results and, where possible, the currently valid certificates from Cert Spotter. That is enough to spot a renewed certificate that was never deployed, but not enough for a rhythm.

4. The renewal rhythm, and what it means later

From the last renewals of a hostname we measure how many days passed between them and how much time the old certificate had left. If renewals always came about the same time before expiry, the client probably counts from expiry. If they came at the same share of the lifetime, it counts by fraction. If they came every so many days whatever the lifetime, it is probably a fixed schedule, such as a cron job every 60 days. When every certificate had the same lifetime, these look identical, and we say so.

Then we apply that rhythm to each coming lifetime. A fixed 60-day schedule leaves 4 days with 64-day certificates and fails with 45-day ones. A client that renews at two thirds of the lifetime keeps up with all of them.

• Looks ready: the rhythm leaves enough time at that lifetime.
• Check the setting: the history cannot tell which rule your client follows, and one of the possible rules would fall short.
• Likely to fail and Will lapse: a fixed schedule that leaves too little time, or none.
• Renewed by hand: long certificates renewed at irregular times; shorter lifetimes mean more renewals a year.
• Can't tell: fewer than three certificates in the history.

These are inferences. Every verdict shows the dates it rests on under "How we know". We cannot see your renewal client, so a verdict says "looks like", never more.

What the check cannot see

• Every server behind a name. Load balancers and CDNs may send different certificates per node or region; we see the one we reach.
• Your renewal client and its settings. The rhythm is read from the outside.
• Certificates that never reach public CT logs, and the newest ones while the search's index is behind. The certificate a server sends always counts, even when the search does not list it yet.
• Uptime. If we cannot connect, we say we could not check; we never say a site is down.

Sources

Certificate Transparency search: crt.sh, operated by Sectigo, with SSLMate's Cert Spotter API as the fallback for current certificates. Renewal windows: the ACME Renewal Information endpoints of the CAs that publish them. Trust anchors: the Mozilla root store as shipped by Debian. Lifetime dates: the CA/Browser Forum's ballot SC-081v3 and Let's Encrypt's announcements.

Why our server connects to yours, and how to opt out: about our checks.