Certificate Transparency Logs
debt(d7/e3/b3/t7)
Closest to 'only careful code review or runtime testing' (d7). The absence of CT log monitoring and missing CAA records are not caught by compilers, linters, or standard SAST tools. Detection requires deliberately querying crt.sh/certspotter or auditing DNS records — tools listed in detection_hints.tools — which are specialist external checks rather than part of a normal development pipeline. A rogue certificate issued silently will not surface in code review; it only becomes visible if someone actively looks.
Closest to 'simple parameterised fix' (e3). The quick_fix describes monitoring crt.sh for your domain, and adding a CAA DNS record is a single DNS change. These are low-effort operational steps but they do require setting up ongoing monitoring (not just a one-line code patch), touching DNS configuration, and potentially integrating an alerting pipeline — slightly more than e1 but well within a single component / operational scope.
Closest to 'localised tax' (b3). The applies_to scope is web contexts only. The burden is primarily operational — maintaining CT log monitoring and a CAA record — rather than a pervasive structural tax on every future code change. It doesn't shape architectural decisions broadly but does impose a recurring maintenance responsibility on whoever owns domain/TLS management.
Closest to 'serious trap' (t7). The misconception field directly states the trap: developers believe CT logs *prevent* misissuance, when they only *detect* it after the fact. This contradicts the intuitive reading of 'transparency as protection' and mirrors how other security controls (e.g. HTTPS itself) are assumed to prevent MitM — yet a rogue cert + HTTPS is undetectable without CT monitoring. The common_mistakes reinforce that this is a widely held and consequential wrong belief.
Also Known As
TL;DR
Explanation
Certificate Transparency (RFC 6962) requires CAs to log every issued certificate to public append-only logs before it can be trusted by browsers. Chrome has required CT since 2018. Benefits: detect rogue certificates (if an attacker gets a certificate for your domain from a compromised CA, CT logs reveal it), monitor your domain for unexpected certificates via crt.sh, and hold CAs accountable. CAA DNS records restrict which CAs can issue for your domain, adding a prevention layer alongside CT's detection.
Common Misconception
Why It Matters
Common Mistakes
- Not monitoring CT logs for your domain — rogue certs go unnoticed
- No CAA DNS record — any CA can issue for your domain without restriction
- Not checking CT logs when deploying new domains
- Assuming HTTPS means no MitM — a rogue cert + HTTPS interception is undetectable without CT monitoring
Code Examples
// No CT monitoring:
// 2024: attacker compromises a CA, gets cert for company.com
// CT log records it immediately — but company has no monitoring
// Attack runs for 12 months before discovered in incident response# CAA DNS record — restrict which CAs can issue:
# company.com. CAA 0 issue "letsencrypt.org"
# Only Let's Encrypt can issue for company.com
# Monitor CT logs via crt.sh API:
# curl 'https://crt.sh/?q=company.com&output=json' | jq '.[].name_value'
# Or subscribe to Cert Spotter for email alerts on new issuance