eMudhra CA-Kompromittierung: Acht Zwischenzertifikate gesperrt

Die eMudhra CA-Kompromittierung betrifft acht Intermediate-Zertifikate: Deren private Schlüssel sind in fremde Hände gelangt, mit ihnen ließen sich TLS-Zertifikate für beliebige Domains ausstellen. Alle acht Zwischenzertifikate sind inzwischen gesperrt. Für unixoide Systeme ohne aktualisierte CA-Pakete läuft der Vorgang unter CVE-2026-111943, betroffen sind dort unter anderem Go, Python-certifi und NetBSD. Firefox-Nutzer benötigen die Versionen 158.0.1, ESR 115.43.1 oder ESR 153.5.1, sofern ihre Installation keine OneCRL-Updates erhält. Ein CVSS-Score liegt bislang nicht vor.

eMudhra CA-Kompromittierung: Acht Zwischenzertifikate betroffen

Am 17. Oktober 2026 um 20:06 UTC wurde Mozilla aus der Sicherheits-Community informiert, also 22:06 MESZ; eine öffentliche Stellungnahme der Zertifizierungsstelle ist bislang nicht bekannt.

Mit den Schlüsseln wäre es möglich gewesen, Websites zu imitieren und Traffic mitzulesen oder zu verändern — die Voraussetzung dafür ist ein Angreifer, der den Verbindungsweg kontrolliert, also etwa über kompromittierte Netze oder Man-in-the-Middle-Positionen verfügt. Eine Webseite allein kompromittiert niemanden; entscheidend ist, wo der Angreifer im Netzwerk sitzt.

Sechs der acht untergeordneten CAs entfielen auf die TLS-Ausstellung und zwei auf Code-Signing. Diese Aufteilung ist für die Bewertung des Risikos wichtig: Nicht jede der gesperrten CAs konnte überhaupt Server-Zertifikate ausstellen. Für die Bereinigung relevant sind vier Roots: emSign_ECC_Root_CA_-_C3, emSign_ECC_Root_CA_-_G3, emSign_Root_CA_-_C1 und emSign_Root_CA_-_G1. Welcher davon genau aus dem NSS-Truststore entfernt wurde, lässt sich aus den Angaben nicht namentlich ableiten.

OneCRL-Sperre in unter drei Stunden, Firefox-Update folgt

Firefox-Nutzer mussten nicht auf ein Update warten. Die Sperrung lief über OneCRL, die Sperrliste für Zertifikate, die ohne Neustart und ohne Versionsupdate greift. Die Verteilung an Standard-Installationen war am 17. Oktober um 22:59 UTC abgeschlossen, also knapp drei Stunden nach dem Eingang des Berichts. In Chrome sind die CAs seit dem 17. Oktober gesperrt, auf Apple-Geräten seit dem 19., auf Microsoft-Produkten seit dem 20. Oktober. Chrome plant zusätzlich, den betroffenen Root aus dem Chrome Root Store zu entfernen.

Für Installationen, bei denen Custom-Settings die OneCRL-Zustellung verhindert hatten, wurde am 20. Oktober Firefox 158.0.1 für Desktop und Android nachgeliefert; das Update enthält den eMudhra-Eintrag in der Blockliste (Release Notes). Parallel erschienen ESR 115.43.1 und ESR 153.5.1. Das Update enthält die OneCRL-Blockliste, damit die Sperren auch bei per Policy deaktiviertem oder nicht erreichbarem RemoteSettings greifen — genau der Fall, in dem eine reine Online-Sperrliste ins Leere läuft.

Davon getrennt zu betrachten ist der NSS-Truststore: Die Trusted-Certificate-Liste wurde auf NSS 3.131.1 angehoben, dabei wurde der Root entfernt, der die betroffenen Intermediates signiert hatte. Das zielt auf Anwendungen, die den NSS-Zertifikatsspeicher mitbenutzen, aber keine OneCRL-Updates erhalten — also gerade nicht auf den Browser selbst.

Linux und Unix: CA-Bundles selbst bereinigen

Hier liegt der eigentliche Aufwand für den Betrieb. Wer Distributionen einsetzt, deren CA-Pakete noch nicht nachgezogen wurden, behält den Root im Truststore, bis er ihn aktiv entfernt. Unter Debian führt sudo dpkg-reconfigure ca-certificates mit Abwahl der Einträge mozilla/emSign_ECC_Root_CA_-_C3.crt, mozilla/emSign_ECC_Root_CA_-_G3.crt, mozilla/emSign_Root_CA_-_C1.crt und mozilla/emSign_Root_CA_-_G1.crt zum Vertrauensentzug. Unter NetBSD entfernen die Befehle certctl untrust /usr/share/certs/mozilla/all/emSign_Root_CA_-_C1.pem und certctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_C3.pem die entsprechenden Anker.

Für Anwendungen, die eigene Zertifikatsspeicher mitbringen, reicht das nicht. Relevant ist dafür CVE-2026-111943, das Go, Python-certifi und NetBSD adressiert. Für Go kursieren Notfallversionen 1.27.3 und 1.26.10; die CA wurde nicht namentlich benannt, und belastbare Go-Primärangaben liegen nicht vor.

Selbsttest mit emudhra.we-have-a-problem.com

Ob die eigene Umgebung noch vertraut, lässt sich prüfen, ohne Zertifikate zu analysieren. Für den Selbsttest gibt es einen öffentlich erreichbaren Testdienst. Unter emudhra.we-have-a-problem.com werden nacheinander Verbindungen zu Subdomains aufgebaut, die von den kompromittierten CAs signierte Zertifikate präsentieren. Eine curl-Schleife über zwölf Subdomains (dv-, ov- und ev-Varianten der Reihen g3b, g3c und aaa) liefert pro Verbindung eine Rückmeldung; die Ausgabe „Your client successfully connected to the site. That’s bad!" bedeutet, dass der Truststore noch nicht bereinigt ist.

Ein zweiter Test arbeitet mit einem fremden Hostnamen: curl https://q3k.google.com --resolve 'q3k.google.com:443:135.181.235.221' spricht gezielt einen Hetzner-Server an, der ein am 20. Oktober für Google ausgestelltes Zertifikat vorzeigt. In Firefox, Safari und Chrome ist der Aufruf inzwischen nicht mehr möglich, dort erscheint eine Warnung vor einem gesperrten CA-Zertifikat. Wer den Testdienst betreibt, ist für die Prüfung unerheblich — relevant ist allein, ob der eigene Client die Kette akzeptiert.

Kein Ausnutzungsnachweis — aber keine Entwarnung

Vor der Sperrung fanden sich keine Zertifikate der kompromittierten CAs in Certificate Transparency. Das ist ein Negativbefund, kein Beweis für Unbedenklichkeit: Wer heimlich signierte Zertifikate einsetzen will, scheitert heute ohnehin an der CT-Pflicht, weil Browser solche Zertifikate nicht akzeptieren. Der Befund zeigt also vor allem, dass kein Missbrauch bekannt geworden ist — nicht, dass keiner stattgefunden hat.

Offen ist die Ursache. Die Ermittlung läuft, eine Koordination mit anderen Root-Store-Betreibern ebenfalls. Auswirkungen auf andere Zertifizierungsstellen werden nach derzeitigem Stand nicht erwartet; das ist eine Einschätzung, keine abgeschlossene Bewertung. Wer die betroffenen Roots bereits bereinigt hat, sollte das nach einem kommenden CA-Paket-Update erneut kontrollieren — Distributionsupdates können Trust-Anker wieder einspielen, wenn der Anbieter sie nicht dauerhaft aus der Liste genommen hat.

Fazit: Truststore prüfen, Patchstand kontrollieren

Für Browser-Nutzer ist die Sache weitgehend erledigt: Die Sperrung erfolgte ohne Zutun über OneCRL, ESR-Nutzer und Installationen mit strikten Policies ziehen mit 158.0.1 beziehungsweise 115.43.1 und 153.5.1 nach. Der Handlungsbedarf liegt bei Servern, CI-Images und eingebetteten Systemen, die eigene CA-Bundles mitführen. Dort gilt: betroffene Roots entfernen, den Selbsttest durchführen, die Ausgabe „Your client successfully connected" als Fehlschlag behandeln und den Vorgang nach dem nächsten Paket-Update wiederholen. Wer Zertifikate von eMudhra in eigenen Ketten nutzt, sollte zudem prüfen, ob ausgestellte Zertifikate noch als vertrauenswürdig behandelt werden — mit der Sperre der Intermediates brechen diese Ketten in aktuellen Browsern.

Quellen