Certificate log search

Q: How do I keep internal hostnames out of the logs?

Use a wildcard certificate, which logs only *.example.com , or issue internal certificates from a private authority that your own devices trust. In public certificates, stay away from descriptive names such as vpn-admin or the name of a product you haven’t released.

Each time a certificate is issued for one of your hostnames, it goes into a public ledger anyone can read. This search reads that ledger for a domain, lists the names it exposes and tests the newest ones in DNS.

A ledger anyone can read

A TLS certificate is issued by a certificate authority (CA), and a browser trusts any certificate signed by any of the hundred or so authorities on its list. For years, that meant one careless or compromised authority could issue a valid certificate for your bank’s domain without anybody noticing.

Certificate Transparency (CT) closes that gap. Authorities have to submit every certificate to append-only public logs, and since April 2018 Chrome rejects certificates that carry no proof of logging. Safari applies the same rule. The logs are run by companies such as Google, Cloudflare, DigiCert, Sectigo and Let’s Encrypt, and anyone can search them.

For you, this cuts both ways. You get to see every certificate ever issued for your domain, including the ones you never asked for. So does everyone else, along with each hostname written in those certificates.

What the search does with the log

We query crt.sh, a public index of the CT logs, for the registered domain and everything beneath it. Results are kept for one hour. Then we go through them like this:

Certificates are counted once. Each issuance appears twice in the logs, as a pre-certificate and as the final certificate. Entries with the same issuer and serial number are merged.
Subdomains are collected from the names in each certificate and sorted by the date of their most recent certificate. Wildcards such as *.example.com are listed apart.
The 40 most recent names are resolved in DNS to see whether they still lead somewhere.
Issuers are tallied, in total and for the last 90 days, and compared with your CAA record if you publish one.

When a domain has a very long history, crt.sh returns only part of it or times out. The page tells you when that happens and falls back to certificates that are still valid.

Dangling CNAMEs and subdomain takeover

Say status.example.com was once a CNAME to example.herokuapp.com. Somebody deleted the app and forgot the DNS record. The alias now points at a name that’s free to claim, and anyone who creates an app with that name on the same platform receives the traffic for your subdomain. From there they can serve a login page under your domain and get a valid certificate for it.

The status column shows what DNS says today.

Resolves: The name has an address. Nothing to do.
Target gone (red): A CNAME to a platform known to let people reuse abandoned names, such as GitHub Pages, Heroku, Azure, Amazon S3, Netlify or Shopify, and the target returns NXDOMAIN. Treat it as urgent.
Target gone (amber): Same situation at a service we don’t recognize.
Gone / No address: The subdomain itself no longer exists. It’s harmless, though its name stays in the logs.

The repair takes one step. Delete the CNAME record, or recreate the resource on the platform if you still need the subdomain. And from now on, make “remove the DNS record” part of closing any hosted service.

Reading the issuer table

Most domains show one or two authorities. Let’s Encrypt and Google Trust Services come up a lot because hosts and CDNs request certificates from them automatically. An issuer gets marked Unusual in two cases. Either it issued in the last 90 days and is absent from your CAA record, or you have no CAA record and it accounts for at most two certificates on a domain that has ten or more.

Unusual doesn’t mean hostile. Turning on a CDN, a site builder or a new landing page tool often brings a new authority along. Ask whoever manages those services. If nobody can explain the certificate, find its serial number through the crt.sh link in the last table and ask that authority to revoke it.

To restrict who can issue from now on, publish CAA records naming only the authorities you use:

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issue "pki.goog"

Only 40 names are tested, and only for a missing CNAME target. Some platforms can be taken over even when the target still answers, and hostnames covered by a wildcard never appear in the logs. A clean result here isn’t a full audit of your DNS zone.

Questions people ask

Can I remove a subdomain from Certificate Transparency logs?

No. The logs only accept additions, and they’re built so that a deletion would be noticed. Assume that any hostname you put in a public certificate is public for good.

How do I find all the subdomains of a domain?

CT logs are the most complete public source, because nearly every HTTPS hostname has had a certificate at some point. They miss names that only ever used a wildcard certificate and names that never served HTTPS.

Why are there hundreds of certificates for my domain?

Automated certificates last 90 days or less and get renewed about every 60 days, per hostname, and a CDN in front of the site issues its own on top. A site with five hostnames can produce more than thirty certificates a year.

How do I keep internal hostnames out of the logs?

Use a wildcard certificate, which logs only *.example.com, or issue internal certificates from a private authority that your own devices trust. In public certificates, stay away from descriptive names such as vpn-admin or the name of a product you haven’t released.

Does a certificate in the logs mean the site is live?

No. It means someone was able to prove control of that name on the day of issuance. The DNS check in the subdomain table tells you whether the name still leads anywhere.