TLS Certificate Transparency logs are essentially public bulletin boards for SSL/TLS certificates.
Let’s watch one in action. Imagine we’re checking for certificates issued for example.com.
# First, find a public log server. This one is run by Google.
LOG_SERVER="https://ct.googleapis.com/logs/pilot"
# Next, we need to query it for entries related to our domain.
# The API often uses a 'query' parameter. We'll look for domains.
curl -s "${LOG_SERVER}/ct/v1/search?domain=example.com" | jq .
# What we're looking for in the output are 'entries'.
# Each entry contains a 'cert' field, which is a base64 encoded certificate.
# We can decode this to see the actual certificate details.
# Let's grab the first entry's certificate and decode it:
FIRST_ENTRY=$(curl -s "${LOG_SERVER}/ct/v1/search?domain=example.com" | jq -r '.entries[0].cert')
echo "$FIRST_ENTRY" | base64 -d > example.com.cert
openssl x509 -in example.com.cert -text -noout | grep Issuer
This command sequence shows you how to pull raw certificate data from a public log. The output will reveal the issuer of the certificate, the subject (our domain), and validity dates. It’s a direct look at what Certificate Authorities (CAs) are issuing.
The core problem Certificate Transparency (CT) solves is the ability for anyone to detect misissued TLS certificates. Traditionally, domain owners had to trust their Certificate Authority (CA) to only issue certificates for domains they owned. If a CA was compromised or made a mistake, a malicious actor could get a certificate for your domain, impersonate your site, and conduct man-in-the-middle attacks. CT logs make this detection possible by creating an auditable, public record of all issued certificates.
Internally, CT works with three main components:
- Monitors: These are services that watch CT logs for new certificates. They can be run by domain owners, security researchers, or other interested parties. They scan logs for certificates issued for specific domains.
- Log Servers: These are the append-only, tamper-evident databases that store the certificates. They are run by trusted entities (like Google, Cloudflare, etc.) and are audited for consistency and correctness. When a CA issues a certificate, it must submit it to several log servers.
- Auditors: These services verify the integrity and correctness of the log servers themselves. They ensure that logs are not being tampered with and that they are consistently serving the same data to everyone.
When a CA issues a certificate, it sends it to a set of CT logs. The log server then issues a Signed Certificate Timestamp (SCT), which is a cryptographically signed promise that the certificate will be logged. The CA embeds this SCT into the certificate itself or serves it via TLS extensions. Browsers (acting as monitors) check for these SCTs when they connect to a website. If a certificate lacks a valid SCT from a trusted log, the browser will typically refuse to establish the connection, or at least warn the user. This forces CAs to log every certificate they issue, making misissuance visible.
The real power comes from setting up your own monitoring. You’re not just passively relying on browsers to catch something. You can actively query logs for certificates issued for your domains. Tools like ctfr or custom scripts can automate this.
# Example using a hypothetical monitoring tool 'ct-scanner'
# This would periodically fetch new entries from logs and alert on matches.
ct-scanner --domain example.com --log-server https://ct.googleapis.com/logs/pilot --interval 1h
This actively scans the logs for example.com. If a new certificate appears that you didn’t authorize, you get an alert before it can be widely used for attacks.
The surprising thing most people don’t realize is that the SCTs don’t prove a certificate is legitimate; they only prove it was logged. A malicious CA could still issue a certificate for your domain, get an SCT, and log it. The CT mechanism’s strength lies in the visibility it provides. It shifts the trust model from "trust the CA implicitly" to "trust that misissuance will be detected quickly." The browser’s role is critical here: it enforces the requirement for SCTs, making the logging process meaningful.
The next step in understanding CT is exploring the concept of Pre-certificates and SCT embedding.