Certificate Transparency (CT) - Öffentliches Zertifikat-Protokoll

Certificate Transparency solves a fundamental problem with PKI: Who verifies whether a Certificate Authority (CA) has issued a certificate for a domain? Before CT, compromised CAs (DigiNotar in 2011, Comodo in 2011) could issue certificates for any domain—such as *.google.com—without being detected. CT makes this publicly visible.

CT Architecture

Certificate Transparency Ecosystem:

Participants:
  Certificate Authorities (CAs):   DigiCert, Let's Encrypt, Sectigo, ...
  CT Log Operators:                Google, DigiCert, Sectigo (operate logs)
  Monitor/Auditor:                 Browsers, independent auditors, companies
  Domain Owners:                    Anyone monitoring certificate issuance

Certificate Issuance Process with CT:

1. CA issues a certificate for domain.de
2. CA submits the certificate to the CT log server
3. CT log responds with a Signed Certificate Timestamp (SCT)
   → SCT = cryptographic proof: "This certificate was recorded in log Y on X"
4. CA embeds SCT in certificate (or OCSP stapling or TLS extension)
5. Browser checks: Does the certificate contain a valid SCT from a known log?
   → No → Certificate is rejected! (Chrome since 2018)

Append-Only Log Structure (Merkle Tree):
  → Once entered: cannot be deleted or modified!
  → Merkle Tree Hash: any change would be detected
  → Log operators cannot cheat without being detected

Important CT logs:
  Google Argon (2024):    ct.googleapis.com/logs/us1/argon2024/
  Google Xenon (2024):    ct.googleapis.com/logs/us1/xenon2024/
  DigiCert Log Server:    ct1.digicert-ct.com/log/
  Let's Encrypt Oak:      oak.ct.letsencrypt.org/2024/
  Sectigo:                sabre.ct.comodo.com/

CT as an OSINT Tool (Subdomain Discovery)

Subdomain Discovery via Certificate Transparency:

Why CT is valuable for penetration testers:
  → EVERY public TLS certificate ends up in the CT log
  → Subdomains in SAN (Subject Alternative Names) are public!
  → New subdomains are immediately visible (even before DNS propagation)
  → Even HTTPS pages without a web presence (internal, staging) are often in CT

crt.sh - free CT search:
  # Find all certificates for *.example.com:
  https://crt.sh/?q=%25.example.com&output;=json

  # API access via curl:
  curl -s "https://crt.sh/?q=%25.example.com&output;=json" | \
    python3 -c "
  import json,sys
  data = json.load(sys.stdin)
  domains = set()
  for cert in data:
      for name in cert.get('name_value','').split('\n'):
          if name.strip():
              domains.add(name.strip().lower())
  for d in sorted(domains):
      print(d)"

  Typical findings from CT:
  → api-staging.example.com
  → admin-old.example.com
  → jenkins.internal.example.com  (used to be public!)
  → dev.example.com               (often with less security!)
  → mail2.example.com             (old mail server)

Additional CT-based OSINT tools:
  subfinder (integrates CT sources):
    subfinder -d example.com -sources certspotter,crtsh -v

  amass (multi-source):
    amass enum -d example.com -src

  certspotter (Sslmate):
    # Real-time CT monitor with API:
    https://sslmate.com/certspotter/api/v1/issuances?domain=example.com&include;_subdomains=true

  censys.io:
    # Advanced certificate search + Shodan-like features:
    censys search "parsed.names: example.com" --index=certificates

Wildcard certificates in CT:
  → *.example.com shows domain existence but not subdomains
  → Often specific subdomains alongside: api.example.com individually
  → Multi-SAN certs: one cert for 50 subdomains → all visible!

CT for Attack Surface Discovery:
  □ Find forgotten assets (old staging systems, dev endpoints)
  □ Cloud provider domains: *.s3.amazonaws.com, *.azurewebsites.net
  □ Third-party services: identify which SaaS is being used
  □ Historical certificates: Was a domain ever hosted elsewhere?

CT Monitoring for Businesses

Monitor your own domain (detect unauthorized certificates):

Scenarios to be detected:
  → Phishing domain: secure-example.com (deceptively similar!)
  → Typosquatting: exmple.com (typo in your own name)
  → Subdomain takeover: old subdomain points to a third-party server
  → Compromised CA issues a certificate for your own domain
  → Internal subdomain is accidentally made public

CertSpotter (SSLMate) - Monitoring service:
  # Free: monitor up to 5 domains
  # Alerts when a new certificate is issued for domain.com

  API integration:
  curl -s "https://api.certspotter.com/v1/issuances" \
    -H "Authorization: Bearer API_KEY" \
    --data-urlencode "domain=example.com" \
    --data-urlencode "include_subdomains=true" \
    --data-urlencode "expand=issuer,cert"

Facebook Certificate Transparency Monitor:
  → facebook.com/transparency
  → Email alerts for new certificates for your own domain
  → Free for any domains

Custom monitoring with the Go-CT library:
  # Certstream - Real-time CT log stream:
  pip install certstream
  certstream --domains example.com
  # → Immediately when a new certificate is issued

Important questions regarding CT monitoring:
  □ Which CAs are authorized for our domain?
     → Set CAA DNS record! (Certification Authority Authorization)
     → Only authorized CAs may issue certificates
  □ Are all found subdomains known?
     → Unknown subdomains = potential shadow IT or forgotten assets
  □ Are certificates renewed properly?
     → CT displays expiration date!

CAA Record (Certificate Authority Authorization):
  # Only Let's Encrypt and DigiCert allowed:
  example.com. IN CAA 0 issue "letsencrypt.org"
  example.com. IN CAA 0 issue "digicert.com"
  example.com. IN CAA 0 issuewild ";"  ← Prohibit wildcard certificates!
  example.com. IN CAA 0 iodef "mailto:security@example.com"  ← Alert email

  # Verify:
  dig CAA example.com

  → If a third-party CA issues a certificate anyway → visible in CT logs!
  → Some browsers/CAs respect CAA before issuance

Security implications

CT and Data Protection:

Public nature of CT entries:
  → ALL certificates recorded in CT logs are PUBLICLY viewable
  → Includes: Domains, subdomains, issuance date, expiration date, CA
  → Also applies to:
    - Internal subdomains (if a public CA was used!)
    - Beta/staging systems
    - VPN access points (if using a public CA)

Data protection best practices:
  □ NEVER secure internal services with a public CA
     → Instead: Private CA (company-owned PKI)
     → Private CA certificates do not end up in CT logs!
  □ Subdomain scheme should not be too revealing:
     → vpn-germany-headquarters.example.com → reveals location!
  □ Only include necessary SANs in certificates

Security of the CT logs themselves:
  → Multiple independent log operators (no single point of failure)
  → Google Chrome: List of trusted CT logs
  → Log compromise: Merkle tree inconsistency immediately detectable

SCT validation by browsers:
  Chrome:  At least 2 SCTs from different logs for DV certificates
           At least 3 SCTs for EV certificates
  Safari:  Similar requirements (Apple CT Policy)
  Firefox: Still in rollout (2024+)

Consequences of missing CT:
  → Browser displays a warning or blocks the page
  → NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
  → No legitimate certificates without CT entries are possible anymore!