Context
Certificate Transparency (CT) gives every domain owner a public mirror of the certificates issued in their name. We treat regular review of those logs as part of certificate lifecycle management, watching for certificates we did not request and CAs we did not pick.
The web’s Public Key Infrastructure (PKI) depends on Certificate Authorities (CAs): organizations trusted to bind a domain name to a public key in the X.509 certificate format. Mis-issuance, CA compromise, or negligence can let a forged certificate look valid to a browser while serving the wrong party. CT addresses that by requiring CAs to submit each certificate to public, append-only logs that domain owners, monitors, and user agents can query.
Chrome has required Signed Certificate Timestamps (SCTs) from approved logs for all publicly-trusted certificates since April 2018, and Apple runs a parallel policy across Safari and other Apple platforms. Without acceptable SCTs, those browsers will not treat the certificate as fully trusted for Transport Layer Security (TLS) connections.
How CT logs work
CT logs are append-only ledgers operated by independent organizations. A CA submits a precertificate to a log and receives an SCT, a signed promise to include the entry within a Maximum Merge Delay (MMD) that each log sets in its policy, typically 24 hours. The CA embeds those SCTs in the final certificate (or delivers them at handshake time via Online Certificate Status Protocol (OCSP) stapling or a TLS extension), and during the handshake the browser checks that the certificate was logged.
Logs use Merkle trees so auditors can verify consistency: new entries extend the tree without rewriting history, and proofs can show that a particular certificate was included. The mechanics matter less for day-to-day operations than the property they guarantee: a tamper-evident public record. In practice, few teams query the approved logs directly. Public and commercial indexers like crt.sh, Cert Spotter, Censys, and Merklemap live-tail those logs and index entries for search, which is how large-scale lookup becomes practical.
What certificates reveal
Each logged certificate carries structured identity data. The subject common name and Subject Alternative Name (SAN) extension list the Domain Name System (DNS) names the certificate is valid for. A single cert often names dozens of hostnames, including internal or staging names that never appeared in public DNS records. That exposure is intentional: transparency requires publishing what was issued. The same data is available to anyone enumerating a target’s footprint, so domain owners should treat their logged certificates as part of the public attack surface.
CT does not replace DNS control, firewall rules, or an internal asset inventory. It answers a narrower question: which certificates have been logged for your domain and the hostnames listed on them.
Using CT to check your domains
We start from a written baseline: approved CAs, renewal cadence, standard SAN patterns, and names that should never receive a public certificate. That baseline is what we compare each log query against.
For ad hoc checks, public aggregators are the fastest path. crt.sh indexes CT data and supports simple queries:
DOMAIN=example.com
curl -fsS "https://crt.sh/?q=${DOMAIN}&output=json" \
| jq -r '.[].name_value' \
| sort -u
Use curl -f so HTTP errors (for example 502) do not get piped into jq. If jq reports a parse error, the response was not JSON—often rate limiting, a temporary outage, or too many results for a broad wildcard query. Retry later, search the exact domain first (q=yourdomain.com), or use q=%.yourdomain.com only when you need subdomains and the result set stays small.
Respect the service’s rate limits and terms of use. The output is a set of names seen on certificates, not proof that a host is live.
When we see a delta (an unexpected issuer, a new wildcard, a look-alike name, a shorter validity period than our standard, or a SAN like staging-api.example.com for a host we retired), we open a ticket: confirm with the team that requested the cert, revoke if it is unauthorized, and update inventory if it is legitimate.
For ongoing coverage, run or subscribe to a CT monitor as described in How CT works, or use a commercial indexer with alerting. Monitors watch logs for names you care about and notify you when a new certificate appears. When a hit arrives, we confirm the hostname is in DNS and in our configuration management database before treating it as live exposure. A logged certificate means a CA issued it, not that a service is listening.
Takeaways
CT is not a defensive secret: the logs are public, anyone can query them, and the asymmetry favors operators who review them on a schedule rather than after an incident. The cost of a recurring check is small; the cost of finding an unauthorized issuer six months late is not.
Periodic CT checks belong beside renewal runbooks and revocation procedures, especially after acquisitions, large SAN changes, or incidents involving a CA.