2026-09-29 · RESEARCH · Das Offensive Technology Team

Certificate Transparency Log-Verzögerung: Was 1.3M Zertifikate zeigen

Kurze Antwort: Wir haben die öffentliche Certificate Transparency (CT) Historie von rund 700 stark frequentierten Domains analysiert und den angegebenen Gültigkeitsbeginn jedes Zertifikats (NotBefore) mit dem Moment verglichen, in dem es tatsächlich in einem CT-Log auftauchte. Über 1.29 Millionen protokollierten Zertifikaten von 2013 bis Mitte 2026 hinweg dauerte es bei 19.6% mehr als zwei volle Tage, bis sie in CT erschienen, und bei 15.0% mehr als eine Woche. Anschließend haben wir die Daten zum 15. Juni 2026 geteilt, als das Root-Programm von Chrome begann, für das endgültig ausgestellte Zertifikat, nicht nur für das Vorzertifikat, einen qualifizierenden CT-Log-Eintrag vorzuschreiben. Nach diesem Datum sinkt der Anteil der Zertifikate mit über 48 Stunden Verzögerung auf 1.7% und der Anteil mit über einer Woche Verzögerung auf 0.8%, in derselben Population, nach derselben Methode gemessen. Das Median-Zertifikat war bereits vor der Vorgabe schnell; was sich geändert hat, ist der Tail, also die Zertifikate, die früher tagelang, wochenlang oder monatelang unprotokolliert blieben. Jede Zahl hier stammt aus dem passiven Auslesen eines öffentlichen Logs. Es wurde kein Host kontaktiert, nichts gescannt. Hier ist genau aufgeführt, wie wir gemessen haben, welche Aussteller die Lücke am schnellsten geschlossen haben und was dies beweist und was nicht.

Zwei Zahlen, eine Richtlinienänderung

Certificate Transparency wurde geschaffen, um die Ausstellung von Zertifikaten zu einem öffentlichen, rein fortlaufenden Protokoll zu machen: Jede öffentlich vertrauenswürdige CA protokolliert die von ihr ausgestellten Zertifikate, sodass jeder, ein Domaininhaber, ein Browser, ein Analyst, sehen kann, was für einen bestimmten Namen erzeugt wurde. Der Haken war schon immer das Wörtchen "irgendwann". Eine CA ist seit 2018 verpflichtet, ein precertificate zu protokollieren und dessen signierte Zeitstempel vor der Ausstellung des endgültigen Zertifikats einzubetten, und ein branchenweites Maximum Merge Delay begrenzt die Zeit, die ein Log hat, um ein übermitteltes Vorzertifikat einzupflegen, typischerweise etwa 24 Stunden. Doch bis zu diesem Jahr gab es keine vergleichbare Frist für die Protokollierung des finalen Zertifikats selbst. Ein Zertifikat konnte signiert, datiert und bereits im produktiven Einsatz sein, während sein eigener Log-Eintrag tagelang, wochenlang oder, in mindestens einem unabhängig gemeldeten Fall, monatelang auf sich warten ließ.

Betrachten Sie den Median genau: Er hat sich kaum verändert, von 1.0 Stunden vor der Richtlinie auf 0.975 Stunden danach. Das ist kein Datenfehler, sondern das reale Bild der Verteilung. Die meisten Zertifikate der meisten Aussteller wurden schon lange vor jeder Richtlinie innerhalb einer Stunde protokolliert. Was die Vorgabe sichtbar geschlossen hat, ist der Tail: die Minderheit der Zertifikate, die früher tagelang oder wochenlang ohne öffentlichen Log-Eintrag blieben. Der Mittelwert der Verzögerung verdeutlicht das noch drastischer, da er von etwa 64 Tagen vor dem Stichtag auf 6.7 Stunden danach fiel, weil ein Mittelwert genau von den Ausreißern beeinflusst wird, die ein Median verschleiert.

Der Mechanismus: eine Frist für Vorzertifikate, keine Frist für den Rest

Das ursprüngliche Design von Certificate Transparency protokolliert ein precertificate, einen Platzhalter mit Poison Extension, der es einer CA ermöglicht, Signed Certificate Timestamps zu sammeln, bevor sie das eigentliche Zertifikat signiert. Mehrere öffentliche CT-Logs müssen dieses Vorzertifikat innerhalb eines begrenzten Maximum Merge Delay, in der Größenordnung eines Tages, annehmen und mergen, und Browser erzwingen seit 2018, dass Logs dies einhalten. Dieser Teil der Pipeline war immer zeitnah, weshalb die Branche behaupten konnte, dass "CT verpflichtend ist" im Großen und Ganzen zutrifft.

Die Lücke war die andere Hälfte: Nichts zwang die CA dazu, das endgültig ausgestellte Zertifikat nach einem bestimmten Zeitplan an ein Log zu übermitteln. Eine CA konnte ihre SCTs aus dem Vorzertifikat beziehen, einbetten, das Zertifikat ausstellen und in den Produktivbetrieb überführen, alles völlig vorschriftsmäßig, während der eigene CT-Log-Eintrag des finalen Zertifikats wartete. Ein unabhängig gemeldeter Fall beschreibt ein von DigiCert ausgestelltes Wildcard-Zertifikat für eine große Plattform, bei dem zwischen der angegebenen Ausstellung und dem Erscheinen in CT eine Lücke von etwa drei Monaten klaffte (wir haben diesen konkreten Fall nicht unabhängig verifiziert; betrachten Sie ihn als anschauliche, nicht verbindliche Anekdote). Unsere eigenen Daten zeigen dasselbe Muster im Maßstab der gesamten Population: Vor der Vorgabe lag ein signifikanter Anteil der Zertifikate mehrerer großer CAs mehr als eine Woche lang ohne öffentlichen Log-Eintrag vor. Genau auf diese Lücke zielt die Chrome-Richtlinie vom Juni 2026 ab, indem sie vorschreibt, dass das finale Zertifikat selbst einen qualifizierenden Log-Eintrag aufweisen muss.

Welche Aussteller die Lücke geschlossen haben und um wie viel

Wir nennen hier Certificate Authorities beim Namen, nicht die Domains, deren Zertifikate wir gezählt haben. Die Logging-Praxis einer CA ist eine Information von öffentlichem Interesse über die CA selbst, genauso wie eine frühere Untersuchung von uns beleuchtet hat, welche CAs von Domains autorisiert werden, für sie auszustellen. Für jeden Aussteller mit einer soliden Stichprobe auf beiden Seiten des Stichtags ist hier der Anteil seiner Zertifikate aufgeführt, die mehr als 48 Stunden nach NotBefore protokolliert wurden, vor und nach dem 15. Juni 2026:

Zwei Dinge stechen hervor. Erstens lagen Let’s Encrypt und Sectigo bereits vor der Richtlinie nahe null, was dazu passt, dass beide hochgradig automatisierte Ausstellungspipelines im großen Maßstab betreiben, bei denen "Ausstellen und Protokollieren" fast ein einziger atomarer Schritt ist. Zweitens haben sich die CAs mit dem größten Nachholbedarf, DigiCert, Amazon und Google Trust Services, deutlich verbessert und ihren Anteil verspäteter Protokollierungen um etwa das Vier- bis Siebenfache reduziert. Wir konnten nicht für jeden Aussteller eine verlässliche Vorher-Nachher-Zeile erstellen: GlobalSign, COMODOs Altmarke und ZeroSSL wiesen in unserer Stichprobe nach der Richtlinie entweder zu wenige Zertifikate auf, um belastbare Aussagen zu treffen (weniger als ein paar Dutzend), oder keine unserer beobachteten Domains hat seit dem 15. Juni 2026 über sie verlängert. Das ist eine Einschränkung unserer Domain-Stichprobe, kein Urteil über diese Aussteller.

Wie wir das gemessen haben

Ein Skeptiker sollte in der Lage sein, dies von Grund auf nachzuvollziehen, daher legen wir die gesamte Methode lückenlos offen.

• Die Grundgesamtheit. Rund 700 Domains aus der Tranco Top-1.000-Liste, zusammengestellt aus mehreren unserer jüngsten Passive-DNS-Studien. Für jede Domain haben wir die vollständige Certificate Transparency Historie bei crt.sh ausgelesen, was jedes protokollierte Zertifikat für diese Domain und ihre Subdomains bis zurück ins Jahr 2013 liefert.
• Die Metrik. Für jedes protokollierte Zertifikat haben wir sein not_before-Feld (der angegebene Gültigkeitsbeginn des Zertifikats) mit entry_timestamp verglichen (dem Zeitpunkt, an dem crt.sh diesen Log-Eintrag erfasst hat). Die Differenz ist die von uns angegebene Verzögerung. Wir haben anhand der internen Eintrags-ID von crt.sh dedupliziert und eine Handvoll Einträge mit einer unplausiblen Differenz (mehr als fünf Jahre) verworfen, die wir als Artefakte von Uhren oder Parsing-Prozessen und nicht als reales Ausstellungsverhalten werten.
• Die Aufteilung. Wir haben jedes Zertifikat danach eingeteilt, ob sein NotBefore vor oder am/nach dem 15. Juni 2026 lag, dem Datum des Inkrafttretens der Chrome Root Program Anforderung, dass das endgültig ausgestellte Zertifikat einen qualifizierenden CT-Log-Eintrag tragen muss. Unsere zwischengespeicherten Daten reichen bis zum 24. Juli 2026, sodass das Zeitfenster nach der Richtlinie etwa die ersten sechs Wochen unter der neuen Regel umfasst, kein ganzes Jahr. Betrachten Sie die Zahlen nach der Richtlinie als frühe Tendenz, von der wir erwarten, dass sie sich festigt, nicht als etablierten Trend.
• Was wir nicht getan haben. Wir haben zu keinem Zeitpunkt ein Zertifikat angefordert, uns mit einem Webserver verbunden oder irgendetwas gescannt. Das Auslesen eines öffentlichen CT-Logs ist ein Lookup, kein Scan, dieselbe Grenze, die für jedes unserer Mandate gilt.
• Was wir behalten haben. Aggregierte Zählwerte, Mediane und Perzentile, pro Aussteller und pro Zeitraum. In den Daten taucht kein Domain- oder Subdomain-Name auf, und wir haben keine personenbezogenen Daten erhoben; Domainnamen und öffentliche Zertifikatsmetadaten sind keine personenbezogenen Daten.

Was dies nicht beweist

Ehrliche Grenzen, denn eine Zahl ohne ihre Einschränkungen ist reines Marketing.

• Das Zeitfenster nach der Vorgabe ist kurz. Sechs Wochen Daten reichen aus, um den Verlauf der Veränderung aufzuzeigen, nicht aber, um sie als dauerhaft zu bestätigen. Ein Teil der Verbesserung könnte auf anfängliche, vorsichtige Compliance zurückzuführen sein, die mit der Zeit wieder nachlässt; wir planen, dies erneut zu prüfen.
• Nicht jeder Aussteller liefert ein verlässliches Nachher-Bild. Eine Handvoll großer CAs hatte in unserer spezifischen Stichprobe von 700 Domains schlicht zu wenige Zertifikate nach Inkrafttreten der Richtlinie, um belastbare Aussagen zu ermöglichen. Eine breitere Domain-Stichprobe würde diese Lücke schließen.
• NotBefore ist kein perfekter Indikator dafür, wann das Zertifikat tatsächlich signiert wurde. Eine CA kann NotBefore zur Toleranz von Clock-Skew geringfügig in die Vergangenheit legen. Diese Praxis würde unseren Verzögerungswert selbst bei einer prompt protokollierenden CA minimal erhöhen; Lücken von Tagen oder Wochen erklärt sie jedoch nicht.
• Dies ist eine Verzögerungsmessung, kein Befund über Fehl-Ausstellungen. Ein spät protokolliertes Zertifikat ist kein Beweis dafür, dass das Zertifikat unberechtigt ausgestellt wurde, sondern nur dafür, dass der öffentliche Audit-Trail hinter seiner Nutzung zurückblieb. Das Risiko liegt in der Audit-Lücke selbst: Solange ein Zertifikat unprotokolliert bleibt, würde niemand, der CT für seine eigene Domain überwacht, etwas davon bemerken.
• Die Grundgesamtheit neigt zu stark frequentierten Domains. Die Top 1.000 von Tranco stützen sich stark auf ressourcenstarke Organisationen und große CDNs; das Ausstellungsverhalten für den Long Tail kleinerer Websites, die häufig dieselben großen CAs, aber über andere Automatismen nutzen, kann abweichen.

Warum das wichtig ist

Das gesamte Nutzenversprechen von Certificate Transparency für einen Domaininhaber besteht darin, dass man das öffentliche Log für den eigenen Namen überwachen und ein unerwartetes Zertifikat erkennen kann, bevor es gegen einen verwendet wird. Das funktioniert nur, wenn die Protokollierung zeitnah zur Ausstellung erfolgt. Ein Zertifikat, das einen Monat lang unprotokolliert bleibt, war genau in diesem Zeitraum aktiv, von jedem Browser als vertrauenswürdig eingestuft und für jeden, der CT überwacht, unsichtbar. Die Lücke, die diese Vorgabe schließt, ist nicht exotisch; es ist der schlichte Unterschied zwischen "wir halten Certificate Transparency formal ein" und "man kann tatsächlich zeitnah und jedes Mal sehen, was wir ausgestellt haben". Die Daten zeigen, dass die schnellsten Aussteller der Branche, darunter Let’s Encrypt und Sectigo, dies bereits als einen einzigen atomaren Schritt behandelt haben, lange bevor eine Richtlinie dies verlangte. Der Rest holt nun sichtbar auf, nachdem das Root-Programm von Chrome dies von einer Best Practice zu einer Pflicht gemacht hat. Genau dasselbe Bild zeigte sich, als wir untersucht haben, wer produktive CT-Logs tatsächlich bezeugt: Die Teile dieses Ökosystems, die durchgesetzt werden, bewegen sich schnell, und die Teile, die lediglich empfohlen werden, tun es nicht.

Certificate Transparency Log-Verzögerung: Kurze Antworten

Was ist Certificate Transparency Log-Verzögerung?

Die Differenz zwischen dem angegebenen Gültigkeitsbeginn eines TLS-Zertifikats (NotBefore) und dem Zeitpunkt, an dem es tatsächlich in einem öffentlichen CT-Log erscheint. Eine kurze Spanne bedeutet, dass der öffentliche Audit-Trail mit der Ausstellung Schritt hält; eine lange Spanne bedeutet, dass ein gültiges, nutzbares Zertifikat über einen Zeitraum existierte, ohne dass es einen öffentlichen Datensatz darüber gab.

Verlangt Chrome, dass alle Zertifikate in CT protokolliert werden?

Die Richtlinie des Chrome Root Program verlangt für Zertifikate, die am oder nach dem 15. Juni 2026 ausgestellt werden, dass das final ausgestellte Zertifikat, nicht nur das Vorzertifikat, einen qualifizierenden CT-Log-Eintrag trägt; nach diesem Datum ausgestellte Zertifikate ohne einen solchen Eintrag werden von Chrome nicht als vertrauenswürdig eingestuft. Die Protokollierung von Vorzertifikaten war bereits seit 2018 vorgeschrieben.

Warum konnte ein Zertifikat gültig sein, bevor es protokolliert wurde?

CT erfordert die Protokollierung eines Vorzertifikats, bevor das endgültige Zertifikat ausgestellt wird, und Maximum Merge Delay Regeln (etwa 24 Stunden) begrenzen, wie lange das dauert. Bis zur Chrome-Richtlinie vom Juni 2026 gab es keine vergleichbare Frist für die Protokollierung des endgültigen Zertifikats selbst, sodass es signiert, datiert und verwendet werden konnte, während der eigene Log-Eintrag hinterherhinkte, mitunter um Monate.

Wie wurde dies gemessen?

Passiv. Wir haben die öffentliche CT-Historie von rund 700 Tranco Top-1.000-Domains über crt.sh ausgelesen und das NotBefore jedes Zertifikats mit dem Zeitstempel seines Log-Eintrags verglichen. Es wurde kein Host kontaktiert, aufgelöst oder gescannt. Das Ergebnis sind 1.29 Millionen Log-Einträge von 2013 bis Mitte 2026, getrennt am Stichtag der Vorgabe vom 15. Juni 2026.

Weiterführende Analysen

• Certificate Transparency Post-Quantum: 43% der Static-CT-Logs signieren bereits mit ML-DSA-44.
• Wie viele Top-Domains schränken die Zertifikatsausstellung ein?
• Was die Zertifikate beweisen.