What is Certificate Transparency (CT)
Key Takeaways
- CT requires all publicly-trusted certificates to be submitted to append-only logs before browsers accept them
- SCTs (Signed Certificate Timestamps) prove a certificate was logged — Chrome requires SCTs from multiple logs since 2018
- CT doesn't prevent mis-issuance — it makes it publicly detectable, creating accountability for CAs
- Monitor CT logs for your domains to detect unauthorized certificates issued by any of the 100+ trusted CAs
Certificate Transparency (CT) is a system of public, append-only logs that record every publicly-trusted TLS certificate issued. When a CA issues a certificate, it must submit it to multiple CT logs and receive Signed Certificate Timestamps (SCTs) proving the submission. Browsers (Chrome since April 2018) require valid SCTs before accepting a certificate. CT doesn’t prevent a rogue or compromised CA from issuing fraudulent certificates — it ensures that any such certificate is publicly visible and detectable by domain owners who monitor the logs.
Why it matters
- Detects rogue issuance — any of the ~150 trusted Root CAs can issue a certificate for any domain. CT makes every issuance visible. If a CA issues a certificate for
google.comwithout Google’s knowledge, it appears in CT logs and is detectable within hours. - CA accountability — before CT, mis-issuance could go undetected indefinitely. CT creates a public audit trail. CAs that mis-issue certificates are caught, reported, and face trust store removal.
- Domain owner monitoring — you can monitor CT logs for certificates issued for your domains. If someone obtains a certificate for
yourcompany.comfrom any CA, you’ll see it in the logs — even if you didn’t request it. - Browser enforcement — Chrome rejects certificates without valid SCTs. This makes CT compliance mandatory for all publicly-trusted CAs, not optional.
- Historical record — CT logs are append-only and cryptographically verifiable (Merkle trees). You can prove a certificate existed at a specific time, or prove that a log hasn’t been tampered with.
How it works
- CA issues certificate — during issuance, the CA submits the pre-certificate (or final certificate) to multiple CT logs.
- Log returns SCT — each CT log appends the certificate to its Merkle tree and returns a Signed Certificate Timestamp — a promise that the certificate will be incorporated into the log within the Maximum Merge Delay (typically 24 hours).
- SCT embedded in certificate — the CA embeds SCTs in the certificate as an X.509 extension (most common method), or the server delivers SCTs via TLS extension or OCSP stapling.
- Browser validates SCTs — during TLS handshake, the browser checks that the certificate has valid SCTs from the required number of independent logs (Chrome requires 2-3 depending on certificate lifetime).
- Logs are publicly queryable — anyone can search CT logs for certificates matching a domain. Services like crt.sh, Google’s CT search, and Censys index all logged certificates.
- Domain owners monitor — automated monitoring watches CT logs for new certificates matching owned domains. Alerts fire on unexpected issuance.
In real systems
Searching CT logs for your domain (crt.sh):
# Find all certificates ever issued for a domain
curl -s "https://crt.sh/?q=example.com&output=json" | \
jq '.[] | {id, issuer_name, not_before, not_after, common_name}'
# Find certificates including subdomains
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq length
# Shows total number of certificates (including wildcard, subdomain certs)CT log monitoring with certspotter:
# Monitor for new certificates (free tier available)
# API: https://sslmate.com/certspotter/
curl -s "https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true&expand=dns_names"Checking SCTs in a certificate:
# View embedded SCTs
openssl s_client -connect example.com:443 2>/dev/null | \
openssl x509 -noout -text | grep -A5 "CT Precertificate SCTs"
# Output shows:
# Signed Certificate Timestamp:
# Version : v1 (0x0)
# Log ID : 7s3QZN... (Google 'Argon2025h1' log)
# Timestamp : Mar 15 10:23:45.123 2026 UTC
# Signature : ecdsa-with-SHA256 ...CAA + CT for defense in depth:
; DNS CAA record — restrict which CAs can issue for your domain
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"CAA prevents unauthorized issuance (CAs must check before issuing). CT detects it if a CA ignores CAA or is compromised. Together they provide prevention + detection.
Where it breaks
Monitoring gap = undetected mis-issuance — CT logs contain the data, but if nobody monitors them for your domain, unauthorized certificates go unnoticed. CT is a detection mechanism, not a prevention mechanism. Without active monitoring, a fraudulent certificate for your domain sits in public logs indefinitely while being used for phishing or interception. Set up automated CT monitoring for all domains you own.
SCT from a log that later fails — CT logs can be “frozen” or removed from browser trust (if they misbehave). If a certificate’s SCTs come from logs that are later distrusted, the certificate may stop being accepted by browsers — even though the certificate itself is valid. CAs mitigate this by embedding SCTs from multiple independent logs, but certificates with SCTs from only 2 logs are vulnerable to a single log failure.
Pre-certificate vs final certificate confusion — CT logs contain pre-certificates (submitted before final issuance) and final certificates. A pre-certificate in CT logs doesn’t guarantee the final certificate was actually issued — the CA might have rejected it after logging. Monitoring tools must handle this: alert on pre-certificates (they indicate intent to issue) but don’t assume the final certificate exists until confirmed.
Operational insight
CT logs are an underused offensive reconnaissance tool. Attackers search CT logs to discover subdomains, internal hostnames accidentally included in SAN fields, staging environments, and infrastructure patterns. A certificate for internal-api.staging.yourcompany.com reveals that subdomain exists — even if it’s not in public DNS. Before requesting certificates, review what information the SANs reveal. For internal systems that don’t need public trust, use a private CA (certificates from private CAs aren’t submitted to CT logs). Only request publicly-trusted certificates for genuinely public-facing services.
Related topics
Ready to Secure Your Enterprise?
Experience how our cryptographic solutions simplify, centralize, and automate identity management for your entire organization.