Zertifikatstransparenzüberwachung im Zeitalter der statischen Stromwandler

Certificate Transparency (CT) ist ein öffentliches, permanent verfügbares Protokoll der für Websites ausgestellten TLS-Zertifikate . Durch die Überwachung dieser öffentlichen Protokolle, bekannt als Certificate Transparency Monitoring, können Sicherheitsteams Zertifikate für ihre Domains aufspüren, die sie nie angefordert oder genehmigt haben. Zwei Änderungen aus dem Jahr 2026 beeinflussen die Funktionsweise: Eine neue Browserregel legt fest, wie und wo Zertifikate protokolliert werden müssen, und die Protokolle selbst wurden überarbeitet, um schneller und kostengünstiger ausgeführt zu werden.

Diese Veränderungen bedeuten, dass die Tools und Gewohnheiten vieler Teams im Bereich CT-Monitoring aktualisiert werden müssen. Dieser Blogbeitrag erläutert die Änderungen, ihre Bedeutung und wie Sie einen zukunftsfähigen Monitoring-Ansatz für 2026 und darüber hinaus entwickeln. Wir beginnen mit den Grundlagen, sodass Sie kein CT-Experte sein müssen, um den Ausführungen folgen zu können.

Was Zertifikatstransparenz ist und warum sie wichtig ist

Certificate Transparency ist ein öffentliches Protokollierungssystem für TLS-Zertifikate. Jedes Mal, wenn eine Zertifizierungsstelle ein Zertifikat ausstellt, protokolliert sie dieses in einem öffentlichen, nur erweiterbaren Register. Jeder kann diese Protokolle einsehen, und diese Offenheit ermöglicht es, Zertifikate zu erkennen, die nicht existieren sollten.

Vor der Einführung von CT konnte eine kompromittierte oder fehlerhaft arbeitende Zertifizierungsstelle (CA) unbemerkt Zertifikate für beliebige Domains ausstellen, ohne dass dies jemandem außerhalb dieser CA auffiel. Im Jahr 2011 kompromittierten Angreifer die niederländische CA DigiNotar und stellten Hunderte gefälschter Zertifikate aus, darunter ein Wildcard-Zertifikat für *.google.com. Damals gab es keine öffentlich nachvollziehbare Aufzeichnung der Zertifikatsausstellung, was es Domaininhabern und Browserherstellern erschwerte, unautorisierte oder falsch ausgestellte Zertifikate zeitnah zu erkennen. CT wurde entwickelt, um diese Lücke zu schließen.

Für Sicherheitsteams bietet CT heute zahlreiche praktische Funktionen. Es ermöglicht die Erkennung von Zertifikaten, die ohne Ihr Wissen für Ihre Domains ausgestellt wurden, das Aufspüren von Fehlausstellungen durch Zertifizierungsstellen, bevor Schaden entsteht, die Abbildung des externen Zertifikatsbestands Ihres Unternehmens, einschließlich vergessener Subdomains, und die Erstellung von Prüfnachweisen für Compliance -Programme, die eine Überwachung der Zertifikatsausstellung erfordern.

Das Protokoll ist in RFC 6962 und dessen Nachfolger RFC 9162 standardisiert , obwohl Browser in der Praxis weiterhin RFC 6962 implementieren. Browser wie Chrome und Safari verlangen, dass Zertifikate einen Signed Certificate Timestamp (SCT) enthalten. Dieser dient als kryptografischer Nachweis im Protokoll, dass das Zertifikat registriert wurde. Ein Zertifikat ohne gültigen SCT aus einem anerkannten Protokoll wird abgelehnt.

Was die Chrome-Vorgabe vom Juni 2026 geändert hat

Chrome setzt die Zertifikatstransparenz (CT) seit 2015 für Zertifikate mit erweiterter Validierung und seit 2018 für die meisten öffentlichen Zertifikate durch. Das Update der Google Chrome Root Program Policy (Version 1.8) vom 15. Juni 2026 verschärft die Anforderungen an Zertifikatstransparenz und PKI-Governance für alle öffentlich vertrauenswürdigen Zertifikatstypen.

Zertifizierungsstelleninhaber müssen jedes TLS-Serverauthentifizierungs-Präzertifikat in mindestens einem CT-Protokoll protokollieren, das Chrome als „Verwendbar“ oder „Qualifiziert“ erkennt, bevor das Zertifikat ausgestellt wird. Die genaue Anzahl der erforderlichen SCTs hängt von der Gültigkeitsdauer des Zertifikats ab. Chrome benötigt zwei SCTs für Zertifikate mit einer Gültigkeit von weniger als 180 Tagen und drei für solche mit einer Gültigkeit von 180 Tagen oder länger. Die grundlegende Anforderung bleibt jedoch dieselbe: die unabhängige Überprüfung durch mehrere Protokollbetreiber.

Chrome wertet jedes Zertifikat anhand einer definierten Menge von Protokollzuständen aus. Ein Protokolleintrag kann sich in einem von vier Zuständen befinden, die für die Konformität relevant sind.

• Qualifiziert: Neu von Chrome akzeptiert, und seine SCTs zählen bereits zur CT-Konformität.
• Nutzbar: Vollständig erkannt und nimmt neue Einreichungen entgegen, sodass SCTs unabhängig davon zählen, ob sie eingebettet oder über den TLS-Handshake übermittelt werden.
• ReadOnly: Es akzeptiert keine neuen Zertifikate mehr (die endgültige Baumgröße wird veröffentlicht), bleibt aber vertrauenswürdig, sodass bestehende SCTs weiterhin gültig sind.
• Außer Dienst gestellt: Wird für neue SCTs nicht mehr verwendet, und nur noch eingebettete SCTs, die vor dem Zeitpunkt der Außerdienststellung ausgestellt wurden, zählen.

SCTs von Protokolldateien, die sich nicht in einem anerkannten, gültigen Zustand befinden, werden für die Konformitätsbewertung nicht berücksichtigt. Zertifikate, die an Protokolldateien gesendet werden, welche später ihren gültigen Status verlieren, können daher ihren CT-Konformitätsstatus auch nach der Ausstellung verlieren. Chrome 148, veröffentlicht am 5. Mai 2026, hat außerdem die Unterstützung für SCTs, die über OCSP-Stapled-Antworten übermittelt werden , entfernt. Das bedeutet, dass SCTs nun entweder direkt im Zertifikat eingebettet oder über die TLS-Handshake-Erweiterung übermittelt werden müssen. Alle Bereitstellungen, die auf OCSP-Stapled-SCTs basieren, sollten neu ausgestellt werden.

Zertifikate, die zuvor auf veralteten Ausnahmen der Certificate Transparency oder überholten SCT-Übermittlungsmechanismen basierten, sollten überprüft werden, um sicherzustellen, dass sie weiterhin der aktuellen CT-Richtlinie von Chrome entsprechen. Die Vorgabe unterstreicht zudem die Notwendigkeit einer kontinuierlichen CT-Überwachung, da jedes fehlerhaft ausgestellte Zertifikat nun in einem öffentlichen Protokoll erfasst werden muss. Dadurch sind diese Protokolle eine zuverlässigere Quelle für Bedrohungsinformationen als je zuvor.

Warum das ältere Blockhaus-Design nach RFC 6962 bei größeren Abmessungen Schwierigkeiten hatte

Das ursprüngliche CT-Log-Design gemäß RFC 6962 funktioniert wie ein klassischer datenbankgestützter API-Dienst. Wenn eine Zertifizierungsstelle ein Zertifikat einreicht, speichert das Log dieses in einer Datenbank, aktualisiert einen Merkle-Hash-Baum, um den neuen Eintrag kryptografisch zu bestätigen, und gibt ein SCT zurück. Monitore und Auditoren fragen das Log anschließend über REST-API-Endpunkte ab, um Einträge abzurufen und die Konsistenz zu überprüfen.

Dieses Design funktionierte gut, solange die Zertifikatsmengen überschaubar waren. Die Web-PKI ist jedoch weit darüber hinausgewachsen. Einzelne CT-Logs enthalten nun Milliarden von Einträgen pro temporalem Shard (einem zeitlich begrenzten Abschnitt eines Logs, der nur Zertifikate mit Ablaufdatum innerhalb eines festen Zeitraums enthält), und die Datenbank hinter jedem Log wurde zum Flaschenhals. Beim Versuch, große Mengen an Einträgen schnell zu lesen, wurde der Lesepfad häufig überlastet. Die Log-Betreiber reagierten mit Ratenbegrenzungen, was die Überwachung verlangsamte und den Wert von CT als nahezu Echtzeit-Erkennungsmechanismus beeinträchtigte.

Die Garantie für eine maximale Zusammenführungsverzögerung von 24 Stunden war wiederholt gefährdet. Gemäß RFC 6962 kann ein Log ein SCT sofort zurückgeben und hat dann bis zu 24 Stunden Zeit, das Zertifikat in seinen Merkle-Baum aufzunehmen. In Zeiten hoher Auslastung verpassten Logs dieses Zeitfenster beinahe, wodurch die SCT-Zusage nicht zuverlässig eingehalten werden konnte. Diese Herausforderungen machten deutlich, dass die Architektur geändert werden musste.

Funktionsweise der Static CT API und von Sunlight

Die Static CT API verfolgt einen grundlegend anderen Ansatz. Anstatt Anfragen an eine Live-Datenbank zu beantworten, veröffentlicht ein Static CT-Log alle Daten als Hierarchie statischer Dateien, sogenannter Tiles. Diese Tiles werden aus Objektspeichern wie S3 oder einem CDN bereitgestellt. Für den Lesevorgang ist keine serverseitige Berechnung erforderlich, was die Effizienzgewinne erklärt.

Die von Filippo Valsorda in Zusammenarbeit mit Let's Encrypt entwickelte Sunlight-Implementierung ist die am weitesten verbreitete Umsetzung dieser Spezifikation. Da der Lesepfad lediglich statische Dateien umfasst, kann er vollständig über ein CDN bereitgestellt werden. Dadurch rufen die Monitore zwischenspeicherbare Kacheln ab, anstatt wiederholt eine Live-Datenbank abzufragen. Dies beseitigt den Lesepfad-Engpass, der die Überwachung gemäß RFC 6962 behinderte, und reduziert den Bandbreiten- und Rechenaufwand, den ein Log-Operator bereitstellen muss, erheblich.

Der Schreibprozess wurde ebenfalls verbessert. Sunlight bündelt Einreichungen und integriert sie in den Merkle-Baum, bevor ein SCT zurückgegeben wird. Dadurch wird die maximale Zusammenführungsverzögerung vollständig eliminiert. Ein SCT wird erst ausgestellt, wenn das Zertifikat im Baum gespeichert ist, sodass die im SCT enthaltene Zusage immer bereits erfüllt ist.

Das Protokoll ist in Kacheln mit jeweils 256 Einträgen strukturiert. Jede Kachel ist eine statische Datei, die im Objektspeicher oder im lokalen Dateisystem abgelegt wird. Das Protokoll ist zeitlich fragmentiert, sodass jede Fragmentierung nur Zertifikate akzeptiert, deren Gültigkeitsdatum (NotAfter) innerhalb eines bestimmten Zeitraums liegt, typischerweise sechs Monate. Dies begrenzt die Fragmentgröße und sorgt für einen überschaubaren Speicherplatz.

Let's Encrypt hat seine RFC-6962-Protokolle am 30. November 2025 auf schreibgeschützt umgestellt und sie am 28. Februar 2026 vollständig abgeschaltet. Die produktiven CT-Protokolle laufen nun auf Sunlight, wobei Sycamore und Willow als primäre Produktionsprotokolle dienen. Das TrustFabric-Team von Google hat TesseraCT veröffentlicht, eine statische CT-API-Implementierung, die eine Alternative zum Trillian-basierten CTFE bietet, das viele ältere Protokolle unterstützt. Das Ökosystem hat sich entschieden auf diese Architektur umgestellt.

Wie die CT-Überwachung heute funktioniert

Die Art der Datenerfassung hängt vom Protokolltyp ab. Die beiden folgenden Unterabschnitte beschreiben die Überwachung anhand älterer RFC-6962-Protokolle und anhand der neueren statischen CT-Protokolle.

Überwachung anhand von RFC 6962-Protokollen

Mithilfe eines RFC-6962-Protokolls ruft ein Monitor den Endpunkt „getentries“ mit einem Start- und Endindex auf, ruft Zertifikatspakete ab und aktualisiert seine Position bei jedem neuen Eintrag. Das Protokoll liefert Einträge aus einer Datenbank und gibt mit jedem Eintrag die vollständige Zertifikatskette zurück, wodurch die Zuordnung zu einer Zertifizierungsstelle (CA) unkompliziert wird.

Überwachung anhand statischer CT-Protokolle

Bei einem statischen CT-Protokoll lädt ein Monitor Datenkacheln direkt herunter. Jede Kachel enthält 256 Einträge. Der Monitor ruft jede noch nicht verarbeitete Kachel ab, verarbeitet die Einträge und verwendet die signierte Prüfpunktdatei des Protokolls, um die aktuelle Baumgröße zu verfolgen. Da die Kacheln statisch sind und aus dem Objektspeicher bereitgestellt werden, können Monitore sie parallel abrufen, ohne an Ratenbegrenzungen zu stoßen.

Ein praktischer Unterschied liegt in der Kettenverarbeitung. RFC-6962-Protokolle lieferten für jeden Eintrag eine vollständige Zertifikatskette. Statische CT-Protokolle fügen hingegen keine Kette zu jedem Eintrag hinzu. Stattdessen veröffentlicht das Protokoll ein Aussteller-Bundle mit den akzeptierten Zwischenzertifikaten. Monitore, die eine vollständige Kette zur CA-Zuordnung rekonstruieren müssen, müssen diese aus diesem Bundle erstellen. Dies erhöht zwar die Komplexität des Monitors, ist aber ein bewusster Kompromiss, der die Daten pro Eintrag kompakt hält und die Bandbreite deutlich reduziert.

Aus Sicht der Überwachungsstrategie bleiben die Kategorien, die es wert sind, verfolgt zu werden, unabhängig vom Protokolltyp konstant.

• Neue Zertifikate werden für Ihre Domains ausgestellt, einschließlich Wildcard-Domains.
• Zertifikate von Zertifizierungsstellen, die Ihre Organisation nicht autorisiert hat.
• Zertifikate mit Gültigkeitsdauern, die außerhalb Ihres Versicherungsvertrags liegen.
• Zertifikate, die Subdomains offenlegen, die Sie nicht kennen.

Diese vier Kategorien erzeugen den Großteil der relevantesten Ereignisse.

Verfügbare Tools für die CT-Überwachung

Die Überwachung von CT-Logs ist nur die halbe Miete; der eigentliche Erfolg liegt in der Umsetzung der gefundenen Erkenntnisse. Hier setzt der CertSecure Manager von Encryption Consulting an. Diese Plattform kombiniert die Überwachung von CT-Logs mit einem umfassenden Zertifikatslebenszyklusmanagement (CLM). Sie durchsucht kontinuierlich die CT-Logs nach Zertifikaten, die für Ihre Domains ausgestellt wurden, und gleicht jedes einzelne mit Ihrem Bestand an genehmigten Zertifikaten ab. So kann Ihr Team die Ergebnisse zentral über eine einzige Konsole untersuchen und beheben, anstatt separate Such- und Alarmierungstools verwenden zu müssen.

Certstream stellt einen Echtzeit-WebSocket-Feed mit CT-Logeinträgen aus allen aktiven Logs bereit. Sicherheitsteams nutzen ihn, um Filter- und Alarmierungs-Pipelines zu erstellen, die Teams kurz nach dem Auftreten eines passenden Zertifikats in den Certificate Transparency-Logs benachrichtigen.

Google pflegt eine aktuelle Liste anerkannter CT-Überwachungsdienste unter certificate.transparency.dev. Für Teams, die eigene Überwachungssysteme entwickeln, ist die C2SP static-ct-api-Spezifikation die vollständige technische Referenz für das Kachelformat und die Checkpoint-Struktur.

Unabhängig davon, welches Tool Ihr Team verwendet, ist das Ergebnis ein Strom von Zertifikatsereignissen, die sortiert und geprüft werden müssen. Die Gestaltung der Benachrichtigungen und deren Integration in Ihren Incident-Response-Prozess sind genauso wichtig wie die Datenerfassungspipeline selbst. Diese Tools übernehmen die Datenerfassung; die Korrelation der Ereignisse mit Ihrem Bestand an autorisierten Zertifikaten und die darauf basierenden Maßnahmen sind die Aufgabe einer CLM- Plattform.

Bedrohungsmuster, die es wert sind, überwacht zu werden

Rohdaten aus der Computertomographie sind allein nicht aussagekräftig. Effektives Monitoring bedeutet, die Muster zu erkennen, die auf ein tatsächliches Problem hinweisen.

Unautorisierte Zertifikatsausstellung : Für Ihre Domain wurde ein Zertifikat von einer Zertifizierungsstelle ausgestellt, zu der Sie keine Geschäftsbeziehung haben. Dies kann auf eine Umgehung der Domainvalidierung, eine kompromittierte Zertifizierungsstelle oder einen Angreifer mit ausreichendem DNS-Zugriff hindeuten, um die automatisierte Domainvalidierung zu umgehen. Die schnelle Erkennung solcher Fälle war der ursprüngliche Zweck von CT.

Schattenzertifikate : Zertifikate, die für Infrastruktur ausgestellt werden, die Ihr Unternehmen betreibt, aber nicht zentral verwaltet. Häufige Beispiele hierfür sind Entwicklungsteams, die persönliche CA-Konten und Zertifikate für nicht verwaltete, öffentlich zugängliche Subdomains oder Infrastruktur außerhalb genehmigter PKI- Prozesse verwenden. Schattenzertifikate stellen sowohl eine Sicherheitslücke als auch ein Compliance-Risiko dar.

Offenlegung von Subdomains : Jede Subdomain eines Zertifikats ist öffentlich auffindbar, sobald das Zertifikat ausgestellt ist. Testumgebungen, interne Tools und Produkte vor der Markteinführung werden auffindbar, sobald sie ein Zertifikat erhalten. Die Überwachung Ihrer eigenen Domains in CT ermöglicht Ihnen, diese Sicherheitslücke zu erkennen, bevor ein Angreifer sie ausnutzen kann.

Indikatoren für fehlerhaft ausgestellte Zertifikate : Zertifikate mit unerwarteten Subject Alternative Names (SANs), unerwarteten Ausstellern, ungewöhnlichen Werten für die erweiterte Schlüsselverwendung (EKU) oder anomalen Zertifikatsfeldern können auf einen Fehler in den Richtlinien der Zertifizierungsstelle oder auf eine vorsätzliche Manipulation hinweisen. Die automatisierte Feldanalyse in großem Umfang ermöglicht es, diese zuverlässig zu erkennen.

Phishing- und Typo-Squatting-Infrastruktur : Angreifer erlangen regelmäßig Zertifikate für Domains, die dem Namen einer Zielorganisation optisch ähneln. Die Überwachung von Cyberkriminalität auf ähnliche Domains und gängige Substitutionsmuster ermöglicht eine frühzeitige Warnung vor dem Aufbau einer Phishing-Infrastruktur.

Das Erkennen dieser Muster in Rohdaten von Cyberkriminalität ist das eine. Das schnelle Reagieren darauf in allen Ihren Domänen ist etwas ganz anderes. Genau hier setzt eine CLM- Plattform an: Sie wandelt einen Strom von Cyberkriminalitätswarnungen in priorisierte Aufgaben um, die Ihr Team verfolgen und lösen kann.

Wie Verschlüsselungsberatung helfen kann

Die Überwachung von Zertifikatstransparenz ist besonders wertvoll, wenn sie mit einer CLM-Plattform verbunden ist, die auf die in den Protokollen enthaltenen Informationen reagieren kann. Ein nicht autorisiertes Zertifikat in einem CT-Protokoll ist nur dann hilfreich, wenn Ihr Team weiß, welche Zertifizierungsstelle es ausgestellt hat, ob es über einen genehmigten Prozess beantragt wurde und wie schnell es widerrufen und ersetzt werden kann. Ohne eine CLM-Plattform, die diesen Kontext liefert, erzeugen CT-Warnungen lediglich irrelevante Informationen anstatt Handlungsempfehlungen.

Der CertSecure Manager von Encryption Consulting ist eine herstellerneutrale CLM-Plattform, die Sicherheits- und PKI-Teams vollständige Transparenz und Kontrolle über ihre Zertifikatsumgebung bietet. Sie erkennt und inventarisiert automatisch Zertifikate in Cloud-, On-Premises- und Hybridumgebungen, sodass Ihr Team jederzeit weiß, welche Zertifikate wo vorhanden sind. Wird eine CT-Warnung für ein bereits im Inventar vorhandenes Zertifikat ausgelöst, kann diese automatisch korreliert und bestätigt werden. Bei einer Warnung für ein unbekanntes Zertifikat meldet der CertSecure Manager dieses umgehend als Untersuchungspunkt mit vollständigen Aussteller- und Bereitstellungsinformationen.

Über die reine Erkennung hinaus automatisiert CertSecure Manager den gesamten Zertifikatslebenszyklus von der Registrierung und Ausstellung bis hin zur Verlängerung und dem Widerruf. Es setzt die richtlinienbasierte Ausstellung sowohl bei öffentlichen als auch bei privaten Zertifizierungsstellen durch, integriert sich in DevOps-Workflows und -Protokolle wie ACME und SCEP und bietet die von Compliance-Frameworks wie PCI DSS , ISO 27001 und NIST geforderte Audit-Protokollierung. Für Organisationen, die die Chrome-Vorgabe vom Juni 2026 erfüllen müssen, bedeutet dies, dass sie genau identifizieren können, welche Zertifikate neu ausgestellt werden müssen, diese über die richtige Zertifizierungsstelle weiterleiten und die CT-Konformität ohne manuelle Nachverfolgung bestätigen können.

Encryption Consulting bietet außerdem PKI-as-a-Service für Unternehmen an, die eine vollständig verwaltete private Zertifizierungsstelle benötigen, sowie PQC-Beratungsleistungen . Die gleiche Krypto-Agilität, die kürzere Zertifikatslebensdauern und die Automatisierung von Cyberkriminalitätstests heute erfordern, wird Unternehmen auch beim Übergang zu den Post-Quanten-Standards des NIST ( FIPS 203 , 204 und 205 , finalisiert im August 2024) benötigen. Da die Zertifikatslebensdauern immer kürzer werden und Automatisierung zum Standard wird, entscheidet die Verfügbarkeit der richtigen Tools und des entsprechenden Fachwissens darüber, ob Teams die Kontrolle behalten oder nur noch hektisch reagieren können.

Fazit

Die Zertifikatstransparenz wandelt jedes öffentlich vertrauenswürdige Zertifikat in einen öffentlichen Datensatz um. Die Überwachung dieses Datensatzes ist eine der einfachsten Methoden, um Zertifikate aufzuspüren, die ohne Ihre Zustimmung für Ihre Domains ausgestellt wurden. Dies funktioniert jedoch nur, wenn jemand die Protokolle tatsächlich überwacht und auf die angezeigten Informationen reagiert.

Im Jahr 2026 änderten sich zwei Dinge. Chrome verlangt nun die Protokollierung nahezu aller Zertifikate, und die Protokolle selbst wurden auf das schnellere und kostengünstigere Static CT API-Design umgestellt. Dadurch werden die CT-Daten vollständiger und einfacher zu handhaben, gleichzeitig muss aber auch das Monitoring, das auf dem alten Modell basiert, aktualisiert werden. Teams, die den größten Nutzen daraus ziehen, betrachten das CT-Monitoring nicht als eigenständigen Warnmeldungs-Feed, sondern als Teil einer umfassenderen CLM-Plattform, die die gefundenen Informationen analysieren und entsprechende Maßnahmen ergreifen kann.