eMudhra-CA-Schlüssel kompromittiert: Go, Firefox und NSS liefern Fixes

Die privaten Schlüssel hinter acht Zwischenzertifikaten von eMudhra, einer indischen Zertifizierungsstelle, wurden offengelegt. Das haben Mozilla und Google am 20. Oktober 2026 bestätigt. Wer diese Schlüssel besitzt, könnte HTTPS-Zertifikate für fremde Websites ausstellen, denen Browser vertrauen würden. Die Browser sperrten die Zertifikate binnen Stunden, doch viele Apps außerhalb des Browsers bleiben gefährdet, bis sie aktualisiert werden.

Was mit den eMudhra-Schlüsseln passiert ist

Eine Zertifizierungsstelle, kurz CA, bürgt für Websites, indem sie deren Zertifikate signiert. Große CAs signieren über „Zwischenzertifikate“, die zwischen ihrer Root und jeder Website stehen. Gelangt der private Schlüssel eines Zwischenzertifikats nach außen, kann ein Angreifer für jede beliebige Domain ein gültig wirkendes Zertifikat erzeugen.

Ein Forscher meldete die acht Schlüssel am Samstag, dem 17. Oktober, den Browser-Herstellern. Als Beweis signierte er mit jedem Schlüssel eine Nachricht: „We have a problem here - Wayne.“ (Wir haben hier ein Problem - Wayne.) Sechs der Zwischenzertifikate stellen Website-Zertifikate (TLS) aus, zwei signieren Software-Code, berichtet The Hacker News.

Die Schlüssel waren zudem schwach, so der Sicherheitsforscher Scott Helme. Jeder war eine winzige Zahl, und er stellte die privaten Schlüssel aller 16 zugehörigen Zertifikate in weniger als einer Sekunde wieder her. Die Zwischenzertifikate stammen aus dem April 2025, also hätte das jeder etwa 17 Monate lang ebenso tun können. Helme zitiert die Erklärung von eMudhra: Ein Fehler in einem Skript erzeugte ein zweites, schwaches Schlüsselpaar, und Mitarbeiter wählten das falsche, weil die Namen ähnlich waren.

Laut The Hacker News ist unbekannt, wie die Schlüssel eMudhra verlassen haben und wer sie sonst noch besitzt. Helmes Analyse ergänzt, dass sich nicht feststellen lässt, ob jemand sie schon vorher wiederhergestellt hat.

Am 22. Oktober kündigte eMudhra an, ganz aus dem weltweiten SSL/TLS-Zertifikatsgeschäft auszusteigen, wie eMudhra steigt nach dem Schlüsselfehler aus dem weltweiten SSL/TLS-Zertifikatsgeschäft aus beschreibt.

Wie schnell die einzelnen Anbieter reagierten

Zeitpunkt (UTC)	Maßnahme
17. Oktober, 18:05	Das Root-Programm von Chrome erhält die Meldung
17. Oktober, 19:45	Chrome sperrt die sechs TLS-Zwischenzertifikate über CRLSet, seine Sperrliste
17. Oktober, 20:06	Mozilla erhält die Meldung
17. Oktober, 22:59	Die OneCRL-Sperre von Firefox erreicht Nutzer mit Standardeinstellungen
19. Oktober	Apple sperrt die Zertifikate
20. Oktober	Microsoft sperrt sie; Releases von Go, Firefox und NSS erscheinen

Laut Mozilla brauchte Firefox für die Sperre weder ein Update noch einen Neustart. Mozilla veröffentlichte außerdem Firefox 158.0.1, ESR 115.43.1 und ESR 153.5.1 für Nutzer, deren eigene Einstellungen die OneCRL-Updates gestoppt hatten. NSS 3.131.1, die Sicherheitsbibliothek von Mozilla, entfernt die Root emSign ECC Root CA - G3, die die Zwischenzertifikate signiert hat. Chrome wird dieselbe Root mit Version 43 des Chrome Root Store entfernen.

Chrome sperrte die beiden Code-Signing-Zwischenzertifikate nicht, weil seine Website-Prüfungen nie über sie laufen. Chrome erklärte zudem, alle anderen CAs in seinem Store geprüft und „keine weiteren Fälle dieses Fehlermusters gefunden“ zu haben. Vor der Sperre durch Chrome waren keine protokollierten Website-Zertifikate mit den sechs TLS-Zwischenzertifikaten verkettet, berichtet The Hacker News.

Warum Apps außerhalb des Browsers weiter gefährdet sind

Browser erhalten Sperrlisten automatisch. Die meisten anderen Programme prüfen Sperrungen überhaupt nicht. Sie vertrauen einer mitgelieferten Liste von CAs, bis jemand eine neue ausliefert.

Helme testete das mit einem gefälschten Zertifikat für api.stripe.com. Mit Standardeinstellungen akzeptierten curl, Python und Node es unter Linux und macOS. Unter Windows akzeptierte es die System-Kryptobibliothek, sofern die Sperrprüfung nicht eingeschaltet war.

Go brauchte aus demselben Grund eine Code-Änderung, erklärt Cyber Kendra. Sein Zertifikatsprüfer liest keine Sperrlisten von Browsern, daher vertrauen Go-Programme den Schlüsseln, bis sie neu gebaut werden. Dies sind die korrigierten Versionen, die in den Berichten genannt werden:

Software	Korrigierte Version
Go	1.27.3 und 1.26.10 (CVE-2026-111943); 1.25 und älter werden nicht mehr unterstützt
Firefox	158.0.1, ESR 115.43.1, ESR 153.5.1
NSS	3.131.1
Python certifi	2026.10.19
Rust webpki-roots	1.0.10
Electron	44.9.1, 43.8.1, 42.11.16

Was das für Entwickler bedeutet

Browser sind abgedeckt. Ihre Server, Build-Tools und Container wahrscheinlich nicht, bis Sie sie aktualisieren.

• Bauen Sie Go-Dienste neu. Ein Go-Binary trägt seine Zertifikatsprüfungen in sich. Bauen Sie mit Go 1.27.3 oder 1.26.10 neu und deployen Sie erneut; nur die CA-Liste des Rechners zu aktualisieren, hilft nicht.
• Aktualisieren Sie mitgelieferte CA-Listen. Aktualisieren Sie certifi in Python-Projekten, webpki-roots in Rust und Electron in Desktop-Apps. Bauen Sie Container-Images neu, damit sie das neue System-Bundle übernehmen. Die Python-Versionen vom 21. Oktober bringen die Korrektur für neue Installationen mit, wie in Python 3.15.1, 3.14.9 und 3.13.17 liefern pip 26.2.2 beschrieben.
• Durchsuchen Sie Ihre eigenen Ketten. Wenn ein Anbieter oder interner Dienst ein eMudhra-Zertifikat nutzt, finden Sie das heraus, bevor die Roots verschwinden. Fügen Sie ein Zertifikat in einen Zertifikat-Decoder ein und lesen Sie das Feld für den Aussteller.
• Schalten Sie Sperrprüfungen ein, wo es geht. Helmes Windows-Test erkannte das gefälschte Zertifikat nur mit aktivierter Sperrprüfung. Behandeln Sie diese Einstellung als Teil Ihrer TLS-Konfiguration, nicht als Extra.