How we check

Every publicly trusted HTTPS certificate is recorded in public Certificate Transparency (CT) logs. We read those records for your domain and look at the pattern. We never contact your server.

1. Your domain

We clean up what you type (remove https://, paths and ports, convert international names to their ASCII “punycode” form) and check it’s a public domain using the Public Suffix List. IP addresses and internal names are rejected because they don’t appear in public logs.

2. Current certificates: Cert Spotter

We ask SSLMate’s Cert Spotter API for the unexpired certificates valid for that exact name (including wildcards that cover it). It merges duplicate log entries and names the issuing CA.[SSLMate] When two of your certificates are valid at the same time, the overlap shows how long before expiry the old one was replaced, the key sign of automation.

3. History: crt.sh

Cert Spotter only returns unexpired certificates, so for the last 24 months we also ask crt.sh, which includes expired ones.[SSLMate; Sectigo (crt.sh)] crt.sh can be slow, can fail, can take days to show new certificates, and stops at about 5,000 records for very large domains, returning the oldest first. We treat any answer of 4,000 records or more as incomplete and don’t use it, and we ignore crt.sh history that is clearly older than the current certificates. When it doesn’t answer we say “history unavailable” and keep the verdict based on current certificates. We never fill the gap with a guess. If Cert Spotter is down, crt.sh is used for current certificates too. Then “expired” or “expiring soon” warnings are shown as “check” rather than “action”, because crt.sh may simply not have the newest certificate yet. If both fail you’ll see “try again later”.

4. The estimate

• Website certificates only: “Verified Mark” and “Common Mark” certificates (logos shown in email, under BIMI) also appear in the logs under your domain, but they aren’t website certificates, so we ignore them.[DigiCert]
• Renewals: a new certificate counts as a renewal when it extends coverage. Reissues inside a multi-year plan, and parallel certificates on several servers, aren’t counted.
• Looks automated: certificates are replaced well before expiry (about a quarter of the lifetime or more, or regularly at least a tenth).
• Looks manual: a certificate expired before its replacement, long certificates were replaced in the last days, or the intervals vary a lot.
• Not enough history: we can’t see enough renewals to tell.

5. The dates

We map the issuer to a CA family (11 families plus “other”). Let’s Encrypt certificates get Let’s Encrypt’s own dates (64-day certificates from February 10, 2027).[Let's Encrypt 1 (Let's Encrypt — Decreasing Certificate Lifetimes to 45 Days (Dec 2, 2025)), 2 (Let's Encrypt — 64-Day Certificate Lifetimes Coming Feb 2027 (Oct 7, 2026))] Everyone else gets the CA/Browser Forum dates, plus the CA’s own date only where the CA has published one.[CA/Browser Forum]

What we can’t see

• Internal or private certificates (not publicly trusted, so not logged).
• The certificate on your own server behind a CDN like Cloudflare. CT shows the CDN’s certificate, which may not be the one on your origin server.
• Whether a renewed certificate was actually installed and is being served.
• Your hosting company, your renewal software and its settings.
• Very new certificates in crt.sh (indexing can lag by days).

That’s why every result is labelled an estimate and links to the steps for your provider.

Privacy

Results are cached for 12 hours per domain name: public CT data only, never linked to you. To protect our shared quota, each connection can run 10 checks a minute. For that, we keep a one-way hash of your IP address and the current minute for at most two minutes. No cookies. Privacy policy.