Finding subdomains through certificate logs

Since 2018 browsers have required publicly trusted certificates to be recorded in Certificate Transparency logs, append-only public ledgers run by several organisations. The purpose is to let site owners spot certificates issued for their names without permission. A side effect is that every host name that has ever had a certificate is searchable by anyone.

What a search shows

Querying the logs for *.example.co.uk returns each host name on a certificate, when it was first seen and who issued it: www, mail, shop, but also staging, test2019, old-crm and the names of services that were tried once. Wildcard certificates hide the names beneath them, so a *.example.co.uk entry means there may be more hosts than the list shows.

Why it matters

• Attack surface. Forgotten hosts run forgotten software. A staging server from four years ago with a known vulnerability is the classic way in.
• Dangling records. A name that still resolves to a cloud service, CDN or SaaS platform you stopped paying for can often be claimed by someone else at that provider, giving them a page under your domain. The subdomain finder checks which names still resolve so these stand out.
• Inventory. For an organisation that has grown by acquisition, the logs are frequently the most complete list of its own hosts.

What to do with the list

Walk the names that still resolve and confirm each is wanted and patched. Remove DNS records for anything retired, particularly CNAMEs to third-party platforms. Consider whether certificates with long lists of names are leaking internal naming; a wildcard certificate avoids that at the cost of a larger blast radius if the key leaks.

Limits

The logs record names from certificates only. Hosts that never had a public certificate, or that live behind a wildcard, do not appear. Results come from crt.sh, which can be slow or rate-limited at busy times.