mine certificate transparency logs for hidden subdomains

every certificate you've ever issued is public record

here's something a lot of people don't fully clock until it bites them: every time you or your hosting provider issues an https certificate, it gets logged permanently in something called certificate transparency, or ct. it's a public, append-only ledger that browsers actually require certs to be logged in before they'll trust them. great for stopping fraudulent certs. also great for anyone, good or bad, who wants a map of every subdomain your organization has ever spun up.

that staging server nobody remembers. the internal admin panel someone "temporarily" put on a public dns record in 2019. the vpn gateway with a cert that gives away its exact hostname. it's all sitting in ct logs, searchable, forever.

the command, broken down

curl -s 'https://crt.sh/?q=example.com&output=json' | jq -r '.[].name_value' | sort -u | head

curl -s quietly grabs data from crt.sh, a free public search interface for ct logs. no login, no api key, nothing to hide behind.

?q=example.com&output=json asks crt.sh for every logged certificate that matches example.com and hands the results back as structured json instead of an html page, which makes it way easier to parse.

jq -r '.[].name_value' digs through that json and pulls out just the "name_value" field from every entry, which is the actual hostname (or hostnames) baked into each certificate.

sort -u sorts the list alphabetically and strips duplicates, because the same subdomain often shows up across dozens of renewed or reissued certs.

head just trims the output so you're not scrolling forever. drop it if you want the full list.

why this matters for defenders

this isn't a "hacking tool," it's a reconnaissance technique, and reconnaissance runs both directions. if someone can run this against your domain in ten seconds and see every subdomain you've ever exposed, you should be running it against yourself first. this is literally how attackers build their initial target list before they've touched anything else. you want to know what they'll see before they see it.

what you'll actually find when you run this on yourself

expect surprises. run it against your own domain and you'll likely turn up dev, staging, or test subdomains that were supposed to be temporary. old vendor integrations or marketing microsites that got a cert years ago and never got decommissioned. internal tool names accidentally exposed through a public-facing cert instead of an internal ca. wildcard cert usage that reveals naming conventions, which helps an attacker guess at other subdomains you haven't even issued certs for yet.

none of this is a vulnerability by itself. it's an inventory problem. you can't secure what you don't know exists, and this command is one of the fastest ways to build that inventory from the outside in.

how to actually close the gap

run the search against your own domains on a schedule, not just once. attackers don't check once either.

for every subdomain that shows up, ask: is this still supposed to exist? if not, kill the dns record and revoke the certificate rather than just letting it expire quietly.

for internal-only services, stop issuing publicly logged certs for them. use an internal certificate authority or a private ca through your cloud provider so those hostnames never hit a public ct log in the first place.

consider setting up ct log monitoring, there are free and paid services that will alert you the moment a new certificate is issued for your domain, so you find out about shadow it or unauthorized certs immediately instead of during an incident.

tighten naming conventions. if your subdomains follow an obvious pattern, an attacker doesn't even need ct logs, they just need a wordlist. mix it up or gate discovery behind something other than "guessable name plus your domain."

the takeaway

certificate transparency isn't going away and honestly it shouldn't, it's a genuinely good security mechanism. but it means your attack surface is more public than you think. run this search against your own domain today, clean up what you find, and put a recurring reminder on your calendar to do it again. the ledger's permanent. your response to it doesn't have to be an afterthought.