Certificate Transparency
See every SSL/TLS certificate ever issued for a domain
Search the certificate transparency logs. Get the full history: issuer CA, validity dates, SAN coverage, and a list of every host the certificate protected. Faster than crt.sh direct, no waiting, no signup.
Querying certificate transparency logs…
crt.sh is rate-limited upstream. If this is intermittent, retry in a moment.
Certificate transparency: what it is and why it exists
Every TLS certificate the browser trusts is signed by a Certificate Authority — one of a few hundred organizations that the browser vendors have decided to trust by default. The browser assumes that any certificate signed by a trusted CA is legitimate. The question Certificate Transparency (CT) answers is: how do you know the CA didn't sign a certificate for your domain that you didn't ask for? If a malicious CA signs a cert for your bank and serves it to phishing victims, the browser would dutifully trust it — unless the CA also logged it to a public CT log that the bank's security team monitors.
How CT logs work
When a CA issues a certificate, it must submit a Signed Certificate Timestamp (SCT) to at least two CT logs (Chrome's requirement; Firefox is similar). The log is append-only and cryptographically signed — once a certificate is in the log, it cannot be removed or modified. The browser, when validating a certificate, checks that the certificate has valid SCTs from logs it trusts.
crt.sh is a community-run aggregator that queries all major CT logs and presents a unified view. The data is public. Anyone can search for any domain and see every certificate ever issued for it (and any subdomain that contains it as a label). SiteTrace wraps crt.sh with a clean JSON response, a 24-hour cache layer, and a UI that renders the result — no need to wait on crt.sh's slow load times.
What to look for
Three patterns matter when you review a CT history for your domain:
- Certificates you didn't request. If you see a cert for a hostname you don't own, that means someone requested it from a CA — possibly legitimately (a former employee, a CDN provider you no longer use) or possibly not (a typosquatter, a phishing operator). Investigate.
- CAs you didn't choose. Some CAs have weaker verification processes or have been compromised historically. If you only ever requested from Let's Encrypt and you see a cert from an unknown CA, that's worth flagging.
- Old certificates still in DNS. If you decommissioned a service 6 months ago but a CT log shows a cert from 8 months ago for that hostname, check that the hostname is no longer in DNS. Stale records are an attack surface.
Brand monitoring
If you operate a brand, you should monitor CT logs for typosquats and look-alike domains. The setup:
- List your brand and common typos (yourbrand.com, yourbrand.io, yourbrnad.com, etc.).
- Query each weekly against the CT logs.
- Alert on any new issuance you didn't authorize.
- File complaints or takedown requests for malicious look-alikes.
Free services exist for this: certspotter runs free monitors for personal use; Facebook has a free CT monitor for brand-protection teams; Cloudflare Registrar customers can enable certificate transparency monitoring on the dashboard.
Why CT matters for incident response
CT logs have caught real attacks. In 2019, a researcher noticed that a CT log contained a certificate for a subdomain of a major cryptocurrency service — issued by a CA that the service did not authorize. The certificate was being prepared for an active man-in-the-middle attack. Because the CT log flagged it within hours, the service was able to revoke the cert and block the attack before significant damage.
Without CT, the certificate would have been silently trusted by every browser in the world, and the attacker would have had a free pass to intercept traffic until someone noticed. CT is not perfect — a malicious CA could refuse to log, and older browsers don't enforce SCT requirements — but it raises the cost of a successful attack significantly.
Practical limits
CT logs only show certificates issued after the participating CAs began logging. For most CAs this is 2015 or later. Certificates issued before that are not in CT and won't appear here. Also: CT logs do not show private certificates (issued by internal CAs) — only public ones that went through a public CA.
For live TLS configuration testing (cipher suites, protocol versions, chain order, session resumption), use SSL Labs. For certificate history and brand monitoring, use SiteTrace.
Related SiteTrace tools: Security Headers Checker, DNS lookup, /check.
Use the API directly
The certificate transparency search is also a JSON API. Free, 50 calls/day without signup, 500/day with a free API key.
curl "https://api.sitetrace.it.com/api/certs?domain=example.com" \
-H "X-API-Key: $SITETRACE_KEY"
Returns { domain, count, certs[] } with each cert containing issuer, validity dates, SAN list, and serial. The same endpoint powers this page.