TUTORIAL

How to Use Certificate Transparency

Monitor and verify X.509 certificates through Certificate Transparency (CT) logs to detect misissued certificates and improve trust.

Problem

A CA can misissue a certificate for your domain without your knowledge, enabling man-in-the-middle attacks. You need to use Certificate Transparency (RFC 6962) to detect unauthorized certificates and monitor for misissuance.

Prerequisites

Understanding of X.509 certificates and CA hierarchy
Familiarity with Merkle trees and inclusion proofs
Knowledge of TLS certificate validation

Steps

1. Understand the CT log architecture

Certificate Transparency logs are append-only Merkle trees of certificates. When a CA issues a certificate, it must submit it to one or more CT logs. The log returns a Signed Certificate Timestamp (SCT) — a promise that the certificate will be included in the log. Browsers require SCTs in TLS handshakes; without them, certificates are rejected. The append-only nature means once logged, a certificate cannot be hidden or removed.
Input
```
certificate issued by CA
```
Output
```
SCT: { log_id, timestamp, extensions, signature }
```
2. Verify SCTs embedded in certificates

When receiving a TLS certificate, check for embedded SCTs (in the certificate's X.509 extensions, OID 1.3.6.1.4.1.11129.2.4.2). For each SCT: verify the log's signature on the SCT, check the timestamp is within the certificate's validity period, and verify the log is trusted (in the CT log list). Use the hash tool to compute Merkle tree hashes for inclusion proofs. At least 2 SCTs from different logs are typically required.
Input
```
certificate with 3 embedded SCTs
```
Output
```
verified: 3/3 SCTs valid | logs: Google Argon, Cloudflare Nimbus, Let's Encrypt Oak
```
3. Monitor CT logs for your domains

Set up monitoring of CT logs for certificates issued for your domains. Use APIs like Google's CT search (https://transparencyreport.google.com) or crt.sh to query for certificates matching your domain. Alert on any certificate you did not request. Check periodically: query for your domain, compare against your known certificate inventory, investigate any unknown certificates immediately. Use the DNS tools to verify the domain ownership.
Input
```
domain: example.com
```
Output
```
found: 2 certificates | expected: 2 | status: OK
```
4. Respond to misissued certificates

If you detect an unauthorized certificate: (1) immediately report to the issuing CA for revocation, (2) revoke the certificate via OCSP or CRL, (3) investigate how the misissuance occurred (domain validation bypass, CA compromise), (4) consider using CAA (Certification Authority Authorization) DNS records to restrict which CAs can issue for your domain, (5) use DANE/TLSA records as an additional verification layer. Document the incident and update monitoring.
Input
```
unauthorized cert for example.com
```
Output
```
action: revoke + report CA + add CAA record
```

Expected result

Continuous monitoring of Certificate Transparency logs that detects unauthorized certificate issuance for your domains, with verified SCTs on all legitimate certificates.

Common errors

Not checking SCTs during TLS validation: Modern browsers enforce CT, but custom TLS clients may not. Verify SCT presence and validity in your TLS stack, not just certificate chain validation.
Monitoring only one CT log: Monitor multiple logs (Google, Cloudflare, Let's Encrypt) since certificates may appear in any of them. Use aggregate APIs that search across all logs.
Ignoring CAA DNS records: CAA records restrict which CAs can issue certificates for your domain. Set them to prevent unauthorized CAs from issuing, reducing misissuance risk at the source.

Troubleshooting

If your certificate is rejected for lack of SCTs, ensure your CA supports CT and submits to logs during issuance. Let's Encrypt and most modern CAs do this automatically.
For internal PKIs (not publicly trusted), CT does not apply — use private CA monitoring instead.
If monitoring produces too many false positives, filter by certificate validity period and issuer to reduce noise.

Security limits

CT detects misissuance but does not prevent it — the certificate is still valid until revoked. Response speed matters.
CT logs are public — your domain names and subdomains are visible in the logs. Do not use CT for internal/private domain names.
All certificate verification happens locally; no certificate data is sent to third parties.