How subdomain discovery via Certificate Transparency works
Every time a website enables HTTPS, its Certificate Authority is required to publish that certificate to public, append-only Certificate Transparency (CT) logs. Because a certificate has to name the exact host it protects, those logs quietly become a record of hostnames — including subdomains that were never linked from anywhere, never appeared in a sitemap, and were never meant to be found: dev.example.com, staging.example.com, admin.example.com, internal tools, forgotten test environments.
This tool queries those logs for your target domain, extracts every hostname ending in that domain, and then resolves each one over DNS to tell you which are currently live (they answer with an IP address) and which are dormant. The result is a fast, passive map of the domain's certificate-issued footprint — the standard first move in reconnaissance, bug bounty, and attack-surface assessment.
Why this matters for security work
Organizations rarely run a single host. They stand up subdomains for staging, admin panels, VPN gateways, developer tools, APIs, and marketing microsites — and each one is a potential entry point. The main website might be hardened, but a forgotten old-dev.example.com running outdated software is exactly the kind of soft target that recon is meant to surface. Standard WHOIS tells you who registered the root domain; it says nothing about this sprawling, often-neglected periphery. CT-based enumeration is how you find it.
The live/dead status matters because a hostname in a CT log isn't necessarily still active — certificates outlive the services they protected. Resolving each subdomain separates the currently-reachable hosts (worth investigating now) from the historical ones (context, but not live targets).
What this finds — and what it honestly misses
This is important, because a subdomain list that looks complete but isn't can mislead. This tool finds subdomains that have had a publicly-logged TLS certificate. That's a large and valuable slice — in the Let's Encrypt era, most public-facing hosts get one. But it is not exhaustive, and a thorough assessment combines it with other methods:
It misses subdomains hidden behind a wildcard certificate (a *.example.com cert covers secret.example.com without logging the specific name), hosts that only ever used a private/internal CA, and any subdomain that never had a certificate at all. It also can't see subdomains discoverable only through brute-force wordlist guessing, passive DNS databases, or crawling the site's own links. So treat this as a strong, fast first pass — the subdomains it shows are real, but the absence of a subdomain here is not proof it doesn't exist. Serious recon pairs CT enumeration with DNS brute-forcing and passive-DNS sources for fuller coverage.
Using this responsibly
Certificate Transparency data is public by design — querying it is legitimate and expected, and this tool only reads already-public records. But what you do with the results carries responsibility. Enumerate and assess only domains you own or are explicitly authorized to test. Subdomain discovery is a normal part of security research, bug bounty programs, and asset inventory; using it against systems you have no authorization to probe is not. If you find a vulnerability through this kind of recon, follow responsible-disclosure practices.