wiredepth
Run a check

Free tool · Asset discovery

Subdomain inventory + enumeration

Query public Certificate Transparency logs for every subdomain that has ever had a TLS certificate issued, then test which ones still resolve. Find forgotten dev environments and dangling CNAMEs before attackers do. No signup.

What this tool checks

We query public Certificate Transparency log aggregators for every cert that has ever been issued to any subdomain of the apex. CT logs are append-only: every cert any CA has issued since 2018 is in there. The result is a near-complete inventory of subdomains that have existed at any point in the domain's history.

Then we resolve each candidate in current DNS to surface which still have live A / AAAA / CNAME records, and which are cert-only ghosts (issued cert, no current DNS). The live ones are your current attack surface; the ghosts are interesting for historical inventory and abandoned-asset detection.

Cert issuance volume is also a signal - a subdomain with 50 certs over 6 years is a long-running production system; a subdomain with 1 cert from 2 years ago is probably an abandoned dev box.

How to read the results

Live with active records: legitimate current assets. Make sure they're inventoried in your asset register.

Live with CNAME to dead resource: subdomain takeover risk. The CNAME points to an external service (S3 bucket, Heroku app, GitHub Pages site) that has been deprovisioned but the CNAME wasn't cleaned up. Anyone who re-registers the target name now controls your subdomain. Highest-priority finding to act on.

NXDOMAIN with historical certs: subdomain existed at some point, doesn't anymore. Useful for historical inventory and post-incident "what did we used to expose" audits.

Frequently asked questions

Is enumerating subdomains via CT logs legal?

Yes - CT logs are public by design (RFC 6962). They exist precisely so anyone can audit which certs have been issued. Major CAs are required to log every cert they issue.

Why does this find subdomains I don't see in DNS?

Two reasons: (1) the subdomain existed historically and was deleted - DNS forgets, CT logs don't. (2) Wildcard certs cover names that may not have explicit DNS records - for example a *.acme.com cert covers names that resolve via wildcard A records.

What about subdomains that never had a TLS cert?

CT-based enumeration misses those. Internal subdomains that never had a public cert (e.g. only behind VPN) won't appear. For full coverage you want this PLUS DNS brute-force enumeration tools (subfinder, amass) - we focus on CT because it has the lowest false-positive rate.

How is this different from Wiredepth Pro subdomain monitoring?

This tool is one-shot - you run it, you see the inventory at this moment. Pro continuously monitors CT logs in real-time (sub-10-second alerts) for any new cert issued for any subdomain of your monitored apex. New subdomain showing up is a regression alert.

My company uses wildcard certs - does this still work?

Wildcards show as *.acme.com in CT logs. We surface them but can't enumerate the specific subdomains the wildcard covers - by design. For wildcard-heavy domains the Pro real-time CT stream is more useful since it picks up specific subdomain certs as they're issued (which most teams use even when a wildcard is available).

Related free tools

DNS health checker

DNSSEC, CAA, NS, MX, expiry, blacklists.

TLS / SSL checker

Cert validity, chain, protocols, HSTS.

Domain reputation + threat intel

Malware feeds, IP abuse, blocklists.

Visual infrastructure map

NS / MX / SPF / DKIM dependency graph.