Find every subdomain with Certificate Transparency logs

What Certificate Transparency is

Certificate Transparency (CT) is a set of public, append-only logs of TLS certificates. It was first specified in RFC 6962 in June 2013 and revised as version 2.0 in RFC 9162 in 2021, which obsoletes the original. Both are Experimental RFCs, which has not stopped CT becoming load-bearing infrastructure for the whole web.

The stated purpose, in RFC 9162's words, is to log certificates "in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates." Logs are built on Merkle hash trees, so a log cannot quietly rewrite its history without that being detectable by anyone watching it.

CT was built so domain owners could spot certificates they didn't ask for. The side effect is more useful day to day: a public, searchable list of every hostname anyone has put on a publicly trusted certificate.

Why every public certificate ends up in a log

Browsers made it mandatory. Chrome's CT policy states that all publicly trusted TLS certificates must be CT compliant to validate in CT-enforcing versions of Chrome, and that certificates which aren't "will simply fail to validate." Compliance means carrying signed certificate timestamps (SCTs) from logs: for certificates with embedded SCTs, at least two from distinct logs when the certificate lasts 180 days or less, three when it lasts longer, and from at least two distinct log operators.

Apple's Certificate Transparency policy says the same thing in its own words: publicly trusted TLS server certificates that fail the policy result in a failed TLS connection. CAs log everything as a result. Let's Encrypt, for example, states on its CT logs page that it submits all certificates it issues to CT logs.

So every hostname on a public certificate is public. That includes staging.client.com, the 2021 spring campaign microsite and the test box a contractor set up on a Friday.

Searching with crt.sh

crt.sh is a free CT search site operated by Sectigo. Its advanced search offers LIKE and ILIKE matching, which is why % works as a wildcard: searching for %.example.com returns logged names under example.com. Add output=json for something a script can read. In a URL the % has to be encoded as %25:

# Every logged name under example.com, one per line
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' | sed 's/^\*\.//' | sort -u

# Only certificates that haven't expired yet
curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired'

Each result's name_value holds every name on that certificate, separated by newlines, which is why the pipeline above splits and deduplicates them. By default crt.sh includes expired certificates, and for discovery that history is the point: it shows hosts that had a certificate years ago and may still be running.

It is a free service carrying a lot of traffic. It returned 502 errors several times while we wrote this guide, so put retries and a pause into anything automated, and don't treat an empty answer as proof that nothing exists.

Searching with the Cert Spotter API

SSLMate's Cert Spotter API is tidier for current inventory. It lists unexpired issuances only, and merges the certificate and precertificate entries for one issuance event into a single object, so you don't see every certificate twice.

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

• include_subdomains=true adds issuances for names below the domain, not only the domain itself.
• match_wildcards=true also returns wildcard certificates that would cover the name you asked about.
• expand=dns_names includes the list of names on each certificate, which is the part you want.
• For more results, pass the id of the last issuance as after. An empty array means you have reached the end.
• Unauthenticated queries get a limited number per hour, and the response headers tell you how many you have left.

Wildcards hide names

A certificate for *.example.com covers one level of subdomain, but the log only records *.example.com. Any host served under that wildcard stays invisible to CT searches. Some teams use wildcards for exactly that reason. For discovery it means CT gives you a floor, not a complete list: pair it with the client's DNS zone and hosting accounts wherever you have access.

A 20-minute routine for a new client

When a client comes on board, we would run this before anyone touches their hosting. It needs a terminal, jq, and a list of the client's registered domains.

1. Run the crt.sh query for each registered domain, including old brand names and country domains the client forgot to mention.
2. Run the Cert Spotter query for the same domains to see which names have a currently valid certificate.
3. Merge both lists and resolve each name. A name that no longer resolves is history; a name that resolves is a live host until proven otherwise.
4. For each live host, note who issued its certificate and when it expires. Hosts on a CA the client doesn't use are worth a question.
5. Send the client the list with a one-line recommendation per host. It gives the client something concrete in week one, before any invoice.

What forgotten hosts mean for an agency

Run a search against a client you have had for five years. The list will contain names nobody in the room remembers. Each one falls into a few familiar types:

• Staging sites. Often a copy of production data behind a weak password, on a plugin version from the day it was cloned.
• Old campaign microsites. Built for one launch, never updated since, still answering on a CMS nobody patches.
• Dangling DNS. A CNAME pointing at a cloud resource that was deleted, which someone else may be able to claim and serve content from under your client's name.
• Live hosts nobody monitors. Still in use, still renewing by hand, and next in line to expire.

Treat the result as an inventory and make a decision per host: monitor it, decommission it (remove the DNS record, not only the server), or hand it back to the client in writing. Our free subdomain certificate finder runs the search for you, and the bulk SSL checker tells you which of the survivors are close to expiry. If you run infrastructure for many clients, our page for MSPs covers how discovery fits into onboarding, and SSL monitoring for agencies picks up from here.

A privacy note

Logs are append-only by design. Once a certificate is logged, the names on it are public for good. Before you request a certificate for acquisition-target.client.com, assume the name will be readable by anyone by the time the certificate is issued. Use a wildcard or an internal CA for names that must stay quiet.

Searching someone else's domain is reading public data, but the polite use is your own and your clients' domains. ExpiryOwl runs CT-log discovery on every domain you add, so hostnames you didn't know about show up on a dashboard rather than in an incident report.