Kompromittierte CA keys erzwingen Korrekturen für Browser und Trust-Store
Kompromittierte CA keys, die zu acht intermediate certificate authorities von eMudhra gehörten, führten zu Notfallsperren in Browsern und Korrekturen in Software von Go, Firefox, NSS, Python und Rust. Mozilla und das Chrome Root Program bestätigten die Kompromittierung am 20. Oktober, nachdem ein Sicherheitsforscher nachgewiesen hatte, dass er über den jeweiligen private key aller acht Stellen verfügte. Ein private key ist das geheime Material, mit dem digitale Zertifikate freigegeben werden, während eine intermediate certificate authority (CA) die Zertifikate ausstellt, die Websites ihren Besuchern präsentieren. Die Kontrolle über einen solchen key könnte es daher ermöglichen, ein Zertifikat für jede beliebige Website auszustellen, das betroffene Software möglicherweise akzeptiert.
Der Forscher meldete das Problem am Abend des 17. Oktober und wies seine Kontrolle nach, indem er dieselbe Nachricht mit jedem der acht keys signierte. Chrome erhielt die Meldung um 18:05 UTC, überprüfte die Ergebnisse und stellte um 19:45 UTC eine CRLSet-Sperre bereit. CRLSet ist die remote bereitgestellte Liste von Chrome mit Zertifikaten, denen nicht mehr vertraut werden darf. Mozilla erhielt die Meldung um 20:06 UTC und schloss um 22:59 UTC eine OneCRL-Sperre für standardmäßige Firefox-Installationen ab. OneCRL übernimmt in Firefox eine ähnliche Funktion für die revocation. Beide Listen werden automatisch abgerufen, sodass normale Browserinstallationen weder einen Neustart noch ein vollständiges Browserupdate benötigten.
Sechs betroffene intermediates waren für Transport Layer Security (TLS) vorgesehen, das System, das Websites authentifiziert und Browserverbindungen verschlüsselt. Dabei handelte es sich um EM DV TLS CA - G3B, EM DV TLS CA - G3C, EM OV TLS CA - G3B, EM OV TLS CA - G3C, EM EV TLS CA - G3B und EM EV TLS CA - G3C. Die beiden anderen, EM OV CS CA - G3B und EM OV CS CA - G3C, waren auf Code Signing beschränkt. Chrome blockierte die Code-Signing-intermediates nicht gesondert, weil sein Prüfsystem für Website-Zertifikate keinen TLS trust path über ein intermediate erstellt, das ausschließlich auf Code Signing beschränkt ist.
Die sechs TLS-intermediates wurden von emSign Root TLS CA - G3 ausgestellt und waren letztlich mit emSign ECC Root CA - G3 verknüpft. Für jedes der acht existierte zudem ein zweites Zertifikat mit demselben public key, das unter dem root AAA Certificate Services von Sectigo cross-signed war. Cross-signing eröffnet demselben key einen weiteren Weg zu einem vertrauenswürdigen root. Die Reaktion von Chrome orientierte sich an den public keys und nicht nur an den einzelnen Zertifikaten, sodass die Sperre auch diese Kopien erfasste. Firefox und Chrome hatten bereits im April 2025 aufgehört, AAA Certificate Services für Websites zu vertrauen, während Apples im Dezember 2025 veröffentlichte root-Liste für iOS 26 und macOS 26 den Dienst weiterhin enthielt.
Das Chrome Root Program fand vor seiner Sperre in den Certificate Transparency (CT) logs kein TLS-Zertifikat, das über die sechs Website-intermediates ausgestellt worden war. CT ist ein öffentliches Verzeichnis von Website-Zertifikaten, und Chrome sowie andere Browser, die eine Protokollierung verlangen, würden einem nicht protokollierten Zertifikat normalerweise nicht vertrauen. Dies begrenzt die über CT sichtbaren Hinweise auf einen Missbrauch, klärt jedoch nicht, ob die keys an anderer Stelle verwendet wurden. Es ist weiterhin unbekannt, wie oder wann die keys eMudhra verließen oder ob außer dem meldenden Forscher noch jemand Zugriff darauf erhielt. Es gibt keine verfügbare Methode, einen früheren Missbrauch festzustellen, außer die in CT erfassten Zertifikate zu durchsuchen.
eMudhra widerrief alle acht Zertifikate. Apple blockierte sie am 19. Oktober, Microsoft folgte am 20. Oktober, und andere trust stores wurden laut einer von einem Mozilla-Kryptografieentwickler veröffentlichten Vorfallseite am 19. Oktober benachrichtigt. Mozilla erklärte, derzeit nicht davon auszugehen, dass andere CAs betroffen seien. Chrome berichtete, jedes andere CA-Zertifikat in seinem store überprüft und keine weiteren Beispiele für denselben Fehlermodus gefunden zu haben.
Software, die revocation-Informationen nicht zuverlässig abruft, benötigt ein Code- oder trust-bundle-Update. Go behandelte die keys in den Versionen 1.27.3 und 1.26.10 unter CVE-2026-111943. Der Filter seiner standard library weist jede chain zurück, die einen der acht keys enthält, auch wenn Go den macOS- oder Windows-system verifier verwendet; die Funktion kann nicht über eine Einstellung deaktiviert werden. Bestehende Programme müssen mit einem korrigierten Go-Release neu erstellt werden. Go 1.25 und ältere Versionen werden nicht mehr unterstützt und erhielten die Änderung nicht. Das Go-Projekt nutzte seinen URGENT-Prozess, obwohl weder der zugehörige Issue noch die Release Notes angeben, ob dies auf eine Ausnutzung oder eine umfassendere Bedrohung für die Integrität des Ökosystems zurückzuführen war. Ein Go-Maintainer erklärte, dass die betroffenen keys derzeit in den Code eingebettet werden müssten, weil revocation Anwendungen über unzureichend gepflegte Linux root stores nicht zuverlässig erreiche.
Firefox 158.0.1, ESR 115.43.1 und ESR 153.5.1 enthalten unter CVE-2026-113470 die OneCRL-Informationen für Installationen, die keine Remote Settings empfangen können. Standardmäßige Firefox-Installationen, die die remote bereitgestellte Sperre erhalten haben, müssen nichts weiter unternehmen. NSS 3.131.1 entfernt emSign ECC Root CA - G3 aus seiner trust list. Python certifi 2026.10.19 und Rust webpki-roots 1.0.10 entfernen diesen root aus ihren bundles. Homebrew ca-certificates 2026-09-25_1 schließt emSign ECC Root CA - G3, emSign Root TLS CA - G3 und AAA Certificate Services anhand ihrer public keys aus.
Die Entfernung eines vollständigen root hat weitreichendere Auswirkungen als die Sperrung nur der acht kompromittierten keys. Dadurch werden auch legitime Zertifikate abgelehnt, die von diesem root abhängig sind. Mozilla warnte, dass einige Server für Software außerhalb von Firefox, die die NSS trust list verwendet, nicht erreichbar werden könnten, bis deren Betreiber zu anderen certificate chains wechseln. Mozilla empfiehlt Betreibern von trust stores, sich nur dort auf revocation zu verlassen, wo clients diese konsequent prüfen und Verbindungen ablehnen, wenn die Prüfung fehlschlägt. Andernfalls sollten sie die acht intermediates nach Möglichkeit direkt blockieren oder in Betracht ziehen, die roots zu entfernen, von denen sie ausgestellt wurden.
Für Node.js war zum beschriebenen Zeitpunkt noch keine Korrektur veröffentlicht, obwohl ein Entwurf für eine Änderung die acht keys blockieren würde. Auch für ca-bundle von Composer gab es noch kein veröffentlichtes Update; eine offene Änderung schlug die Entfernung von emSign ECC Root CA - G3 vor. Mozilla entfernte diesen root am 20. Oktober aus NSS. Chrome plant, ihn in Version 43 seines root store zu entfernen, und überprüft den anderen aufgenommenen root von eMudhra, emSign Root CA - G1. Das trust-services-Repository der CA enthielt bis zum 20. Oktober keinen Hinweis auf den Vorfall. Mozilla erklärte, dass die Untersuchung der root cause gemeinsam mit der CA, anderen root programs und nachgelagerten trust stores fortgesetzt werde.
Für Organisationen, die die Gefährdung von Browsern, Anwendungen und trust stores bewerten, ist AEU-I der auf sicherheitsorientierte IT, Infrastruktur und Beratung ausgerichtete Dienst der AEU Group. Website-Betreiber sollten prüfen, ob ihre derzeitige certificate chain von einem entfernten root abhängt. Softwareteams müssen zugleich zwischen dem automatischen Schutz von Browsern und Bibliotheken oder kompilierten Anwendungen unterscheiden, die ausdrücklich aktualisiert oder neu erstellt werden müssen.