Certificate Transparency 2026: CT-Logs aktiv überwachen

Was Certificate Transparency ist und welches Problem es löst

Certificate Transparency (CT) ist ein offener Standard, der 2013 von Google initiiert und in RFC 6962 spezifiziert wurde (RFC Editor). Die Grundidee: Jede Zertifizierungsstelle (Certificate Authority, CA) reicht jedes ausgestellte Zertifikat bei mehreren öffentlichen, manipulationssicheren Protokollen ein. Diese Logs sind für jeden einsehbar und durchsuchbar — über öffentliche Schnittstellen oder über das Monitoring von Sicherheitsdiensten. Damit wird das Web-PKI-Vertrauensmodell, das jahrelang eine intransparente Blackbox war, prüfbar.

Das Problem, das CT löst, ist real und teuer. Vor CT konnte eine kompromittierte oder schlampig arbeitende CA Zertifikate für beliebige Domains ausstellen, ohne dass der eigentliche Domain-Inhaber davon erfuhr. Der bekannteste Fall: 2011 wurde die niederländische CA DigiNotar vollständig übernommen. Angreifer kontrollierten alle acht zertifikatsausstellenden Server und erzeugten mindestens 531 betrügerische Zertifikate (Black-Tulip-Report), darunter ein Wildcard-Zertifikat für *.google.com, das in einem Man-in-the-Middle-Angriff gegen rund 300.000 Nutzer im Iran eingesetzt wurde (Wikipedia/Fox-IT). DigiNotar war wenige Wochen später insolvent.

Auch große, etablierte Anbieter sind nicht gefeit. Über das Certificate-Transparency-Programm deckte Google 2015 bis 2017 auf, dass Symantec über Jahre hinweg bis zu 30.000 Zertifikate ohne ordnungsgemäße Validierung ausgestellt hatte (The SSL Store/Google). Die Folge: Chrome und andere Browser entzogen den betroffenen Zertifikaten schrittweise das Vertrauen — ein Vorgang, der ohne die öffentliche Sichtbarkeit der CT-Logs nicht ans Licht gekommen wäre.

Wie ein CT-Log technisch funktioniert

Ein CT-Log ist eine einzige, immerwährend wachsende, ausschließlich anfügbare (append-only) Datenstruktur — technisch ein Merkle-Tree, dessen Knoten mit kryptografischen SHA-256-Hashes ihrer Kindknoten beschriftet sind (RFC Editor). Zertifikate können nur hinzugefügt, aber nicht nachträglich gelöscht, verändert oder rückwirkend eingefügt werden. Verstöße gegen diese Append-only-Eigenschaft lassen sich durch den Abgleich der signierten Baumköpfe (Signed Tree Heads) zwischen unabhängigen Beobachtern erkennen.

Wenn eine CA ein gültiges Zertifikat einreicht, muss das Log sofort einen Signed Certificate Timestamp (SCT) zurückgeben — das Versprechen, das Zertifikat innerhalb einer festen Frist, der Maximum Merge Delay (typischerweise 24 Stunden), in den Baum aufzunehmen (RFC Editor). Dieser SCT wird in das Zertifikat eingebettet und vom Browser geprüft. Der Nachweis, dass ein Zertifikat tatsächlich im Log enthalten ist, lässt sich effizient in logarithmischer Zeit erbringen (RFC Editor) — selbst bei Milliarden von Einträgen.

Wichtig ist die Unterscheidung zwischen einem Zertifikat und einem Pre-Zertifikat. Damit der SCT bereits zum Ausstellungszeitpunkt in das Zertifikat eingebettet werden kann, reicht die CA zunächst eine spezielle Vorabversion — das Pre-Zertifikat — bei den Logs ein und erhält dafür die SCTs zurück. Erst danach entsteht das endgültige, ausgelieferte Zertifikat mit eingebetteten SCTs. Aus Sicht des Monitorings ist das relevant, weil sowohl Pre-Zertifikate als auch finale Zertifikate in den Logs auftauchen: Ein und dieselbe Ausstellung kann in mehreren Einträgen sichtbar werden, was ein gutes Monitoring entsprechend zusammenfasst, statt es als getrennte Vorfälle zu melden. Die ursprüngliche Log-Architektur aus RFC 6962 wird derzeit zudem durch eine effizientere, gekachelte Struktur (Static CT API) abgelöst (RFC Editor) — für Domain-Inhaber ändert sich am Prinzip der öffentlichen Prüfbarkeit dadurch nichts.

Warum CT-Logs für Browser inzwischen Pflicht sind

Certificate Transparency ist längst keine freiwillige Kür mehr. Seit dem 24. Juli 2018 erzwingt Google CT in Chrome 68 und höher: Alle nach April 2018 ausgestellten, öffentlich vertrauenswürdigen TLS-Zertifikate müssen CT-konform sein, um erfolgreich validiert zu werden (IDManagement.gov/Google). Wenige Monate später, am 15. Oktober 2018, zog Apple nach und verlangt seither mindestens zwei SCTs aus anerkannten CT-Logs (DigiCert/Apple).

Apples Richtlinie staffelt die Anzahl der nötigen SCTs nach der Laufzeit des Zertifikats: Zertifikate mit weniger als 15 Monaten Gültigkeit benötigen zwei SCTs, 15 bis 27 Monate drei, 27 bis 39 Monate vier und alles darüber fünf (Apple/Entrust). Praktisch bedeutet das: Ein Zertifikat, das nicht in den CT-Logs steht, funktioniert in modernen Browsern schlicht nicht. Ihre Domain ist also bereits heute in diesen Logs vertreten, ob Sie es aktiv beobachten oder nicht — die einzige Frage ist, ob Sie mitlesen oder nur potenzielle Angreifer.

Welche Bedrohungen CT-Log-Monitoring aufdeckt

Der eigentliche Sicherheitsgewinn entsteht nicht durch CT allein, sondern durch das aktive Beobachten der Logs. Ohne Monitoring sind die Daten zwar öffentlich, aber niemand schaut hin. Mit Monitoring werden aus 17 Milliarden Einträgen genau die wenigen herausgefiltert, die Ihre Domain betreffen — und davon wiederum die, die Sie nicht selbst beantragt haben.

Besonders der Phishing-Aspekt ist gravierend. Laut Anti-Phishing Working Group nutzten bereits 84 % der Phishing-Seiten ein gültiges SSL-Zertifikat samt Schloss-Symbol — ein Anstieg von rund 26 Prozentpunkten gegenüber dem ersten Quartal 2019 (58 %) (APWG, Q4 2020). Die Verfügbarkeit kostenloser, domainvalidierter Zertifikate hat diesen Trend befeuert: Allein Let's Encrypt stellt Ende 2025 zeitweise zehn Millionen Zertifikate pro Tag aus (Let's Encrypt). Das Schloss-Symbol allein sagt heute nichts mehr über die Vertrauenswürdigkeit einer Seite aus — wohl aber das CT-Log darüber, wer für Ihre Marke Zertifikate ausstellt.

Die historischen Großvorfälle illustrieren, warum genau diese Sicht so wertvoll ist. Beim DigiNotar-Hack 2011 wurde die Kompromittierung erst durch das Certificate-Pinning in Chrome aufgedeckt — also durch eine clientseitige Kontrolle, weil es ein systematisches Log-Monitoring damals noch nicht gab (Slate/Wikipedia). Im Symantec-Fall war es umgekehrt das Certificate-Transparency-Programm selbst, das die Fehlausstellungen sichtbar machte (The SSL Store/Google). Die Lehre für jede Marke heute: Wer seine eigenen Domains in den Logs beobachtet, ist nicht darauf angewiesen, dass ein Browser-Hersteller oder ein externer Forscher das Problem zufällig bemerkt. Das verkürzt die Zeitspanne zwischen Ausstellung und Entdeckung von Wochen oder Monaten auf Minuten — und genau diese Zeitspanne entscheidet darüber, wie viel Schaden ein betrügerisches Zertifikat anrichten kann.

Legitimes vs. unerwartetes Zertifikat: die Unterscheidung

Der Kern des CT-Monitorings ist eine Einordnung: Ist ein neu aufgetauchtes Zertifikat erwartet oder nicht? Ein gut konfiguriertes Monitoring vergleicht jeden neuen Log-Eintrag für Ihre Domain gegen eine Reihe von Kriterien und unterscheidet so zwischen Normalbetrieb und Verdachtsfall — ohne Sie bei jeder routinemäßigen Erneuerung mit Fehlalarmen zu fluten.

• Ausstellende CA: Stammt das Zertifikat von einer CA, die Sie tatsächlich nutzen und die Ihr CAA-Record erlaubt? Eine fremde CA ist ein Warnsignal.
• Common Name und SAN: Deckt sich der eingetragene Domain-Name mit Ihren bekannten (Sub-)Domains? Eine nicht beantragte Subdomain deutet auf Shadow IT oder Kompromittierung hin.
• Tippfehler-Varianten: Wurde ein Zertifikat für eine Domain ausgestellt, die Ihrem Namen verblüffend ähnelt? Das ist ein klassisches Lookalike-/Phishing-Muster.
• Zeitpunkt: Passt die Ausstellung zu einem geplanten Rollout oder einer automatischen Erneuerung — oder kommt sie aus dem Nichts?
• Anzahl und Herkunft der SCTs: Erfüllt das Zertifikat die Browser-Anforderungen, oder wirkt die Protokollierung manipuliert?

CT-Monitoring im Verbund mit anderen Sicherheitssignalen

CT-Log-Monitoring entfaltet seinen vollen Wert erst im Zusammenspiel mit den übrigen Säulen der Website-Sicherheit. Ein betrügerisches Zertifikat ist selten ein isolierter Vorfall — es ist oft der erste sichtbare Schritt einer Angriffskette, die sich auch an anderer Stelle abzeichnet. Wer mehrere Signale korreliert, erkennt Angriffe früher und mit weniger Fehlalarmen.

Auch die E-Mail-Authentifizierung gehört in dieses Bild. Wer eine Phishing-Domain mit gültigem Zertifikat aufsetzt, versucht oft im selben Zug, E-Mails im Namen Ihrer Marke zu versenden. Das Auswerten von DMARC-Reports macht solche Missbrauchsversuche sichtbar und ergänzt die CT-Überwachung um die Mail-Perspektive. So entsteht ein Lagebild, das Domain, Zertifikat, DNS und E-Mail gemeinsam betrachtet.

CT-Monitoring praktisch aufsetzen: Schritt für Schritt

Der Einstieg in CT-Monitoring ist unkompliziert, weil die Daten ohnehin existieren — Sie müssen sie nur systematisch beobachten und sinnvoll filtern. Ein strukturiertes Vorgehen verhindert, dass Sie in Fehlalarmen ertrinken oder umgekehrt echte Vorfälle übersehen.

1. Domain-Inventar erstellen: Erfassen Sie alle Domains und Subdomains, die zu Ihrer Organisation gehören — inklusive selten genutzter und historischer Namen. Nur was Sie kennen, können Sie als legitim einordnen.
2. Erlaubte CAs festlegen: Definieren Sie, welche Zertifizierungsstellen Sie nutzen, und hinterlegen Sie dies konsistent in Ihren CAA-Records.
3. Tippfehler-Varianten ableiten: Sammeln Sie naheliegende Lookalike-Domains Ihrer Marke, damit Phishing-Zertifikate auffallen.
4. Logs kontinuierlich beobachten: Lassen Sie die öffentlichen CT-Logs automatisiert nach Ihren Domains und Varianten durchsuchen — neue Einträge erscheinen oft schon Sekunden nach der Ausstellung.
5. Alarmierung einrichten: Verknüpfen Sie jeden unerwarteten Fund mit einer sofortigen Benachrichtigung per E-Mail, Slack, Discord oder Telegram.
6. Reaktionsplan definieren: Legen Sie vorab fest, wer ein verdächtiges Zertifikat prüft, wann eine Sperrung (Revocation) beantragt wird und wie eine mögliche Datenpanne nach Art. 33 DSGVO behandelt wird.

Ein häufiger Stolperstein in der Praxis ist die Behandlung von Wildcard-Zertifikaten. Ein Eintrag für *.ihre-domain.de deckt beliebig viele Subdomains ab, ohne dass jede einzelne als separates Zertifikat in den Logs auftaucht. Das ist bequem, kann aber Shadow IT verschleiern: Wer ein Wildcard im Einsatz hat, sollte ergänzend überwachen, welche Subdomains tatsächlich aktiv sind, statt sich allein auf die CT-Einträge zu verlassen. Ein zweiter typischer Fehler ist die unvollständige Domain-Liste — gerade bei Zukäufen, Kampagnen-Domains oder ausgelaufenen Projekten geraten Namen in Vergessenheit, die weiterhin auf die Organisation registriert sind. Genau diese vergessenen Domains sind ein bevorzugtes Ziel für Übernahmen. Ein lebendiges, regelmäßig gepflegtes Inventar ist deshalb die Grundvoraussetzung dafür, dass die Unterscheidung zwischen erwartet und unerwartet überhaupt verlässlich funktioniert.

Wirtschaftliche Folgen und Compliance-Bezug

Die Kosten eines unentdeckten Zertifikatsproblems sind erheblich. Ein einziger Telekommunikationskonzern verursachte durch ein abgelaufenes Zertifikat einen Ausfall, der 32 Millionen Kunden in 11 Ländern betraf und in der Aufarbeitung mit Folgekosten in Milliardenhöhe verbunden war (Red Sift/Sectigo). Branchenweit berichten 88 % der Unternehmen von einem ungeplanten Ausfall durch ein abgelaufenes Zertifikat in den vergangenen zwei Jahren (Red Sift). Während diese Zahlen abgelaufene Zertifikate betreffen, zeigen sie die operative Tragweite des gesamten Zertifikats-Lebenszyklus — und CT-Monitoring ist die vorgelagerte Erkennungsschicht für dessen Ausstellungsphase.

Auch das Thema Shadow IT spielt direkt hinein: Laut Gartner verschaffen sich rund 41 % der Mitarbeitenden Technologie, von der die IT-Abteilung nichts weiß (Gartner). Eine eigenmächtig eingerichtete Subdomain mit eigenem Zertifikat ist ein typisches Beispiel — und taucht zuverlässig in den CT-Logs auf, lange bevor die IT sie auf anderem Weg bemerkt. Für die Compliance ist das relevant: Wer den Überblick über alle Zertifikate seiner Domains nachweisen kann, erfüllt einen Baustein der „geeigneten technischen und organisatorischen Maßnahmen“, die die DSGVO fordert.

Der deutsche Kontext verstärkt das. Das BSI behandelt den sicheren Einsatz von TLS in der technischen Richtlinie TR-02102-2 (BSI), deren aktuelle Fassung 2026-01 erschienen ist. Mit dem Inkrafttreten des NIS2-Umsetzungsgesetzes am 6. Dezember 2025 erhalten Mindeststandards zudem eine neue rechtliche Grundlage in § 44 BSIG (BSI). Eine lückenlose Sicht auf die eigenen Zertifikate ist damit nicht nur gute Praxis, sondern zunehmend regulatorische Erwartung.

Vertrauen durch Transparenz: CT als Teil Ihrer Sicherheitsstrategie

Certificate Transparency hat die Web-PKI von einem intransparenten Vertrauenssystem in eine prüfbare Infrastruktur verwandelt. Doch Transparenz nützt nur, wenn jemand hinschaut. Die öffentlichen Logs sind ein gewaltiger, frei zugänglicher Datenschatz — bei rund 121,6 Millionen neuen Zertifikaten pro Tag (Cloudflare Radar, Certificate Transparency) aber unmöglich manuell auszuwerten. Genau hier setzt automatisiertes Monitoring an: Es reduziert die Milliarden Einträge auf die Handvoll, die für Ihre Domain relevant sind.

Der XICTRAQ Security-Scan beobachtet die Certificate-Transparency-Logs für Ihre Domains und Subdomains. Taucht ein Zertifikat von einer unerwarteten CA, für eine nicht beantragte Subdomain oder für eine Tippfehler-Variante Ihres Namens auf, erhalten Sie umgehend eine Benachrichtigung — kombinierbar mit der Überwachung von Ablaufdaten, Zertifikatskette und Konfiguration Ihrer aktiven Zertifikate. So wird aus der reinen Transparenz der CT-Logs ein konkreter, handlungsfähiger Frühwarnmechanismus für Ihre Marke.

Häufig gestellte Fragen zu Certificate Transparency