Certificate Transparency Search

What is Certificate Transparency?

Certificate Transparency is a public, append-only log of every SSL/TLS certificate issued by participating Certificate Authorities. It was created by Google in 2013 in response to a string of CA misissuance incidents — DigiNotar, Comodo, TurkTrust — where attackers managed to obtain certificates for domains they didn't own. CT makes that kind of incident detectable within minutes instead of months: every certificate the CA issues must be submitted to one or more public logs before (or shortly after) issuance, and anyone in the world can watch the logs for unexpected entries on their domains.

Since 2018, Chrome refuses to trust any certificate that isn't logged in at least two CT logs. Safari, Edge, and Firefox have similar requirements. In practice, this means every publicly-trusted certificate issued in the last several years is in CT — searchable, forever.

Why search CT logs?

• Subdomain discovery. Every certificate names the domains it covers. A certificate for staging.example.com in the logs tells you that subdomain exists, even if it isn't linked from anywhere public. This is the killer use case for security researchers, red teams, and the curious — it's how people find that abandoned admin panel, that test environment with no auth, that internal service someone forgot.
• Misissuance detection. If a CA issues a certificate for your domain to someone who isn't you, CT is how you find out. Many orgs run automated monitors against the logs (Cloudflare's "Certificate Transparency Monitoring", DigiCert's "CT Monitor", etc.) to alert on unexpected issuance.
• Auditing. Which CAs have issued certificates for your domain? Are any of them ones you don't recognise? Are there old certs that should have been revoked? The issuer breakdown answers all of that in one look.
• Wildcards. A wildcard cert for *.example.com tells you the org uses wildcard issuance — useful intel both for understanding their cert posture and for guessing valid subdomains.

What CT logs can't show you

• Domains that have never had a publicly-trusted certificate issued — HTTP-only sites, sites behind internal CAs, sites that use self-signed certs.
• Subdomains created after a wildcard cert was issued — the wildcard covers them, but the specific name never appears individually in CT.
• Domains that use Let's Encrypt's "redacted" CT submission feature with the precert poison extension — these still show up but with the leaf domain redacted to a hash.

About crt.sh

This tool queries crt.sh, the most popular public CT log search engine. It's operated by Sectigo and runs continuous ingestion against every active CT log — Google's Argon, Cloudflare's Nimbus, DigiCert's Yeti, and others. The crt.sh JSON API is the standard way to query CT programmatically; this tool wraps it with deduplication, sane sorting, expired-cert filtering, and subdomain extraction.

For audit-grade verification you'd want to query the raw CT logs directly using the RFC 6962 API. For everyday subdomain discovery and certificate inspection, crt.sh is the right level of abstraction.