Certificate Transparency als Frühwarnsystem für Marken- und Fehlausstellungen

Problem

Das klassische Web-PKI-Modell vertraut rund 50 öffentlichen Certification Authorities (CAs) und deren unzaehligen Subordinates blind. Jede dieser Stellen kann technisch ein Zertifikat für "dernium.de" ausstellen. Wenn eine kompromittierte, fehlerhaft konfigurierte oder boeswillige CA das tut, bemerkt der eigentliche Domaininhaber das ohne zusaetzliche Kontrolle in der Regel nicht. Genau dieser blinde Fleck hat 2011 bei DigiNotar eine massive Man-in-the-Middle-Kampagne gegen rund 300.000 iranische Nutzer ermoeglicht, bevor der Vorfall überhaupt auffiel.

Kurze Antwort

Certificate Transparency (CT) zwingt CAs dazu, jedes ausgestellte Zertifikat in öffentliche, kryptographisch verkettete Append-only-Logs einzuliefern. Browser wie Chrome und Safari akzeptieren Zertifikate nur noch, wenn mindestens ein Signed Certificate Timestamp (SCT) aus einem anerkannten Log beiliegt. Wer seine eigenen Domains auf diese Logs abonniert, sieht Fehlausstellungen und Typosquats typischerweise innerhalb von Minuten.

Tiefgang

Die Version 2.0 des Protokolls ist in RFC 9162 beschrieben und ersetzt das aeltere RFC 6962. Jeder Log ist ein Merkle-Tree, an den nur angehaengt werden darf. Beim Einreichen eines (Pre-)Zertifikats gibt der Log einen SCT zurück, eine signierte Zusage, dieses Zertifikat binnen einer Maximum Merge Delay (ueblicherweise 24 Stunden) dauerhaft aufzunehmen. Der SCT wird per X.509-Extension, OCSP-Stapling oder TLS-Extension an den Browser geliefert. Clients können Inklusionsbeweise nachpruefen, Monitore können den gesamten Baum auditieren.

Chrome setzt CT für alle öffentlich vertrauten Zertifikate verbindlich durch. Die aktuelle Regelbasis steht in der Chrome Certificate Transparency Policy. Apple fordert CT seit Oktober 2018 und führt eine eigene Liste akzeptierter Logs. Die praktische Folge: Ein Zertifikat, das es am Browser vorbeischaffen will, liegt zwangslaeufig in mindestens einem öffentlich durchsuchbaren Log.

Diese Durchsetzung hat drei grosse CA-Vorfaelle überhaupt erst nachvollziehbar gemacht. Symantec wurde 2017 distrusted, nachdem Andrew Ayer über CT-Monitoring mehr als 100 unberechtigt ausgestellte Zertifikate gefunden hatte, unter anderem für example.com. Die DigiNotar-Affaere wurde retrospektiv zum Lehrbeispiel und war der direkte Antrieb hinter Googles CT-Initiative. Und im Juni 2024 hat Google im Security-Blog angekuendigt, neuen Entrust-Zertifikaten mit SCT-Datum nach dem 11. November 2024 das Vertrauen zu entziehen. Begruendung waren dokumentierte Compliance-Versaeumnisse, die genau deshalb öffentlich nachvollziehbar waren, weil alle betroffenen Ausstellungen in CT-Logs lagen.

Für Monitoring gibt es drei praktikable Wege. Erstens ad hoc über die Suchmaske von crt.sh, betrieben von Sectigo. Zweitens eigene Feeds, etwa das Atom-Abo unter https://crt.sh/atom?q=%25dernium.de. Drittens ein richtiger Log-Tail mit SSLMate Cert Spotter, der die Logs direkt liest, ohne auf einen Aggregator angewiesen zu sein, und zusaetzlich die Append-only-Eigenschaft prüft. Für strategische Übersicht ist der Google Transparency Report brauchbar.

Spannend wird CT als Markenschutz, sobald man das Muster auf Typosquats und Homoglyphen ausdehnt. Wenn der Inhaber von "dernium.de" ein Zertifikat für ein kyrillisch-aehnliches Glyph oder "svelnoer.de" im Log sieht, ist das ein sauberer Indicator of Compromise. In der Praxis heißt das: Suchmuster jenseits der eigenen Domain, Unicode-Konfusionsklassen nach UTS 39 und Edit-Distanz-Heuristiken.

Zwei Fallstricke muss man sauber einpreisen. Zum einen issuen moderne CDN-Anbieter Zertifikate für Kundendomains über ihre eigenen Intermediates, Cloudflare oder Fastly sind hier typische Quellen. Wer das nicht vorher whitelistet, produziert Alarmmuedigkeit. Zum anderen liefert Let's Encrypt sechs- bis achtstellige Zertifikatszahlen pro Tag; ein Filter auf exakt die eigenen Host-Patterns plus explizite Ausschlussregeln für erwartete Subdomains ist zwingend.

Als komplementaere Kontrolle gehoert RFC 8659 dazu. Ein CAA-DNS-Record schraenkt vorab ein, welche CAs überhaupt für eine Domain ausstellen duerfen. CAA verhindert die Ausstellung, CT macht sie sichtbar, falls ein Angreifer die CAA-Pruefung umgeht oder eine CA sie missachtet. Beide Kontrollen ergänzen sich, sie ersetzen sich nicht.

Abgelehnte Alternativen

HTTP Public Key Pinning (HPKP) war der erste Versuch, die CA-Pluralitaet einzudaemmen. Es hat sich als zu fragil erwiesen, weil Fehlkonfigurationen ganze Sites unerreichbar machten. Chrome hat HPKP 2018 entfernt. DANE über TLSA-Records ist technisch elegant, scheitert aber am geringen DNSSEC-Rollout und daran, dass kein Major-Browser es für Web-PKI durchsetzt. Rein internes CA-Inventar per Spreadsheet skaliert in Konzernen mit dutzenden Tochtermarken nicht und erwischt Schatten-IT gar nicht.

Wie Dernium hier hilft

Dernium Watch wird als eigenstaendiges Produkt unter watch.dernium.de entwickelt und buendelt drei Signalquellen: Live-Abonnement auf die Chrome- und Apple-anerkannten CT-Logs, CAA-Record-Checks pro überwachter Domain sowie eine Homoglyph- und Typosquat-Expansion, die aus der eigenen Markenliste automatisch Suchmuster ableitet. Heute steht die Plattformbasis, produktiv ist der CT-Stream-Consumer mit Host-Pattern-Filter noch nicht; CAA-Monitoring und Homoglyph-Detektion sind geplante Teilprojekte, keine Features von morgen. Den aktuellen Stand halten wir auf der Produktseite transparent nach.

Offene Punkte

Die Chrome-Policy entwickelt sich weiter; insbesondere ist ab Mai 2026 mit Chrome 148 der Wegfall OCSP-gelieferter SCTs geplant. Wer eigene interne PKIs betreibt und CT dort einziehen will, sollte Log-Betrieb und Datenschutz (CT-Logs sind öffentlich und enthalten Hostnamen) separat bewerten. Ein Eigenbetrieb eines CT-Logs für den Webhandshake lohnt sich für Nicht-CAs praktisch nie.