In 2011, a Dutch Certificate Authority called DigiNotar was compromised. The attackers issued fraudulent certificates for google.com, yahoo.com, and dozens of other domains — used to intercept Gmail traffic of Iranian dissidents. The certificates were technically valid (signed by a trusted CA) and undetectable by normal validation.
Certificate Transparency (CT) was created to ensure this can never happen undetected again. Every publicly-trusted TLS certificate must now be logged in public, append-only, cryptographically-verifiable logs before browsers accept it. If a rogue CA issues a certificate for your domain, it appears in CT logs — and you can detect it.
How Certificate Transparency Works
The System
CT consists of three components:
1. CT Logs — append-only, publicly-auditable databases of certificates. Operated by Google, Cloudflare, DigiCert, Sectigo, and others. Anyone can query them.
2. Signed Certificate Timestamps (SCTs) — proof that a certificate was submitted to a log. The log returns an SCT (a signed promise to include the certificate within 24 hours). Browsers require SCTs.
3. Monitors — services that watch CT logs for certificates matching specific domains. Alert domain owners when unexpected certificates appear.
The Flow
1. CA issues certificate for example.com
2. CA submits certificate to 2+ CT logs (before or during issuance)
3. Each CT log returns an SCT (signed timestamp proving submission)
4. CA embeds SCTs in the certificate (X.509 extension)
5. Server presents certificate + SCTs to browser during TLS handshake
6. Browser verifies: certificate valid AND SCTs present from required number of logs
7. If SCTs missing or invalid → browser rejects the certificate
Meanwhile:
8. Domain owner monitors CT logs for certificates matching their domains
9. If unexpected certificate appears → investigate (possible compromise or mis-issuance)Browser Requirements
Chrome requires SCTs from multiple independent CT logs:
| Certificate Lifetime | Required SCTs |
|---|---|
| < 180 days | 2 SCTs from different logs |
| 180 days - 15 months | 3 SCTs |
| 15 months - 27 months | 4 SCTs |
| > 27 months | 5 SCTs |
If a certificate doesn’t have enough valid SCTs, Chrome shows a certificate error — even if the certificate is otherwise valid.
Monitoring CT Logs for Your Domains
Why Monitor
CT logs are public. Anyone can search them. This means:
- You can detect certificates issued for your domains by any CA
- You can detect unauthorized wildcard certificates
- You can find certificates for subdomains you didn’t know existed
- You can identify shadow IT (teams getting certificates without going through proper channels)
How to Monitor
Option 1: crt.sh (Manual/API)
# Search for all certificates ever issued for your domain
curl -s "https://crt.sh/?q=example.com&output=json" | \
jq '.[] | {id, issuer_name, not_before, not_after, common_name}'
# Include subdomains
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq lengthOption 2: Certspotter (Automated monitoring)
# SSLMate's Certspotter monitors CT logs and alerts on new certificates
# Free tier: 1 domain, email alerts
# API:
curl "https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true"Option 3: Google Certificate Transparency Search
https://transparencyreport.google.com/https/certificates
# Search by domain, view all logged certificatesOption 4: Self-hosted monitoring (certstream)
# Real-time CT log stream (all certificates, all domains)
import certstream
def callback(message, context):
if message['message_type'] == 'certificate_update':
domains = message['data']['leaf_cert']['all_domains']
for domain in domains:
if 'example.com' in domain:
print(f"ALERT: Certificate issued for {domain}")
# Send alert to Slack/PagerDuty
certstream.listen_for_events(callback, url='wss://certstream.calidog.io/')What to Alert On
| Event | Severity | Action |
|---|---|---|
| Certificate from unexpected CA | HIGH | Investigate — possible compromise or policy violation |
| Certificate for unknown subdomain | MEDIUM | Verify — shadow IT or attacker reconnaissance |
| Wildcard certificate you didn’t request | CRITICAL | Investigate immediately — possible domain hijack |
| Certificate with unusual validity period | LOW | Review — may indicate misconfiguration |
| Pre-certificate without corresponding final cert | LOW | Normal (CA may have rejected after logging) |
CT Logs as a Reconnaissance Tool
CT logs are a double-edged sword. They protect domain owners, but they also reveal information:
What Attackers Learn from CT Logs
# Find all subdomains for a target (reconnaissance)
curl -s "https://crt.sh/?q=%.target.com&output=json" | \
jq -r '.[].common_name' | sort -u
# Reveals:
# internal-api.target.com
# staging.target.com
# dev-portal.target.com
# vpn.target.com
# admin.target.com
# jenkins.target.comEvery certificate you request for a subdomain reveals that subdomain exists — even if it’s not in public DNS.
Mitigation
- Use private CA for internal services — private CA certificates aren’t submitted to CT logs
- Only request public certificates for genuinely public services
- Use generic names for internal services if you must use public certificates (though this reduces the certificate’s utility)
CT and CAA Records: Defense in Depth
CT detects unauthorized certificates after issuance. CAA (Certificate Authority Authorization) DNS records prevent unauthorized issuance:
; Only Let's Encrypt and DigiCert can issue for this domain
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issuewild "letsencrypt.org"
; Report violations
example.com. IN CAA 0 iodef "mailto:security@example.com"CAA: Prevention (CA must check before issuing — if not authorized, issuance is blocked) CT: Detection (if a CA ignores CAA or is compromised, the certificate still appears in CT logs)
Use both. CAA prevents most unauthorized issuance. CT catches anything that slips through.
CT Log Ecosystem
Major CT Log Operators
| Operator | Logs | Notes |
|---|---|---|
| Argon, Xenon, Icarus, Pilot, etc. | Largest operator, runs Chrome CT policy | |
| Cloudflare | Nimbus | High-availability, fast |
| DigiCert | Yeti, Nessie | CA-operated logs |
| Sectigo | Mammoth, Sabre | CA-operated logs |
| Let’s Encrypt | Oak | Operated by ISRG |
| TrustAsia | Multiple | Regional (Asia-Pacific) |
Log Lifecycle
CT logs have a lifecycle:
- Pending — new log, not yet trusted by browsers
- Qualified — accepted by Chrome, SCTs are valid
- Read-only — no longer accepting new certificates, but SCTs remain valid
- Retired — removed from trust, SCTs no longer accepted
If a log is retired and your certificate only has SCTs from that log, browsers may reject it. This is why CAs embed SCTs from multiple independent logs.
Practical Implementation
For Website Operators
You don’t need to do anything for CT compliance. Your CA handles CT log submission and SCT embedding automatically. Every publicly-trusted CA has been doing this since 2018 (Chrome requirement).
What you SHOULD do:
- Set up CT monitoring for your domains (Certspotter, crt.sh alerts, or custom)
- Configure CAA DNS records (restrict which CAs can issue for you)
- Review CT logs periodically for unexpected certificates
- Investigate any certificate you didn’t request
For CA Operators (Private CA)
Private CA certificates don’t need CT logging (they’re not publicly trusted). But you CAN submit to CT logs voluntarily for transparency within your organization.
For Security Teams
CT logs are an intelligence source:
- Monitor your domains for unauthorized certificates
- Monitor competitor domains for infrastructure changes
- Detect phishing domains (certificates for
examp1e.comorexample-login.com) - Track CA behavior (which CAs issue for your domains, how often)
FAQ
Q: Can I opt out of Certificate Transparency? A: No. All publicly-trusted certificates must be logged. If a CA issues a certificate without CT logging, Chrome rejects it. There’s no opt-out for public certificates. (Private CA certificates are not subject to CT requirements.)
Q: Does CT reveal my internal infrastructure? A: Only if you request publicly-trusted certificates for internal services. Use a private CA for internal services — those certificates aren’t logged. Only request public certificates for genuinely public-facing services.
Q: What if I find an unauthorized certificate for my domain in CT logs? A: 1) Verify it’s actually unauthorized (not requested by another team). 2) Contact the issuing CA to request revocation. 3) Check your DNS for compromise (attacker may have passed domain validation). 4) Review CAA records and tighten them. 5) Investigate how the attacker proved domain control.
Q: How quickly do certificates appear in CT logs? A: The Maximum Merge Delay (MMD) is typically 24 hours — meaning the log promises to include the certificate within 24 hours of issuing the SCT. In practice, most logs include certificates within minutes.
Q: Did CT replace certificate pinning? A: Effectively, yes. HTTP Public Key Pinning (HPKP) was deprecated by Chrome in 2018 because misconfiguration caused self-denial-of-service. CT provides the same benefit (detecting unauthorized certificates) without the operational risk of pinning. CT + CAA is the modern replacement for HPKP.