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

Problem

Das klassische Web-PKI-Modell (PKI = Public Key Infrastructure, das System aus Zertifikaten und vertrauenswürdigen Ausstellern, auf dem HTTPS beruht) vertraut rund 50 öffentlichen Certification Authorities (CAs, Zertifizierungsstellen) und deren unzähligen Subordinates (untergeordneten Ausstellern) blind. Jede dieser Stellen kann technisch ein Zertifikat für "dernium.de" ausstellen. Wenn eine kompromittierte, fehlerhaft konfigurierte oder böswillige CA das tut, bemerkt der eigentliche Domaininhaber das ohne zusätzliche Kontrolle in der Regel nicht. Genau dieser blinde Fleck hat 2011 bei DigiNotar eine massive Man-in-the-Middle-Kampagne (Angriff, bei dem sich ein Dritter unbemerkt zwischen zwei Kommunikationspartner schaltet) gegen rund 300.000 iranische Nutzer ermöglicht, bevor der Vorfall überhaupt auffiel.

Für wen ist das? Für Domain- und Sicherheitsverantwortliche, die Fehlausstellungen von Zertifikaten früh erkennen wollen.

Kurze Antwort

Certificate Transparency macht jede Zertifikatsausstellung öffentlich nachprüfbar - so sehen Sie binnen Minuten, wenn jemand ein Zertifikat für Ihre Domain ausstellen lässt.

• CT (Certificate Transparency) zwingt CAs, jedes ausgestellte Zertifikat in öffentliche, fälschungssichere Logs (Append-only, also nur anhängbar) einzuliefern.
• Browser erzwingen es: Chrome und Safari akzeptieren Zertifikate nur mit einem Signed Certificate Timestamp (SCT, signierter Beleg aus einem anerkannten Log).
• Folge: Jedes gültige Zertifikat liegt zwangsläufig in mindestens einem durchsuchbaren Log - auch ein bösartig ausgestelltes.
• Monitoring: Abonnieren Sie die Logs auf Ihre Domains, dann fallen Fehlausstellungen und Typosquats (verwechslungsähnliche Domains) schnell auf.
• Ergänzung, kein Ersatz: Ein CAA-DNS-Record verhindert unerlaubte Ausstellung vorab, CT macht sie im Nachhinein sichtbar - beide zusammen.

Tiefgang

Die Version 2.0 des Protokolls ist in RFC 9162 beschrieben und ersetzt das ältere RFC 6962. Jeder Log ist ein Merkle-Tree (eine kryptografisch verkettete Baumstruktur, bei der jede nachträgliche Änderung auffällt), an den nur angehängt werden darf. Beim Einreichen eines (Pre-)Zertifikats gibt der Log einen SCT zurück, eine signierte Zusage, dieses Zertifikat binnen einer Maximum Merge Delay (maximale Einarbeitungsfrist, üblicherweise 24 Stunden) dauerhaft aufzunehmen. Der SCT wird per X.509-Extension (Erweiterungsfeld im Zertifikat), OCSP-Stapling oder TLS-Extension an den Browser geliefert. Clients können Inklusionsbeweise (Nachweise, dass ein Zertifikat tatsächlich im Log steht) nachprüfen, 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 zwangsläufig in mindestens einem öffentlich durchsuchbaren Log.

Diese Durchsetzung hat drei große CA-Vorfälle überhaupt erst nachvollziehbar gemacht. Symantec wurde 2017 distrusted (das Vertrauen wurde entzogen), nachdem Andrew Ayer über CT-Monitoring mehr als 100 unberechtigt ausgestellte Zertifikate gefunden hatte, unter anderem für example.com. Die DigiNotar-Affäre wurde retrospektiv zum Lehrbeispiel und war der direkte Antrieb hinter Googles CT-Initiative. Und im Juni 2024 hat Google im Security-Blog angekündigt, neuen Entrust-Zertifikaten mit SCT-Datum nach dem 11. November 2024 das Vertrauen zu entziehen. Begründung waren dokumentierte Compliance-Versäumnisse, 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 (kontinuierliches Mitlesen) mit SSLMate Cert Spotter, der die Logs direkt liest, ohne auf einen Aggregator angewiesen zu sein, und zusätzlich 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 (verwechselbar ähnliche Schriftzeichen) ausdehnt. Wenn der Inhaber von "dernium.de" ein Zertifikat für ein kyrillisch-ähnliches Glyph oder "svelnoer.de" im Log sieht, ist das ein sauberer Indicator of Compromise (IoC, ein konkretes Verdachtsmerkmal). In der Praxis heißt das: Suchmuster jenseits der eigenen Domain, Unicode-Konfusionsklassen nach UTS 39 und Edit-Distanz-Heuristiken (Erkennung von Domains, die sich nur um wenige Zeichen unterscheiden).

Zwei Fallstricke muss man sauber einpreisen. Zum einen issuen (erzeugen) moderne CDN-Anbieter (Content Delivery Networks, Auslieferungsnetze wie Cloudflare oder Fastly) Zertifikate für Kundendomains über ihre eigenen Intermediates; sie sind hier typische Quellen. Wer das nicht vorher whitelistet (als erwartet freigibt), produziert Alarmmüdigkeit. 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 komplementäre Kontrolle gehört RFC 8659 dazu. Ein CAA-DNS-Record (Certification Authority Authorization, ein DNS-Eintrag) schränkt vorab ein, welche CAs überhaupt für eine Domain ausstellen dürfen. CAA verhindert die Ausstellung, CT macht sie sichtbar, falls ein Angreifer die CAA-Prüfung 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-Pluralität einzudämmen. 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 (nicht von der IT freigegebene Systeme) gar nicht.

Was Sie jetzt tun sollten

1. Machen Sie eine Sofort-Bestandsaufnahme. Geben Sie Ihre Hauptdomain bei crt.sh ein und prüfen Sie, ob alle gelisteten Zertifikate erwartbar sind. Unbekannte Einträge sind sofort zu untersuchen.
2. Richten Sie ein laufendes Monitoring ein. Abonnieren Sie einen Feed (etwa das Atom-Abo von crt.sh) oder setzen Sie einen Log-Tail wie Cert Spotter auf - einmalige Suchen reichen für Dauerschutz nicht.
3. Pflegen Sie eine Whitelist erwarteter Aussteller. Tragen Sie Ihre CDN-Anbieter und legitimen CAs als erwartet ein, sonst ertrinken echte Warnungen in Fehlalarmen.
4. Setzen Sie einen CAA-DNS-Record. Beschränken Sie per CAA, welche CAs überhaupt für Ihre Domains ausstellen dürfen. Das verhindert unerlaubte Ausstellung vorab, während CT sie sichtbar macht.
5. Weiten Sie die Suche auf Typosquats aus. Erzeugen Sie aus Ihren Markennamen verwechselbare Schreibweisen und Homoglyphen und überwachen Sie auch diese - so erkennen Sie Phishing-Vorbereitungen früh.

Wie Dernium hier hilft

Dernium Watch ist als eigenständiges Produkt live und bündelt drei Signalquellen: eine regelmäßige Auswertung der Chrome- und Apple-anerkannten CT-Logs über den crt.sh-Aggregator, CAA-Record-Checks pro überwachter Domain sowie eine Homoglyph- und Typosquat-Expansion, die aus der eigenen Markenliste automatisch Suchmuster ableitet. Den jeweils aktuellen Funktionsumfang halten wir auf der Produktseite transparent nach. Wenn Sie zunächst nur einzelne Domains stichprobenhaft prüfen wollen, finden Sie unter den kostenlosen Webtools einen CAA-Record-Check und einen Validator für die TLS-Zertifikatskette, ohne Anmeldung und direkt im Browser.

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.

Häufige Fragen

Was bringt mir Certificate Transparency konkret als Domaininhaber?

CT gibt Ihnen ein öffentliches, fälschungssicheres Verzeichnis aller Zertifikate, die für Ihre Domain ausgestellt wurden. Wenn eine fehlerhafte oder kompromittierte Zertifizierungsstelle ein Zertifikat für Ihre Domain ausstellt, landet es zwangsläufig in diesem Verzeichnis. Überwachen Sie es, erkennen Sie eine solche Fehlausstellung typischerweise innerhalb von Minuten - statt wie früher gar nicht oder erst nach einem Schaden.

Muss ich für CT-Monitoring eigene Software betreiben?

Nicht unbedingt. Für den Einstieg genügt die kostenlose Suchmaske von crt.sh oder deren Feed-Abonnement. Wer es robuster will, nutzt ein Werkzeug wie Cert Spotter, das die Logs direkt liest und auch deren Unveränderbarkeit prüft, oder einen Dienst, der das Monitoring übernimmt. Eigene Software ist nur nötig, wenn Sie sehr spezifische Filter oder eine eigene Verarbeitung brauchen.

Was ist der Unterschied zwischen CAA und CT?

Ein CAA-Eintrag im DNS legt vorab fest, welche Zertifizierungsstellen überhaupt für Ihre Domain ausstellen dürfen - er soll die unerlaubte Ausstellung verhindern. CT verhindert nichts, sondern macht jede tatsächlich erfolgte Ausstellung im Nachhinein öffentlich sichtbar. Umgeht ein Angreifer die CAA-Prüfung oder missachtet eine CA sie, fängt CT das als sichtbares Signal auf. Die beiden Mechanismen ergänzen sich und sollten gemeinsam eingesetzt werden.

Warum bekomme ich so viele Treffer für meine Domain?

Das ist normal. Automatische Zertifikatsdienste wie Let's Encrypt erneuern Zertifikate sehr häufig, und CDN-Anbieter stellen für Kundendomains laufend eigene Zertifikate aus. Ohne Filter sehen Sie deshalb viele erwartbare Einträge. Definieren Sie eine Whitelist Ihrer legitimen Aussteller und Subdomains, damit nur die wirklich auffälligen, unerwarteten Ausstellungen einen Alarm auslösen.

Hilft CT auch gegen gefälschte, ähnlich aussehende Domains?

Indirekt ja. CT überwacht zunächst Ihre eigene Domain, aber Sie können das Muster auf verwechselbare Schreibweisen und Zeichen ausweiten (Typosquats und Homoglyphen). Sieht ein Angreifer für eine solche Fake-Domain ein Zertifikat ausstellen, taucht das in den Logs auf - oft ein frühes Zeichen für eine geplante Phishing-Kampagne. CT verhindert die Fremddomain nicht, gibt Ihnen aber ein Frühwarnsignal.