Every company's web footprint grows faster than anyone tracks it. A marketing team spins up a landing page, an engineer stands up a staging box, a regional office gets its own VPN endpoint, and before long you have hostnames like api.yourcompany.com, staging.dev.yourcompany.com, and vpn.london.yourcompany.com scattered across half a dozen accounts. Nobody keeps a master list. Six months later, half of those subdomains are running software nobody has patched, and one of them is a way into your network.
The CT Subdomain Resolver helps you find those subdomains without touching the target at all. It reads public Certificate Transparency logs to pull every hostname that has ever been issued a certificate under a domain, then resolves each one to its current IP so you know what is still live.
What Certificate Transparency actually is
For years the certificate authority system ran on trust. Any trusted CA could issue a certificate for any domain, so if one of them was compromised or went rogue and issued a cert for yourbank.com, the holder could sit in the middle of encrypted traffic and nobody would notice.
Certificate Transparency, launched by Google in 2013 and specified in RFC 6962, closed that gap. Now, whenever a public CA like Let's Encrypt, DigiCert, or Sectigo issues a certificate, it has to submit that certificate to public, append-only logs. Browsers enforce this: Chrome, Safari, and Firefox reject certificates that were never logged. Because the logs are append-only and public, they form a permanent record of every certificate a public CA has issued. That was designed to catch fraudulent certificates, but it also means the logs are a searchable index of hostnames.
How the resolver uses that data
The old way to enumerate subdomains was brute force: take a wordlist of common names (admin, test, dev, portal) and hammer the DNS servers to see what resolves. That approach is slow, it lights up firewall and intrusion-detection alerts, and it never finds the oddly named hosts. Nobody guesses project-alpha-92.yourcompany.com from a wordlist.
Reading CT logs sidesteps all of that. The resolver works in three steps:
- Log scraping. You enter a root domain, and the tool queries CT log aggregators for every historical and active certificate registered under it.
- Hostname extraction. It parses the Subject Alternative Name (SAN) and Common Name (CN) fields out of those certificates, collecting every fully qualified name it finds.
- Live DNS resolution. A certificate only proves a subdomain existed when the cert was issued. So the tool then resolves each name to its current IPv4 (
A) and IPv6 (AAAA) records, so you can tell what is still online versus what is a stale entry from years ago.
You get the same picture from the other direction with the All DNS Records lookup once you know which hostnames to check, and you can trace who owns a resolved address with the IP ownership lookup when an IP lands somewhere you didn't expect.
The wildcard allowlist problem
Here is a mundane but common use. Say you need to configure an edge firewall or a secure web gateway to permit traffic only to one vendor's services, everything under *.thirdpartyvendor.com. The catch is that a lot of router and appliance ACLs don't support wildcard matching. They want explicit IP addresses or exact hostnames.
Without a list, your options are guessing or emailing the vendor and waiting. Running the vendor's domain through the resolver gives you the set of subdomains that have been issued certificates plus their resolved IPs, and you can paste those addresses straight into the allowlist. It won't be perfect (a subdomain that never got a public cert won't appear), but it is a far better starting point than a blank rule.
Finding takeovers and leaked names before someone else does
The same data is useful defensively, and this is where security teams tend to spend their time.
Subdomain takeovers. You might discover that blog.yourcompany.com still has a CNAME pointing at an S3 bucket or a GitHub Pages site that was deleted long ago. An attacker who registers that abandoned resource can serve their own content from your subdomain, which is a clean setup for phishing under your brand. Pulling the CT list and checking where each name actually points is how you catch these dangling records. A quick CNAME lookup on the suspect hostname confirms whether it's pointing at something you no longer control.
Leaked internal names. When an admin requests a certificate for an internal host like payroll-internal.yourcompany.com, the moment that cert is issued the hostname is published to CT logs for the whole world. Attackers watch CT streams precisely to find targets like that. Running the resolver against your own domain shows you what naming conventions you've inadvertently exposed, which is worth knowing before you name the next one.
Where it fits
Certificate Transparency was built to keep certificate authorities honest. The side effect is a public map of hostnames, and the resolver turns that map into something practical: a list of subdomains and the IPs they point to right now. Whether you're building a firewall allowlist without wildcard support, running reconnaissance on a pentest, or auditing what your own organization has quietly put online, start by seeing what the logs already know about you. Odds are it's more than you expect.