Der Schlüssel war 4: Wer entscheidet, welchen Websites Ihre Software vertraut

Dies ist ein maschinell übersetzter Artikel. Die Originalfassung ist auf Englisch verfügbar.

Zuletzt aktualisiert: 25. Oktober 2026 · 19 Min. Lesezeit

Wir haben hier ein Problem

Am Samstag, dem 17. Oktober 2026, um 18:05 Uhr UTC ging beim Root-Programm von Chrome die Meldung eines Sicherheitsforschers ein, der öffentlich nur als Wayne bekannt ist. Er gab an, die privaten Schlüssel von acht Zertifizierungsstellen zu besitzen, die eMudhra betreibt, ein börsennotiertes Unternehmen mit Sitz im indischen Bengaluru. Zum Beweis hatte er mit jedem der acht Schlüssel dieselbe kurze Nachricht signiert: „Wir haben hier ein Problem – Wayne.“

Einbrechen musste er dafür nirgends. Sobald die Nachricht öffentlich war, beschrieb der Sicherheitsforscher Scott Helme, wie die Schlüssel aussahen. Einer von ihnen war schlicht die Zahl 4. Zwei andere waren 56 und 115. Helme sagte, er habe sie alle auf seinem Laptop aus den öffentlichen Zertifikaten zurückgewonnen, und das habe weniger als eine Sekunde gedauert. Eine unabhängige Prüfung durch Journalisten bestätigte, dass der private Schlüssel hinter eMudhras „EM OV TLS CA – G3C“ die 4 war.

Die acht waren Zwischenzertifizierungsstellen, die arbeitende Ebene eines Zertifikatsanbieters, die Nachweise für andere signiert. Sechs von ihnen durften Zertifikate für Websites ausstellen, und diese sechs genossen das Vertrauen der Root-Programme von Chrome, Mozilla, Microsoft und Apple. Die anderen beiden dienten der Codesignierung, also den Zertifikaten, mit denen Softwarehersteller ihre Programme signieren, und Microsoft vertraute ihnen. Ihre Schlüssel waren fehlerhaft erzeugt worden, sodass jeder, der wusste, wo er suchen musste, sie aus den Zertifikaten selbst berechnen konnte, die ja bewusst öffentlich sind. Das war möglich, seit die Zertifikate im April 2025 erstellt worden waren.

Um 19:45 Uhr UTC, eine Stunde und vierzig Minuten nach Eingang der Meldung, hatte Chrome die Befunde bestätigt und eine Sperre an seine Nutzer verteilt. Niemand musste ein Update installieren oder den Browser neu starten.

Auf das Tempo kam es an, weil man mit einem solchen Schlüssel einiges anrichten kann. Wer einen der sechs Website-Schlüssel besaß und die Verbindung eines Menschen abfangen konnte, hätte ein gefälschtes Zertifikat für eine Bank, einen E-Mail-Dienst oder jede andere Website vorlegen können, ganz gleich, welchen Zertifikatsanbieter die echte Website nutzte, und Software, die der Kette von eMudhra vertraute, hätte es akzeptiert. Im Weg standen vor allem zwei Schutzmechanismen: ein öffentliches Protokollierungssystem namens Certificate Transparency, auf dem manche Software besteht, ein Großteil aber nicht, und was immer an Sperren die jeweilige Software rechtzeitig erreichte.

Ob ein gefälschtes Zertifikat funktioniert hätte, hing von Entscheidungen ab, die normalerweise unsichtbar bleiben: wer für eine Website bürgt, wer entscheidet, dass man diesem Bürgen glauben soll, und wie schnell sich dieser Glaube zurückziehen lässt, wenn sich der Bürge als defekt erweist.

Wofür ein Zertifikat bürgt

Ein Website-Zertifikat ist ein kleines signiertes Dokument, das einen Namen, etwa die Webadresse einer Bank, an einen öffentlichen Schlüssel bindet. Öffentliche Schlüssel bilden jeweils ein Paar mit einem privaten Schlüssel. Der private Schlüssel bleibt geheim und erzeugt digitale Signaturen; mit dem öffentlichen Schlüssel kann jeder prüfen, ob eine Signatur von seinem Gegenstück stammt. Wenn sich Ihr Browser mit einer Website verbindet, beweist die Website, dass sie den privaten Schlüssel besitzt, der zum öffentlichen Schlüssel in ihrem Zertifikat passt. Das Zertifikat selbst besagt, dass dieser öffentliche Schlüssel zu diesem Namen gehört, und eine Zertifizierungsstelle, kurz CA, steht für diese Aussage ein, indem sie sie signiert.

Bevor die CA ein Website-Zertifikat signiert, muss sie prüfen, ob der Antragsteller die Domain kontrolliert. Eine zugelassene Methode besteht darin, dem Antragsteller einen Zufallswert zu geben und diesen dann in den DNS-Einträgen der Domain zu suchen, dem öffentlichen Adressbuch des Internets, wo ihn nur jemand hinterlegt haben kann, der die Domain kontrolliert. Die CA kann außerdem bestätigen, dass der Antragsteller wirklich den privaten Schlüssel besitzt, den er zertifizieren lassen will, und zwar mit einem technischen Test namens Proof of Possession, obwohl der zugrunde liegende Standard ihr auch erlaubt, sich auf das Wort des Antragstellers zu verlassen.

Kein Browser könnte jede CA der Welt selbst überprüfen, deshalb wird Vertrauen entlang einer Kette delegiert. An der Spitze stehen Stammzertifikate, die Root-Zertifikate, gespeichert in einer Liste namens Vertrauensspeicher, die mit Ihrem Betriebssystem oder Browser ausgeliefert wird. Root-Zertifikate autorisieren Zwischen-CAs, und diese stellen die Zertifikate aus, die Websites verwenden. Wenn Ihre Software das Zertifikat einer Website sieht, folgt sie den Signaturen nach oben, von der Website zu einem Zwischenzertifikat und weiter zu einem Root-Zertifikat, und akzeptiert die Website nur, wenn die Kette bei einem Root-Zertifikat in ihrem Speicher endet, jede Signatur stimmt, das Zertifikat noch gültig ist und den aufgerufenen Namen abdeckt und keine der übrigen Regeln der Software es verbietet.

Root-Programme, betrieben von Betriebssystem- und Browserherstellern wie Apple, Google, Microsoft und Mozilla, prüfen Zertifizierungsstellen und entscheiden, welche Root-Zertifikate in den Speicher kommen. Deshalb ist der private Schlüssel einer Zwischen-CA so wertvoll. Sofern sie nicht auf bestimmte Namen beschränkt wurde, was bei eMudhra nicht der Fall war, kann eine Zwischen-CA ein Zertifikat für jede beliebige Domain signieren, und dieses Zertifikat lässt sich nach oben bis zu einem vertrauenswürdigen Root-Zertifikat verifizieren. Der Schlüssel des Root-Zertifikats selbst kann weggeschlossen bleiben; der Schlüssel der Zwischen-CA erledigt das tägliche Signieren, und wenn er in fremde Hände gerät, gerät die Beglaubigung durch das Root-Zertifikat gleich mit dorthin.

Nichts davon sagt Ihnen, ob eine Website ehrlich ist, auch wenn das Schloss-Symbol des Browsers weithin so verstanden wird. Als Google der Frage 2021 nachging, verstanden nur 11 % der Teilnehmenden richtig, was das Schloss bedeutete, und fast alle Phishing-Seiten nutzten HTTPS und zeigten es deshalb ebenfalls an. 2023 kündigte Google an, dass Chrome das Schloss durch ein anderes Symbol ersetzen werde. Ein einfaches Zertifikat besagt nur, dass die Verbindung zu demjenigen führt, der den Schlüssel für diesen Namen besitzt. Manche Zertifikate nennen zusätzlich die Organisation hinter der Website; keines bürgt für ihre Absichten.

Es gibt noch eine weitere Ebene. Certificate Transparency, 2013 von Google-Ingenieuren beschrieben, trägt Zertifikate in öffentliche Logs ein, in denen jeder überprüfen kann, was jede CA ausgestellt hat. Ihre Entwickler sahen vor, dass Clients irgendwann jedes nicht protokollierte Zertifikat ablehnen würden, sodass ein Zertifikat, das in den Logs fehlt, ob von einer CA ausgestellt oder von einem Dieb mit dem Schlüssel einer CA, abgewiesen würde. Chrome tut das standardmäßig bei jeder Verbindung, die sich auf seinen Root Store stützt.

Die Warnung, auf die niemand reagierte

Die Regeln für das Erzeugen von CA-Schlüsseln sind streng. Für Root-Schlüssel und bestimmte Schlüssel von Zwischen-CAs verlangen die Baseline Requirements der Branche, das Regelwerk, das die Root-Programme der Browser und die CAs gemeinsam pflegen, dass die CA einem schriftlichen Skript zur Schlüsselerzeugung folgt und die Zeremonie von einem qualifizierten Prüfer bezeugen oder vollständig auf Video aufzeichnen lässt. Jeder CA-Schlüssel muss von mehreren Personen gemeinsam erzeugt werden, von denen keine allein über das gesamte dafür nötige Wissen verfügt.

Am 30. April 2025 erstellte eMudhra einen Satz von 24 Zwischen-CAs. Sie kamen in drei Serien, A, B und C, mit zwei Schlüsselarten, RSA und dem auf elliptischen Kurven beruhenden Typ P-384, und vier Verwendungszwecken. Die acht defekten Schlüssel waren sämtliche P-384-Schlüssel der Serien B und C. Alle acht waren ganze Zahlen kleiner als 256. Voll ausgeschrieben war jeder eine lange Reihe von Nullen mit irgendetwas im letzten Byte.

Warum dieser Schlüssel zu erraten war

Ein privater Schlüssel auf der Kurve P-384 ist schlicht eine Zahl, zufällig gewählt zwischen 1 und einer festen Obergrenze, die selbst 384 Bit lang ist. Der öffentliche Schlüssel wird aus dem privaten durch eine Rechnung gewonnen, die vorwärts leicht auszuführen und bei einer echt zufälligen Zahl rückwärts aussichtslos ist. Er steht im Zertifikat. Die Zahl 4 ist ein völlig zulässiger privater Schlüssel; sie ist aber auch eine der ersten Zahlen, die jeder ausprobieren würde. Mozilla wies darauf hin, dass sich so kleine Schlüssel nahezu sofort zurückgewinnen lassen: Man berechnet die öffentlichen Schlüssel für 1, 2, 3 und so weiter bis 256 und vergleicht jeden mit dem im Zertifikat. Stimmen zwei überein, ist der private Schlüssel die Zahl, mit der man begonnen hat. Ein echt zufälliger Schlüssel bietet keine solche kurze Liste. Wie Scott Helme es formulierte, umfasst der Bereich rund 10 hoch 115 Möglichkeiten, „also wird das nie jemand durchsuchen“. Mozillas Dennis Jackson übergab die Aufgabe außerdem lokal laufenden KI-Agenten. Sie gewannen den Schlüssel mit einem einfachen Prompt schon beim ersten Versuch zurück.

Wie konnte eine Schlüsselzeremonie so kleine Zahlen hervorbringen? eMudhras vorläufige Erklärung, veröffentlicht am 19. Oktober, lautet, das an jenem Tag verwendete Skript sei fehlerhaft gewesen. Das Unternehmen gibt an, es habe eine einmalige Abweichung vom üblichen Verfahren genehmigt, um den Export der Schlüssel zu testen; ein Programmierfehler habe die Hardware veranlasst, neben den eigentlichen Schlüsselpaaren ein zweites, schwächeres Schlüsselpaar zu erzeugen, und die schwachen Schlüssel seien dann versehentlich für die Zertifikatsanträge verwendet worden, weil ihre Bezeichnungen ähnlich aussahen. Nach eigenen Angaben wurden die Schlüssel in Hardware-Sicherheitsmodulen von Utimaco erzeugt, den manipulationssicheren Geräten, die CA-Schlüssel erzeugen und schützen sollen.

eMudhra bezeichnet die Darstellung selbst als vorläufig, und sie lässt das zentrale Rätsel offen. Ein Kommentator in Mozillas öffentlichem Bug-Eintrag merkte an, entweder seien die Schlüssel außerhalb der sicheren Hardware erzeugt und entgegen den Richtlinien hineingeladen worden, oder die Hardware lasse sich irgendwie so konfigurieren, dass sie selbst fehlerhafte Schlüssel erzeugt. Ein anderer Teilnehmer vermutete auf Mozillas öffentlicher Mailingliste, ohne Bestätigung, eine Software habe eine kleine Datei, die auf den echten Schlüssel in der Hardware verweist, für den Schlüssel selbst gehalten. Mozilla gelang es trotz deutlich größerer Anstrengungen nicht, die P-384-Schlüssel der A-Serie aus demselben Satz zurückzugewinnen. Am 20. Oktober schickte Mozilla eMudhra Fragen mit einer Frist von 24 Stunden; Stand 23. Oktober war keine Antwort eingegangen, und wie die schwachen Schlüssel entstanden waren, war nicht erklärt worden.

Dokumentiert ist dagegen, dass sich das Problem schon mehr als ein Jahr zuvor gezeigt hatte. Im Juni 2025 zeigte ein öffentlicher Überwachungsdienst, dass eMudhra für ebendiese Zwischen-CAs sechs Zertifikatssperrlisten mit ungültigen Signaturen ausgab. Eine Sperrliste, kurz CRL, ist ein signiertes Verzeichnis der Zertifikate, die eine CA widerrufen hat, und ihre Signatur muss sich mit dem öffentlichen Schlüssel im Zertifikat der CA verifizieren lassen. Laut eMudhras damaligem Bericht hatte Sectigo, ein anderer Zertifikatsanbieter, das Unternehmen am 3. Juni 2025 erstmals per E-Mail gewarnt, doch die Nachricht war von internen Filtern in Quarantäne verschoben und nicht gesehen worden. Die fehlerhaften Listen wurden am 6. Juni ersetzt.

Im Oktober 2026 erklärte eMudhra, worin diese Korrektur bestanden hatte. Die Listen waren zunächst mit den ursprünglichen, ordnungsgemäß zufälligen Schlüsseln signiert worden; weil die Zertifikate aber die öffentlichen Hälften der schwachen Schlüssel enthielten, schlugen diese Signaturen fehl, und das Unternehmen signierte die Listen mit den fehlerhaften Schlüsseln neu. Im Juni 2025 hatte eMudhra also den Beleg in der Hand, dass seine Zertifikate nicht zu den Schlüsseln passten, die es zu verwenden glaubte, und es reparierte die Listen.

Das Root-Programm von Chrome fragte, warum eMudhra die Listen einfach neu signiert hatte, statt den Betrieb einzustellen, zu untersuchen, warum für diese CAs zwei Schlüsselpaare existierten, und die Zertifikate zu widerrufen. eMudhra gibt an, seine Root-Zertifikate und ausstellenden CAs hätten zwei Jahre hintereinander unabhängige Audits durchlaufen. Am 14. Oktober 2026, drei Tage vor Waynes Meldung, veröffentlichte das Unternehmen eine Sperrliste für ein anderes Root-Zertifikat, emSign Root TLS CA – G1, deren Signatur sich ebenfalls nicht verifizieren ließ.

Zwei Arten von Ausschalter

Chromes erster Schritt war schnell, weil er auf Schlüssel zielte. Chrome führt eine Blockliste namens CRLSet, die Google im Hintergrund an die Browser verteilt. Das Update, das um 19:45 Uhr UTC ankam, sperrte die Fingerabdrücke der öffentlichen Schlüssel der sechs Zwischen-CAs. Weil die Sperre Schlüssel benannte, erfasste sie jedes Zertifikat, das diese Schlüssel verwendete, auch jedes, das ein Fälscher später noch erzeugen mochte. Mozilla sperrte die Zertifikate in Firefox über seine eigene Liste, OneCRL, und war um 22:59 Uhr UTC fertig. OneCRL funktioniert, ohne dass Nutzer Firefox aktualisieren oder auch nur neu starten müssen.

Eine im Hintergrund verteilte Liste schützt nur die Software, die sie empfängt. Am 20. Oktober veröffentlichte Mozilla ein Firefox-Update für Nutzer, bei denen die Konfiguration verhindert hatte, dass die Blockliste ankam, und später eine Korrektur für einige Profile von Firefox für Android, die sie nicht anwandten. Google begann am Montag, dem 19. Oktober, gegen 22:00 Uhr UTC, eine entsprechende Sperre über die Google Play-Dienste an Android-Geräte zu senden, und erklärte am folgenden Tag, die meisten hätten sie erhalten. Microsoft und Apple folgten innerhalb weniger Tage, wobei veröffentlichte Darstellungen beim genauen Datum von Apples Maßnahme auseinandergehen.

Auch die Zertifizierungsstellen handelten. eMudhra hatte bis 09:38 Uhr UTC am 18. Oktober alle acht Zertifikate als widerrufen markiert und als Grund eine Kompromittierung der CA angegeben. Sectigo, das die Zwischen-CAs cross-signiert hatte, schloss den Widerruf seiner Cross-Zertifikate am 19. Oktober ab. Chrome sorgte außerdem dafür, dass die Certificate-Transparency-Logs jedes Zertifikat zurückwiesen, dessen Kette zu den kompromittierten CAs führte, sodass ein gefälschtes Zertifikat nicht mehr die Log-Einträge sammeln konnte, die CT-prüfende Software verlangt.

Das schwerere Werkzeug besteht darin, das Root-Zertifikat zu entfernen, das die Zwischen-CAs autorisiert hatte. Am 20. Oktober beschloss Mozilla mit dem Hinweis, dass inzwischen mehrere Personen die Schlüssel unabhängig voneinander zurückgewonnen hätten, die Notfallentfernung von emSign ECC Root CA – G3, dem eMudhra-Root-Zertifikat über den defekten Zwischen-CAs, aus seinem Vertrauensspeicher. Firefox brauchte das nicht; OneCRL deckte Firefox bereits ab. Es ging um alle anderen, die Mozillas Root-Liste oder eine davon abgeleitete ohne OneCRL nutzen. Mozilla warnte, dass einige Server für diese Nutzer durch die Änderung unerreichbar würden, bis sie auf neue Zertifikatsketten umgestellt hätten.

Chrome entfernte dasselbe Root-Zertifikat aus seinem Speicher. Google erwartete, dass die Änderung alle Geräte, die sich auf den Chrome Root Store stützen, am Dienstagmorgen, dem 27. Oktober 2026, pazifischer Zeit, erreichen würde, die Testversionen Canary und Beta schon früher. Google sagte unumwunden, dass manche legitimen Zertifikate, deren Kette zu diesem Root-Zertifikat führt, in Chrome deshalb nicht mehr funktionieren würden.

Die beiden Schalter unterscheiden sich darin, was sie erfassen und wen sie treffen. Die Entfernung eines Root-Zertifikats kappt jeden Pfad über dieses Root-Zertifikat, auch die ehrlicher Websites, verfehlt aber Pfade über andere Root-Zertifikate, und eMudhras Zwischen-CAs hatten noch einen weiteren. Sectigo hatte sie cross-zertifiziert und dieselben Schlüssel damit an ein Root-Zertifikat namens AAA Certificate Services gebunden, das unter dem Namen Comodo ausgestellt worden war. Chrome hatte dieses Root-Zertifikat im April 2025 aussortiert, doch manche Systeme vertrauten ihm noch: Ubuntu entfernte emSign ECC Root CA – G3 aus allen unterstützten Versionen und aus älteren Versionen, die das Comodo-Root-Zertifikat noch mitführten, zusätzlich auch dieses. Eine Sperre, die am Zwischenzertifikat selbst ansetzt, erfasst jeden Weg auf einmal. Die Programmiersprache Go ging so vor: Ab den am 19. Oktober veröffentlichten Versionen filtert die Zertifikatsprüfung von Go jede Kette heraus, die eine der kompromittierten Zwischen-CAs enthält, ganz gleich, bei welchem Root-Zertifikat sie endet.

Die Updates aller anderen

Am 18. Oktober schrieb Mozilla in seinem öffentlichen Bug-Eintrag, man sorge sich um das weitere Ökosystem, weil viele Endpunkte keinen wirksamen Weg hätten, Widerrufsinformationen zu empfangen. Browser hatten ihre Hintergrundlisten. Viele andere Programme, die sichere Verbindungen aufbauen, haben nichts Vergleichbares.

Die Website zur Verfolgung des Vorfalls, eine öffentliche Seite, die Mozillas Dennis Jackson eingerichtet hatte, führte auf, wer exponiert war. Anwendungen und Bibliotheken, die ihr eigenes Bündel vertrauenswürdiger Root-Zertifikate mitbringen, brauchten Software-Updates. Das galt auch für Apps, die auf Electron aufbauen, dem Framework hinter Desktop-Programmen wie Slack und Discord, und die Electrons Korrektur erst übernehmen, wenn sie auf einer gepatchten Version neu gebaut werden.

Manche Lücken steckten in den eigenen Vertrauensdateien der Betriebssysteme. Stand 22. Oktober meldete die Vorfallsseite, dass macOS die kompromittierten Zwischen-CAs sperrte, seine eingebauten Kommandozeilenwerkzeuge, darunter curl, git und python3, Zertifikate aber gegen eine separate Datei prüften, ohne den Widerrufsstatus abzufragen, und dass diese Datei nicht aktualisiert worden war. Unter Ubuntu musste Javas Vertrauensspeicher nach dem System-Update wegen eines Synchronisierungsproblems, das Canonical bis zum 22. Oktober nicht behoben hatte, von Hand nachgezogen werden, und Browser, die als Snap-Pakete installiert waren, nutzten den Systemspeicher überhaupt nicht.

Andere Lücken steckten in Bibliotheken, die ihre eigenen Listen mitführen. Go lieferte seine Korrektur mit den Sicherheitsversionen 1.27.3 und 1.26.10 aus, unter CVE-2026-111943. Pythons weitverbreitetes Zertifikatsbündel certifi entfernte am 18. Oktober alle vier emSign-Root-Zertifikate und stellte dann die drei nicht betroffenen in einer Version mit dem Tag 2026.10.19 wieder her; eine automatisierte Version vom 23. Oktober strich zwei dieser drei erneut. Und manche Produkte konnten nur ihre Hersteller reparieren: Ciscos Sicherheitsteam Talos hob virtuelle private Netzwerke als Produkte hervor, die wahrscheinlich Updates benötigen würden.

Unter alledem lag Certificate Transparency. Die meisten Browser setzen sie durch, viele Clients, die keine Browser sind, aber nicht, darunter curl. Ein gefälschtes Zertifikat, das mit einem der eMudhra-Schlüssel erstellt und nie protokolliert worden wäre, hätte Chrome abgelehnt, diese Clients aber hätten es akzeptieren können, solange sie der Kette von eMudhra noch vertrauten und nichts anderes es aufhielt, etwa eine App, die nur die bekannten Zertifikate ihrer eigenen Server akzeptiert.

Vieles spricht dafür, dass das System funktioniert hat. Bevor Chrome am 17. Oktober die Sperre setzte, war kein Website-Zertifikat, dessen Kette zu den sechs Zwischen-CAs führte, in Certificate Transparency protokolliert worden; zwischen der Erzeugung der Schlüssel im April 2025 und dieser Sperre hätte also kein damit gefälschtes Zertifikat gegen Clients eingesetzt werden können, die CT durchsetzen. Talos erklärte, Stand 21. Oktober, 14:00 Uhr UTC, keinen böswilligen Einsatz in freier Wildbahn beobachtet zu haben. eMudhra gibt an, nur eine der betroffenen Zwischen-CAs sei je in Produktion gegangen, und keine von ihnen habe je ein Zertifikat für eine Website oder einen Softwarehersteller ausgestellt.

Für Software, die CT die ganze Zeit durchgesetzt hat, trifft dieses Argument zu, und der Schutz kam von einer dauerhaft geltenden Regel, nicht vom Notfalleinsatz des Wochenendes. Seine Reichweite ist geringer, als die Formel „das System hat funktioniert“ nahelegt. Firefox für Android setzt Certificate Transparency erst seit Version 145 durch, die den Nutzern am 11. November 2025 erstmals angeboten wurde. Android-Apps können eingebaute CT-Prüfungen erst ab Android 16 nutzen und erhalten sie standardmäßig nur, wenn sie für Android 17 gebaut sind.

Der Notfalleinsatz zählte auch für das, was danach kam. Mozillas erste Benachrichtigung an die nachgelagerten Betreuer von Vertrauensspeichern verschwieg bewusst, dass die Schlüssel von jedermann zurückgewonnen werden konnten. Spätestens am 20. Oktober spielte das kaum noch eine Rolle: Mehrere Personen hatten sie unabhängig voneinander zurückgewonnen, und Helme hatte alle acht Werte veröffentlicht. Sobald die Schlüssel praktisch öffentlich waren, standen die Sperren und die Zurückweisung durch die CT-Logs zwischen ihnen und jeder neuen Fälschung. Bis zum 24. Oktober war nichts veröffentlicht worden, das zeigte, ob Angreifer die fehlerhaften Schlüssel zwischen April 2025 und Oktober 2026 gegen Clients ohne CT eingesetzt hatten.

Wer den Schalter in der Hand hat

Darüber, welchen Root-Zertifikaten Browser und Betriebssysteme vertrauen, entscheiden die Root-Programme, und deren Regeln lassen ihren Betreibern viel Spielraum. Laut Chromes Richtlinie nimmt Google Zertifikate „nach alleinigem Ermessen“ auf oder entfernt sie, und jedes aufgenommene Zertifikat muss den Nutzern einen Wert bieten, der das Risiko seines Verbleibs übersteigt. Mozillas Richtlinie besagt, dass Mozilla ein Zertifikat nach alleinigem Ermessen jederzeit und aus jedem Grund deaktivieren oder entfernen kann. Mozilla gibt außerdem an, für die Aufnahme keine Gebühren zu verlangen.

Dieser Ermessensspielraum wurde auf unterschiedliche Weise genutzt. Als 2014 Indiens National Informatics Centre unautorisierte Zertifikate für mehrere Google-Domains ausstellte, warf Chrome das darüberliegende Root-Zertifikat der India CCA nicht hinaus. Es beschränkte dieses Root-Zertifikat auf eine Liste indischer Domains. Drei Jahre zuvor war die Reaktion auf eine niederländische Zertifizierungsstelle vollständig gewesen: Am 3. September 2011 beschloss Google, sämtliche von DigiNotar betriebenen Zertifizierungsstellen abzulehnen, und siebzehn Tage später erklärte ein niederländisches Gericht das Unternehmen für insolvent.

DigiNotar, 2011

Der Einbruch bei DigiNotar wurde durch einen gewöhnlichen Nutzer bekannt. Am 28. August 2011 schrieb ein Kunde von ParsOnline, einem iranischen Internetanbieter, in einem Google-Supportforum über eine Zertifikatswarnung, die Chrome ihm angezeigt hatte. Das Zertifikat gab vor, für Google ausgestellt zu sein, und es stammte von DigiNotar, in dessen Systeme eingebrochen worden war. Ermittler der Sicherheitsfirma Fox-IT, die im Auftrag der niederländischen Regierung arbeiteten, stellten später fest, dass ein betrügerisches Zertifikat für google.com-Adressen bei einem groß angelegten Angriff auf etwa 300.000 Nutzer eingesetzt worden war, fast alle davon im Iran, deren Google-Datenverkehr wahrscheinlich abgefangen oder umgeleitet wurde. Sie leiteten diese Schätzung aus 298.140 unterschiedlichen Internetadressen ab, die den Status des gefälschten Zertifikats abgefragt hatten, und bezeichneten sie als sehr grobe Annäherung. Am 3. September entzog die niederländische Regierung DigiNotar öffentlich ihr Vertrauen. Bis Ende Oktober 2026 war kein Angriff mit den eMudhra-Schlüsseln gemeldet worden. DigiNotar zeigte, was die Signiermacht einer CA in den Händen von jemandem anrichtet, der bereit ist, sie einzusetzen.

Die Aufnahme in Chromes Root Store, schrieb Google, verlange von einem CA-Betreiber, fortlaufend die technische Kompetenz und operative Sorgfalt nachzuweisen, die zum Schutz der Chrome-Nutzer nötig sind, und man prüfe „eingehend“, ob eMudhras übrige CA-Zertifikate bleiben sollten. Am 23. Oktober schrieb eMudhra in den öffentlichen Bug-Eintrag, die intensive Beobachtung in den sozialen Medien und die Analysen von Investoren und Kunden hätten eine sinnvolle Analyse des Vorfalls „so gut wie unmöglich“ gemacht. Chrome antwortete am selben Tag, das sei keine Entschuldigung, und eMudhra habe weiterhin Verpflichtungen gegenüber den „Milliarden“ Menschen, die sich auf das System verlassen und die sein Fehler gefährdet habe.

eMudhras Verwaltungsrat hatte bereits am 22. Oktober beschlossen, sich aus dem globalen Geschäft mit SSL/TLS-Zertifikaten zurückzuziehen. Nach Angaben des Unternehmens macht dieses Geschäft nur einen sehr kleinen Teil seiner Tätigkeit aus.

Dieselben Unternehmen schreiben außerdem gemeinsam mit den CAs Regeln, in einem Gremium namens CA/Browser Forum. Bei einer Abstimmung, die am 11. April 2025 endete, neunzehn Tage bevor eMudhra die fehlerhaften Schlüssel erzeugte, stimmten Apple, Google, Microsoft und Mozilla allesamt dafür, die Lebensdauer von Website-Zertifikaten zu verkürzen, und 25 Zertifikatsaussteller, darunter eMudhra, stimmten ebenfalls mit Ja. Die Vorlage argumentierte, dass der Widerruf die Menschen im Maßstab des Internets nicht ausreichend schützt, der Ablauf von Zertifikaten dagegen schon. „Die Gültigkeitsdauer von Zertifikaten und ihre Durchsetzung durch die vertrauenden Parteien sind unglaublich zuverlässig“, hieß es darin. Nach den im Oktober 2026 geltenden Regeln dürfen Website-Zertifikate, die ab dem 15. März 2026 ausgestellt werden, höchstens 200 Tage gültig sein; ab dem 15. März 2027 sind es 100 Tage und ab dem 15. März 2029 noch 47 Tage.

Diese Obergrenzen gelten für die Zertifikate, die Websites verwenden, und richten sich nach dem Ausstellungsdatum. Der Regeltext begrenzt die CA-Zertifikate, um die es bei diesem Vorfall geht, nicht; kürzere Laufzeiten hätten eMudhras Zwischenzertifikate also nicht ablaufen lassen. Verschwunden ist der Widerruf auch nicht. Let’s Encrypt, die kostenlose Zertifizierungsstelle, stellte im August 2025 ihren OCSP-Dienst ein, über den Browser jeweils ein einzelnes Zertifikat abfragen konnten, weil jede Anfrage der CA verriet, welche Website von welcher Internetadresse aus besucht wurde. Die Notfallsperren vom 17. Oktober waren im Grunde Sperrlisten, die Browserhersteller selbst kuratiert und verteilt hatten.

Diese Ordnung legt sehr viel Macht in wenige private Hände, die meisten davon amerikanisch. Was der Fall eMudhra zeigt, ist, wie diese Macht ausgeübt wird: in einem offenen Bug-Eintrag, in dem jeder die Fragen, die Fristen und die Antworten nachlesen kann, und mit Begründungen, die die Unternehmen veröffentlichen, die die Entfernung vornehmen.

Die Zertifikate, die umziehen müssen

Die Entfernung eines Root-Zertifikats ist schnell verkündet und langsam verdaut. Stand 21. Oktober zählte Chrome etwa 30.800 noch nicht abgelaufene Precertificates, deren Kette zu emSign ECC Root CA – G3 führte. Ein Precertificate ist die Kopie eines Zertifikats, die vor der Ausstellung bei den Transparenz-Logs eingereicht wird; die Zahl erfasst also protokollierte Zertifikate, nicht Websites, die sie noch verwenden. Davon stammten 30.791, also 99,9 %, von zwei Zwischen-CAs von InCommon, einem Zertifikatsdienst von Internet2, einer US-amerikanischen Netzwerkorganisation. Diese beiden gehörten nicht zu den acht defekten Zwischen-CAs; sie hingen lediglich an dem Root-Zertifikat, das entfernt wurde. eMudhra schätzte, dass etwa 30.000 Zertifikate umziehen müssten, fast alle über ACME ausgestellt, das Protokoll, mit dem Server Zertifikate automatisch anfordern und erneuern. eMudhra stellte die Ausstellung unter dem G3-Root-Zertifikat am 20. Oktober ein.

Automatisierung allein löst das nicht. Gängige ACME-Clients ersetzen ein Zertifikat erst, wenn sein Erneuerungstermin gekommen ist, es sei denn, sie unterstützen eine neuere Erweiterung, mit der die CA eine vorzeitige Erneuerung anstoßen kann, oder jemand greift von Hand ein. Chrome wies am 21. Oktober darauf hin, dass der Wechsel von eMudhras Hierarchie auf Basis elliptischer Kurven zu seiner RSA-Hierarchie auch bedeuten kann, dass die Einstellungen des Clients geändert werden müssen.

InCommons Zertifikate kommen über CertiNext, einen Lieferanten, dessen Muttergesellschaft eMudhra ist. Am 22. Oktober teilte InCommon seinen Kunden mit, viele von ihnen hätten die Woche damit verbracht, auf Zertifikatsfehler zu reagieren und Änderungen einzuplanen, auf die sie keinen Einfluss hatten, und das nach einer erfolgreichen, aber kräftezehrenden Migration im Frühjahr und Sommer. Sein Rat an jenem Morgen lautete, betroffene Zertifikate als RSA-Zertifikate neu ausstellen zu lassen, bis die Ausstellung auf Basis elliptischer Kurven wieder möglich sei.

eMudhra hatte am 20. Oktober erklärt, die einzige Alternative für seine G3-Kunden seien Zwischen-CAs, deren Kette zu seinem RSA-Root-Zertifikat emSign Root CA – G1 führt. Mozilla erklärte am selben Tag, es entziehe G1 zu diesem Zeitpunkt nicht das Vertrauen. G1 gehörte zu den übrigen eMudhra-Zertifikaten, die Chrome nach eigener Aussage vom 20. Oktober eingehend prüfte; bis zum 24. Oktober hatte Chrome keine Entscheidung bekannt gegeben. Am 21. Oktober bat Chrome eMudhra um Bestätigung, ob Kunden zu G1, zur Hierarchie eines anderen Unternehmens oder zu beidem umgezogen würden.

InCommons Update am Abend des 22. Oktober löste das unmittelbare Problem. Zertifikate auf Basis elliptischer Kurven wurden wieder ausgestellt, nun mit einer Kette zum G1-Root-Zertifikat, und bestehende Clients konnten erneuern, ohne ihre Einstellungen zu ändern. Im selben Update hieß es, eMudhra werde in 30 Tagen, zu einem von CertiNext noch zu bestätigenden Termin, die Ausstellung über alle Zwischen-CAs einstellen, die an seinen öffentlichen Root-Zertifikaten hängen, und InCommon arbeite an einem Ersatzweg. Für Kunden, die im Frühjahr und Sommer eine kräftezehrende Migration hinter sich gebracht hatten, hatte die Entfernung eines einzigen Root-Zertifikats die nächste ausgelöst.

Weitere Artikel zum Thema

• Wie weit eine US-Sanktionsliste in ein Gericht in Den Haag hineinreicht
• Wie geht es weiter mit Bitcoin?
• Wie KI wirklich funktioniert: Was die Entwickler wissen, die Schlagzeilen aber nicht

Weiterführende Literatur

Als Amazon-Partner verdient Eikleaf an qualifizierten Verkäufen. Die folgenden Buchlinks sind Affiliate-Links: Wenn Sie darüber kaufen, erhalten wir möglicherweise eine kleine Provision, ohne zusätzliche Kosten für Sie.

Empfohlene Videos

Hinweis zu generativer KI

Einige Inhalte dieser Seite wurden mithilfe einer generativen KI erstellt und/oder bearbeitet.

Bildnachweise

HTTPS und Schloss-Symbol in der Adressleiste einer Website – Wikimedia Commons (Foto: Santeri Viinamäki, CC BY-SA 4.0)

Hardware-Sicherheitsmodul nCipher nShield F3 – Wikimedia Commons (Foto: Alexander Klink, CC BY 3.0)

Googleplex-Zentrale – Wikimedia Commons (Foto: Asoundd, CC BY-SA 4.0)

Wichtige Quellen und Literaturhinweise

Mozilla Bugzilla. „Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.“ Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. „Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.“ Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. „Compromised eMudhra Intermediate Certificates“ thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. „eMudhra Intermediate CA Compromise.“ Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). „Moving Forward Together: InCommon Certificate Service Update.“ Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). „InCommon Certificate Service FAQ.“ Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. „eMudhra CA compromise fixes available.“ Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. „USN-8944-1: ca-certificates update“ and „USN-8944-2: ca-certificates update.“ Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. „[security] Go 1.27.3 and Go 1.26.10 are released.“ golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. „Release History.“ Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. „Remove emsign (#437),“ „Restore unaffected emSign roots (#439) (#440)“ and „2026.10.23 (#445).“ python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. „Compromised eMudhra intermediate certificates.“ Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. „eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.“ 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. „eMudhra to exit global SSL/TLS certificate business.“ 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. „Mozilla, Google, Apple block compromised eMudhra CA certificates.“ BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. „Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.“ 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. „Indian certification authority eMudhra’s private keys compromised – one of them was the number ‚4‘.“ The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. „Bug 1970728: eMudhra: Invalid CRL signatures.“ June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. „Firefox for Android 145.0 release notes.“ 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. „RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.“ IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. „RFC 6962: Certificate Transparency.“ IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. „Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.“ 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. „Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.“ 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. „Chrome Root Program Policy, Version 1.8.“ Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. „Mozilla Root Store Policy, Version 3.1.“ Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. „OCSP Service Has Reached End of Life.“ Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. „An update on the lock icon.“ Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. „‚It builds trust with the customers‘ – Exploring User Perceptions of the Padlock Icon in Browser UI.“ SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. „Network security configuration: Certificate transparency.“ Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. „Maintaining digital certificate security.“ Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. „An update on attempted man-in-the-middle attacks.“ Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. „Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.“ 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf