Certificate Transparency (CT logs)

Certificate Transparency is a set of public, append-only logs in which certificate authorities record every publicly trusted certificate.

How it works

Certificate Transparency (RFC 6962) requires certificate authorities to submit every publicly trusted certificate to public logs that can only be appended to. The log returns a signed timestamp (SCT) that ships with the certificate. Chrome and Safari reject certificates without enough valid SCTs.

Anyone can read the logs, for example through crt.sh or their own monitor. That makes it possible to see which CA issued which certificate for which hostnames and when – including subdomains that are never linked anywhere.

Because the entries are public, they also reveal internal hostnames such as staging.example.com or vpn.example.com. If that matters, cover those names with a wildcard certificate; DNS names are not secrets anyway.

Why it matters

Without someone watching the logs, a rogue certificate goes unnoticed. That is exactly how a domain takeover plays out: an attacker redirects the name servers or a DNS record, passes the CA’s domain validation and uses a genuine certificate for a phishing site or to intercept mail.

Benign cases matter too: a new issuer often means a contractor, CDN or mail provider is obtaining certificates for the domain without the agency knowing – and a CAA record added later would block that provider’s next renewal.

How to prevent it

  1. Monitor the CT logs of every client domain continuously and account for each new issuer.
  2. Publish a CAA record listing the CAs allowed to issue, plus an iodef address for reports.
  3. Document the expected subdomains so an unknown hostname in the logs stands out immediately.
  4. When an unexpected certificate appears, check DNS access, the registrar account and the name servers first, then ask the issuing CA to revoke it.
  5. Cover internal hostnames with a wildcard certificate if their names should stay out of public logs.

How DomainWarn detects it

The Certificate issuance check reads the CT logs daily (via crt.sh and DomainWarn’s own watcher that follows the logs continuously) and lists every certificate issued in the last 30 days for the domain and its subdomains. The first run sets the baseline. After that, a certificate from a previously unseen certificate authority is a warning and every newly issued certificate an event in the timeline; if it lands within 24 hours of a name server or MX change, DomainWarn reports it as critical.

Hostnames in certificates that are neither the domain, www nor a subdomain you listed as expected appear as a notice and as a suggestion for a website monitor. The discovered hostnames also feed the Subdomain takeover and Subdomain inventory checks, and the issuers of valid certificates inform the CAA record suggestions.

DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.

Monitor this domain continuously14-day free trial, no credit card.