Certificate Transparency (CT) - Öffentliches Zertifikat-Protokoll

Certificate Transparency löst ein fundamentales Problem der PKI: Wer prüft, ob eine Certificate Authority (CA) ein Zertifikat für eine Domain ausgestellt hat? Vor CT konnten kompromittierte CAs (DigiNotar 2011, Comodo 2011) unbemerkt Zertifikate für beliebige Domains ausstellen - z.B. *.google.com. CT macht dies öffentlich sichtbar.

CT-Architektur

Certificate Transparency Ökosystem:

Teilnehmer:
  Certificate Authorities (CAs):   DigiCert, Let's Encrypt, Sectigo, ...
  CT-Log-Betreiber:                Google, DigiCert, Sectigo (betreiben Logs)
  Monitor/Auditor:                 Browser, unabhängige Prüfer, Unternehmen
  Domain-Owner:                    Jeder der Zertifikats-Ausstellungen beobachtet

Ablauf der Zertifikatsausstellung mit CT:

1. CA erstellt Zertifikat für domain.de
2. CA übermittelt Zertifikat an CT-Log-Server
3. CT-Log antwortet mit Signed Certificate Timestamp (SCT)
   → SCT = kryptografischer Beweis: "Dieses Cert wurde am X in Log Y aufgenommen"
4. CA bettet SCT in Zertifikat ein (oder OCSP-Stapling oder TLS-Extension)
5. Browser prüft: Zertifikat enthält gültige SCT von bekanntem Log?
   → Nein → Zertifikat wird abgelehnt! (Chrome seit 2018)

Append-Only Log-Struktur (Merkle Tree):
  → Einmal eingetragen: nicht mehr löschbar oder veränderbar!
  → Merkle-Tree-Hash: jede Änderung würde erkannt
  → Log-Betreiber können nicht schummeln ohne entdeckt zu werden

Wichtige 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 als OSINT-Werkzeug (Subdomain Discovery)

Subdomain-Discovery via Certificate Transparency:

Warum CT für Pentester wertvoll ist:
  → JEDES öffentliche TLS-Zertifikat landet im CT-Log
  → Subdomains in SAN (Subject Alternative Names) sind öffentlich!
  → Neue Subdomains sofort sichtbar (noch bevor DNS-Propagation)
  → Auch HTTPS-Seiten ohne Web-Präsenz (intern, Staging) oft im CT

crt.sh - kostenlose CT-Suche:
  # Alle Zertifikate für *.example.com finden:
  https://crt.sh/?q=%25.example.com&output=json

  # API-Zugriff 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)"

  Typische Findings aus CT:
  → api-staging.example.com
  → admin-old.example.com
  → jenkins.internal.example.com  (war mal öffentlich!)
  → dev.example.com               (oft mit weniger Sicherheit!)
  → mail2.example.com             (alter Mailserver)

Weitere CT-basierte OSINT-Tools:
  subfinder (integriert CT-Quellen):
    subfinder -d example.com -sources certspotter,crtsh -v

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

  certspotter (Sslmate):
    # Real-time CT-Monitor mit API:
    https://sslmate.com/certspotter/api/v1/issuances?domain=example.com&include_subdomains=true

  censys.io:
    # Erweitertes Zertifikat-Suche + Shodan-ähnliche Features:
    censys search "parsed.names: example.com" --index=certificates

Wildcard-Zertifikate im CT:
  → *.example.com zeigt Domain-Existenz aber nicht Subdomains
  → Daneben oft spezifische Subdomains: api.example.com einzeln
  → Multi-SAN-Certs: ein Cert für 50 Subdomains → alle sichtbar!

CT für Attack Surface Discovery:
  □ Forgotten assets finden (alte Staging-Systeme, Dev-Endpoints)
  □ Cloud-Provider-Domains: *.s3.amazonaws.com, *.azurewebsites.net
  □ Drittanbieter-Services: erkennen welche SaaS genutzt wird
  □ Historische Certs: War eine Domain mal woanders gehostet?

CT-Monitoring für Unternehmen

Eigene Domain überwachen (unauthorisierte Zertifikate erkennen):

Szenarien die erkannt werden sollen:
  → Phishing-Domain: secure-example.com (täuschend ähnlich!)
  → Typosquatting: exmple.com (Tippfehler in eigenem Namen)
  → Subdomain-Takeover: alter Subdomain zeigt auf fremden Server
  → Kompromittierte CA stellt cert für eigene Domain aus
  → Interner Subdomain wird versehentlich öffentlich gemacht

CertSpotter (SSLMate) - Monitoring-Service:
  # Kostenlos: bis 5 Domains überwachen
  # Alerts wenn neues Zertifikat für domain.com ausgestellt wird

  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
  → E-Mail-Alerts für neue Certs der eigenen Domain
  → Kostenlos für beliebige Domains

Eigenes Monitoring mit Go-CT-Library:
  # Certstream - Real-time CT-Log-Stream:
  pip install certstream
  certstream --domains example.com
  # → Sofort wenn neues Cert ausgestellt wird

Wichtige Fragen beim CT-Monitoring:
  □ Welche CAs sind für unsere Domain autorisiert?
     → CAA-DNS-Record setzen! (Certification Authority Authorization)
     → Nur autorisierte CAs dürfen Certs ausstellen
  □ Sind alle gefundenen Subdomains bekannt?
     → Unbekannte = potenzielle Shadow-IT oder vergessene Assets
  □ Sind Certs ordnungsgemäß erneuert?
     → CT zeigt Ablauf-Datum!

CAA-Record (Certificate Authority Authorization):
  # Nur Let's Encrypt und DigiCert erlaubt:
  example.com. IN CAA 0 issue "letsencrypt.org"
  example.com. IN CAA 0 issue "digicert.com"
  example.com. IN CAA 0 issuewild ";"  ← Wildcard-Certs verbieten!
  example.com. IN CAA 0 iodef "mailto:security@example.com"  ← Alert-Mail

  # Verifizieren:
  dig CAA example.com

  → Wenn fremde CA trotzdem Cert ausstellt → in CT-Logs sichtbar!
  → Manche Browser/CAs respektieren CAA vor Ausstellung

Sicherheitsimplikationen

CT und Datenschutz:

Öffentlichkeit von CT-Einträgen:
  → ALLE in CT-Logs eingetragenen Zertifikate sind ÖFFENTLICH einsehbar
  → Enthält: Domains, Subdomains, Ausstell-Zeitpunkt, Ablauf, CA
  → Gilt auch für:
    - Interne Subdomains (wenn Public-CA verwendet wurde!)
    - Beta/Staging-Systeme
    - VPN-Zugangspunkte (wenn mit Public-CA)

Datenschutz-Best-Practices:
  □ Interne Dienste NIEMALS mit Public-CA absichern
     → Stattdessen: Private CA (unternehmenseigene PKI)
     → Private-CA-Certs landen nicht in CT-Logs!
  □ Subdomain-Schema nicht zu informativ:
     → vpn-germany-headquarters.example.com → verrät Standort!
  □ Nur notwendige SANs in Zertifikaten

Sicherheit der CT-Logs selbst:
  → Mehrere unabhängige Log-Betreiber (kein Single-Point-of-Failure)
  → Google Chrome: Liste vertrauenswürdiger CT-Logs
  → Log-Kompromittierung: Merkle-Tree-Inkonsistenz sofort erkennbar

SCT-Validierung durch Browser:
  Chrome:  Mindestens 2 SCTs aus verschiedenen Logs bei DV-Certs
           Mindestens 3 SCTs für EV-Zertifikate
  Safari:  Ähnliche Anforderungen (Apple CT Policy)
  Firefox: Noch im Rollout (2024+)

Konsequenz fehlender CT:
  → Browser zeigt Warnung oder blockt Seite
  → NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
  → Kein legitimes Zertifikat ohne CT-Einträge mehr möglich!