Datahorses

Certificate Transparency logs: what they reveal about your domains

By · · 4 min read

Certificate Transparency (CT) is a system of append-only logs that record TLS certificates as certificate authorities issue them. Anyone can read these logs. For your company, that means 2 things: the logs show everyone which hostnames you have certificates for, and they let you notice a certificate for your domain that nobody on your side asked for.

The protocol was first described in RFC 6962 (June 2013) and updated as version 2.0 in RFC 9162 (December 2021). Both are Experimental RFCs, but browsers rely on CT in practice: Chrome requires publicly trusted TLS certificates to be CT compliant, and Apple has its own CT policy for its platforms.

So if a browser trusts a certificate for yourcompany.com, there is almost certainly a log entry for it.

What the logs reveal about your company

A CT entry contains the names the certificate covers, the issuing authority and the validity dates. Put together, the entries for your domain show:

  • Your subdomains. vpn.yourcompany.com, jira.yourcompany.com, staging-api.yourcompany.com: every name that ever had its own certificate.
  • Your vendors. Issuers and naming patterns often hint at which hosting, mail or SaaS platforms you use.
  • Your history. Old entries stay in the log, so names from projects shut down years ago remain visible.
  • New certificates as they appear. A new entry for a name you do not recognize, or from an authority you do not use, is worth a question.

None of this is a flaw in CT. The point of the system is that misissued certificates cannot stay hidden. The consequence is that your list of hostnames is not private, so it is better that you read it before anyone else does.

How to search the logs yourself

The easiest way is crt.sh, a search interface for CT logs. Type your domain, or use % as a wildcard to include every subdomain:

https://crt.sh/?q=%25.yourcompany.com

For a list you can process, add &output=json:

curl -s 'https://crt.sh/?q=%25.yourcompany.com&output=json' \
  | jq -r '.[].name_value' | sort -u

When you read the results, look for:

  • Names nobody recognizes. Each one should map to a system with a known owner.
  • Test and staging names such as dev, test, old, beta. These often point to forgotten staging servers.
  • Names that no longer resolve or that point to a platform you left. Check them for dangling DNS and subdomain takeover.
  • Unexpected issuers. A certificate from an authority you have never used deserves a check with the team that runs your DNS and hosting.
  • Recent dates you cannot explain. A fresh certificate for your main login hostname that nobody requested is the most urgent case.

Keep in mind that wildcard certificates (*.yourcompany.com) do not list individual subdomains, so the logs show you a lot, but not everything.

Limit who can issue: the CAA record

You can tell certificate authorities which of them may issue for your domain with a CAA record, defined in RFC 8659. Authorities check it before issuing. A typical setup:

yourcompany.com.  CAA 0 issue "letsencrypt.org"
yourcompany.com.  CAA 0 issuewild ";"
yourcompany.com.  CAA 0 iodef "mailto:security@yourcompany.com"

This allows one authority, forbids wildcard certificates and gives an address for reports. CAA does not replace CT: it reduces what can be issued, while CT shows you what actually was issued.

Certificates are getting shorter, so logs get busier

Under CA/Browser Forum ballot SC-081, now part of the Baseline Requirements, the maximum validity of public TLS certificates is 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027, and from 15 March 2029 only 47. Renewals will be more frequent and mostly automated, so your domains will produce more CT entries. That makes manual reading less practical and a clear baseline of "expected" certificates more useful. For the renewal side of this change, see why certificate expiration still takes websites down.

What to do when you find something unexpected

  1. Identify the owner. Ask IT, marketing and your agencies whether they requested the certificate.
  2. If nobody did, contact the issuing authority. Each publishes a way to report misissued certificates and request revocation.
  3. Check your DNS and registrar. An unexpected certificate can follow a DNS change, so review the points in our article on nameserver and registrar changes.
  4. Add or tighten CAA so the same authority cannot issue again without your consent.

A short checklist

  • Search crt.sh for %.yourcompany.com and save the list of names.
  • Match every name to a system and an owner.
  • Remove or fix names that point to nothing.
  • Publish a CAA record naming the authorities you use.
  • Review new entries regularly, not once a year.

Where Datahorses fits

Datahorses watches your company from the outside every day, and Certificate Transparency is one of the things it reads for you: new certificates issued for your domains, new subdomains, and the CAA records that should limit them. We do not enter your systems and need no access. When something looks wrong, you get the finding with clear steps, as described in what happens when we find something. The full list of what we guard is on the home page.

More articles

All articles