Certificate transparency and DNS history for recon

Every TLS certificate a public CA issues is written to public certificate transparency logs, usually called CT logs. The names on those certificates, including internal-looking subdomains, are searchable by anyone. Pair CT with DNS history, the record of what a name pointed to over time, and you can map a target's infrastructure without sending it a request. The NotHoly chat helps correlate the pieces: same IP, same certificate, same pattern.

#Query CT logs with crt.sh

crt.sh is a web front end to the CT logs, and it also speaks JSON, so you can script it.

curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' | anew ct.txt

The %25 is a URL-encoded percent, the SQL wildcard, so this returns every name seen on a certificate under example.com. Some lines come back as wildcard entries like a leading star-dot; keep or strip them as you prefer. CT often reveals hosts that never show up in DNS brute force or crawling, because the certificate was issued before the host went live.

#Read what a certificate ties together

A single certificate can list many names in its subject alternative name field, the SAN. When a dev, a staging and an admin host share one certificate, they usually share a deployment. Pull the SAN set for a host directly.

echo | openssl s_client -connect api.example.com:443 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

The names printed next to your host are strong leads. They are in scope only if they sit under roots you are allowed to test, so check each against your scope sheet.

#Add DNS history

A name's current record is one snapshot. DNS history shows the IPs and mail servers it used before, which can expose an origin behind a CDN or an old server still running. Passive DNS providers keep this data and many have a free tier. Resolve the current records yourself with dnsx.

dnsx -l ct.txt -a -resp -silent -o resolved.txt

Compare today's IPs with the historical set. An IP that the CDN no longer fronts, but that still answers, is worth a careful and in-scope look, because it can be the origin the CDN was meant to hide.

#Correlate with the chat

Paste the certificate names, the resolved IPs and any history into the NotHoly chat.

Here are hosts, their current IPs, and historical IPs.
Cluster them by shared IP and shared certificate, flag any
origin IP that sits outside the CDN ranges, and list the
infrastructure groups you can infer. Note what is uncertain.

The model groups the records and names its uncertainty, which keeps you from over-reading a coincidence. Confirm each group against your own resolution before you treat it as fact, since historical data can be stale.

#Scope and privacy

CT and DNS history are public, but the hosts they reveal are not all yours to touch. A certificate can name a shared platform or a partner, so keep only the names under the roots you are allowed to test. Finding an origin IP does not widen your scope; if it is out of scope, you note it and stop.

#Frequently asked questions

#Can I find subdomains that DNS brute force misses?

Yes. CT shows names from certificates that were issued but may never have had a public DNS record, or that were later removed from DNS. It is one of the highest-yield passive sources, which is why it sits early in recon.

#Is querying crt.sh passive?

Querying crt.sh touches crt.sh, not your target, so it is passive with respect to the target. Resolving those names with dnsx does send DNS queries, so treat that step as light active work and keep it in scope.

CT and DNS give you infrastructure; the next source is code. Move on to GitHub and code search recon. Back to crawling and URL harvesting.