Find subdomains from certificate logs

How this finds hosts nobody listed

Every publicly trusted TLS certificate is written to Certificate Transparency (CT) logs: append-only public records that browsers require CAs to use. A certificate for staging.client.com issued in 2022 is still in those logs today, even if everyone forgot the host existed. Searching the logs for a domain is the most complete inventory of its HTTPS hosts you can get without access to anyone's DNS.

We query SSLMate's Cert Spotter CT search, with crt.sh as a fallback, collect every name on every certificate under the domain, remove duplicates, strip wildcard prefixes and keep the most recent expiry date for each host.

Reading the list

Hosts with a current certificate come first, soonest expiry at the top. Hosts whose most recent certificate has already expired come after, newest first.

• Expiring within 14 days (warning): if this host is live and uses automated certificates, its renewal has probably stopped.
• Expired latest certificate (critical): either the host was retired, which is fine, or it is still running and serving an expired certificate, which is not. Only a quick check tells you which.
• Hosts you don't recognise: old campaign sites, forgotten staging servers, a CMS someone tried once. These are where expired certificates and unpatched software live.

The expiry shown is the latest certificate logged for that name, not necessarily the one the server is serving right now. To see what a live host actually presents, paste it into the SSL checker, or paste a batch into the bulk SSL checker.

What it can't see

• Hosts covered only by a wildcard certificate. *.client.com shows up as client.com; the individual subdomains under it never appear in the logs.
• Hosts that never had a publicly trusted certificate: plain HTTP sites, internal hosts on a private CA.
• Anything registered under a different domain. A client's shop on another domain needs its own search.

The logs also over-report in one way: a name stays in them forever. A host that was switched off in 2021 is still listed, with a certificate that expired in 2021. That is why expired entries are sorted to the bottom and labelled rather than hidden. Most of them are harmless history; the few that still answer are the ones worth your afternoon.

Doing the same search yourself

Nothing here is secret sauce. You can search the logs directly: crt.sh takes a query such as %.example.com in its search box (the % is a wildcard), and Cert Spotter has a JSON API you can call from a script. The request below asks for every certificate covering the domain and its subdomains, with the names listed out:

curl -s "https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true&expand=dns_names"

The raw answer is one entry per certificate, not per host, and busy domains have thousands of them. The work this tool does for you is the boring part: paging through the results, collapsing duplicates, stripping wildcards, keeping only the latest certificate per host and sorting by what needs attention.

Why agencies run this on day one

When you take over a client, the handover document lists the main site. The CT logs list the main site, the old site, the landing pages from three campaigns ago, the staging copy, the webmail and the thing the previous developer set up for a trade show. Some of those still answer on the public internet. You would rather find them than have the client's customer find them.

In ExpiryOwl this search runs per client root domain, and new hosts that appear in the logs show up in your discovery list with a one-click add. For the method behind it, and how to query the logs yourself, read finding subdomains with Certificate Transparency.