Dr.Who
← blog

How to detect unauthorized TLS certificates for your domain (CT logs)

· certificate-transparency · tls · ssl · ct-logs · mis-issuance

certificate-transparencytlssslct-logsmis-issuance

Every certificate a publicly-trusted CA issues is recorded in Certificate Transparency (CT) logs — public, append-only, cryptographically-verifiable ledgers that browsers require certificates to appear in. That makes detection straightforward: search a CT aggregator like crt.sh for your domain to see every certificate ever issued for it, then set up ongoing monitoring so any new certificate you didn't request triggers an alert. An unexpected certificate is a strong signal of mis-issuance, a compromised CA account, or shadow IT.

What Certificate Transparency actually is

CT (defined in RFC 6962) was built after CA breaches where attackers obtained valid certificates for domains like google.com and nobody noticed for weeks. The fix: make issuance public. When a CA issues a certificate, it submits it to one or more CT logs and gets back a Signed Certificate Timestamp (SCT) — a signed promise that the log will include it. Chrome and Safari refuse to trust a certificate that doesn't carry valid SCTs.

The consequence that matters to you: if a certificate works in a browser, it is in the logs, and you can find it.

How to search the logs

The fastest manual check is crt.sh, which indexes the major logs. Query by domain, including a wildcard to catch subdomains:

https://crt.sh/?q=%25.example.com&output=json

Or from the command line:

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

That %25 is a URL-encoded %, the wildcard crt.sh uses. The result is every name on every certificate ever logged for the domain and its subdomains. Read it like an inventory.

What to look for

Three patterns are worth investigating:

  • Issuing CAs you don't use. If you buy from one CA and a certificate appears from another, ask why. The crt.sh "Issuer Name" column tells you.
  • Subdomains you don't recognize. vpn-old.example.com or staging.example.com showing up often means forgotten or rogue infrastructure — shadow IT issuing its own certs.
  • Wildcard certificates you never requested. A *.example.com you can't account for is the highest-severity finding; one mis-issued wildcard covers your entire namespace.

How to respond and prevent recurrence

When you find an unauthorized certificate, identify who requested it — the issuing CA can tell you which account or ACME order produced it. If it is genuinely unauthorized, request revocation and rotate any credentials that could have been used.

Then close the door. Publish a CAA record so only your approved CAs are even allowed to issue:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:[email protected]"

CT monitoring is detective — it tells you after the fact. CAA is preventive — it stops the issuance up front. Run both. CAA narrows who can issue; CT alerts you when something gets through anyway (a CA bug, a compromised account that uses an allowed CA). Neither replaces the other.

Run the CT-log check on your domain →

Further reading