Certificate Transparency Monitoring for CDN-Managed Domains

When a Certificate Authority issues a TLS certificate for your domain, you should know about it. If someone else obtains a valid certificate for your domain — through CA compromise, DNS hijacking, or domain validation exploitation — they can intercept your traffic without triggering browser security warnings. Certificate Transparency was designed to make this detectable. Every publicly trusted certificate must be logged in append-only, cryptographically verifiable public logs before browsers accept it. Monitoring these logs for your CDN-managed domains is how you detect unauthorized certificate issuance before it becomes an active attack. For broader certificate management at the CDN edge, see CDN SSL/TLS Optimization.

How Certificate Transparency Works

Certificate Transparency operates on a simple principle: public accountability. Before CT, certificate issuance was a private transaction between the requester and the CA. If a CA issued a fraudulent certificate, neither the domain owner nor the public could detect it until the certificate was used in an attack. CT changes this by requiring CAs to submit every certificate to one or more public log servers before issuance.

Each CT log is an append-only Merkle tree. Certificates are added as leaf nodes, and the tree's cryptographic structure ensures that entries cannot be modified or removed after insertion. Log servers return a Signed Certificate Timestamp (SCT) when they accept a certificate, and this SCT is embedded in the certificate itself or delivered during the TLS handshake. Browsers verify that certificates carry valid SCTs from multiple independent logs, ensuring that the certificate was publicly logged before it was used.

Why CDN Domains Need CT Monitoring

CDN-managed domains have a unique certificate landscape. Your CDN provider — Cloudflare, Fastly, Akamai, AWS CloudFront — issues and manages certificates on your behalf. Cloudflare, for example, uses Let's Encrypt and DigiCert to issue certificates that often cover multiple customer domains on shared SAN (Subject Alternative Name) certificates. These certificates rotate frequently: Let's Encrypt certificates expire every 90 days, and CDN providers may reissue them more frequently during infrastructure changes.

This automated certificate lifecycle creates a high volume of legitimate CT log entries for your domain. Without monitoring, you have no way to distinguish a routine CDN certificate renewal from an unauthorized certificate issued through a compromised CA or a DNS hijacking attack that passed domain validation at a different CA. The unauthorized certificate looks identical in the CT log — it is a valid, publicly trusted certificate for your domain. The only distinguishing feature is that it was issued by a CA you did not authorize.

Setting Up CT Monitoring

Several services provide CT log monitoring. CertSpotter from SSLMate monitors all major CT logs and sends alerts when new certificates are detected for your domains. Facebook's Certificate Transparency Monitoring service provides similar functionality. Google's CT search interface at transparencyreport.google.com lets you search for certificates manually but does not provide automated alerts.

# Monitor CT logs using CertSpotter API
# List all certificates for a domain
curl -s "https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true&expand=dns_names,issuer" \
  | python3 -m json.tool

# Automated monitoring script
#!/bin/bash
DOMAIN="example.com"
EXPECTED_ISSUERS=("Let's Encrypt" "DigiCert" "Cloudflare")
WEBHOOK_URL="https://hooks.slack.com/services/xxx/yyy/zzz"

# Fetch recent certificates
CERTS=$(curl -s "https://api.certspotter.com/v1/issuances?domain=${DOMAIN}&include_subdomains=true&expand=issuer")

echo "$CERTS" | python3 -c "
import json, sys
certs = json.load(sys.stdin)
expected = ${EXPECTED_ISSUERS[@]}
for cert in certs:
    issuer = cert.get('issuer', {}).get('name', 'Unknown')
    if not any(e in issuer for e in ['Encrypt', 'DigiCert', 'Cloudflare']):
        print(f'ALERT: Unexpected issuer {issuer} for {cert.get(\"dns_names\", [])}')
"

CAA Records: Preventive Control

While CT monitoring detects unauthorized certificates after issuance, CAA (Certificate Authority Authorization) DNS records prevent them from being issued in the first place. CAA records specify which CAs are authorized to issue certificates for your domain. Compliant CAs check CAA records before issuance and refuse to issue if they are not listed.

# CAA records for a domain using Cloudflare CDN
# Cloudflare uses Let's Encrypt and DigiCert
example.com.  IN  CAA  0  issue "letsencrypt.org"
example.com.  IN  CAA  0  issue "digicert.com"
example.com.  IN  CAA  0  issuewild "letsencrypt.org"
example.com.  IN  CAA  0  issuewild "digicert.com"

# Incident notification email
example.com.  IN  CAA  0  iodef "mailto:[email protected]"

# Verify CAA records
dig CAA example.com +short
# 0 issue "letsencrypt.org"
# 0 issue "digicert.com"
# 0 issuewild "letsencrypt.org"
# 0 issuewild "digicert.com"
# 0 iodef "mailto:[email protected]"

CAA and CT monitoring form a defense-in-depth pair. CAA prevents most unauthorized issuance by telling compliant CAs not to issue. CT monitoring catches the cases CAA misses: compromised CAs that ignore CAA checks, CAs that have not yet implemented CAA enforcement, and situations where an attacker modifies your DNS records to change the CAA policy before requesting a certificate.

Handling False Positives from CDN Certificate Operations

The most common challenge with CT monitoring for CDN customers is alert fatigue from legitimate certificate operations. CDN providers issue, renew, and rotate certificates frequently. Cloudflare alone may issue multiple certificates per month for an active domain due to certificate renewals, edge certificate updates, and shared SAN certificate rebalancing.

Build your monitoring allowlist around three dimensions: authorized CAs (the specific CAs your CDN provider uses), expected certificate patterns (SAN certificates that include CDN-specific hostnames like sni.cloudflaressl.com), and certificate lifecycle timing (new certificates appearing within the expected renewal window of expiring certificates). Certificates that fall outside all three dimensions warrant investigation.

Advanced Monitoring: Expect-CT and Reporting

The Expect-CT HTTP header was designed to let domain owners enforce CT compliance for their domain and receive reports when non-compliant certificates were encountered. While Chrome deprecated Expect-CT enforcement in 2023 after CT became mandatory for all publicly trusted certificates, the reporting functionality remains valuable.

# Expect-CT header with reporting (note: enforcement deprecated)
Expect-CT: max-age=86400, report-uri="https://reporting.example.com/ct"

# Modern approach: Certificate Transparency Policy in DNS
# Using CAA with reporting
example.com.  IN  CAA  0  iodef "mailto:[email protected]"
example.com.  IN  CAA  128 contactemail "[email protected]"

For CDN-managed domains, configure your CDN provider's certificate monitoring features alongside external CT monitoring. Cloudflare provides Certificate Transparency Monitoring in the SSL/TLS dashboard. AWS Certificate Manager sends SNS notifications for certificate events. Using both CDN-native and external monitoring ensures you detect unauthorized certificates regardless of whether the CDN provider's monitoring has coverage gaps. See CDN Security Headers for complete header configuration including HSTS, which prevents downgrade attacks that bypass certificate validation entirely.