eMudhra: Acht CA-Schlüssel kompromittiert, Go und Firefox mit Notfallupdates

Die Privatschlüssel von acht Zwischenzertifikaten der indischen Zertifizierungsstelle eMudhra sind kompromittiert. Wer einen dieser Schlüssel besitzt, kann TLS-Zertifikate für beliebige Domains ausstellen. Chrome, Firefox, Apple und Microsoft sperren die Zertifikate bereits, Browser mit Standardeinstellungen brauchen deshalb kein Zutun. Handlungsbedarf besteht dort, wo Software keine Sperrinformationen auswertet: Go-Programme, Python-Umgebungen mit certifi, Rust-Anwendungen mit webpki-roots, Linux-Zertifikatspakete und Firefox-Installationen mit deaktivierten Remote Settings.

Akute Panik ist nicht nötig, eine Prüfung noch in dieser Woche aber schon. Der Vorfall betrifft keine einzelne Webanwendung, sondern die Vertrauenskette, auf die sich TLS-Clients verlassen.

Was ist passiert?

Laut Mozilla ging am Samstag, 17. Oktober 2026, um 20:06 UTC ein Hinweis ein, dass die Schlüssel zu acht eMudhra-Zwischenzertifikaten offenliegen. Der Melder signierte eine Nachricht mit jedem der acht Schlüssel und lieferte damit den Beweis. Mozilla verteilte die Sperre per OneCRL bis 22:59 UTC an alle Firefox-Installationen mit Standardkonfiguration. Das Chrome Root Program blockierte die sechs TLS-Zwischenzertifikate laut The Hacker News bereits um 19:45 UTC per CRLSet. Apple folgte am 19. Oktober, Microsoft am 20. Oktober.

Nach Angaben der von Mozilla-Kryptografieingenieur Dennis Jackson veröffentlichten Übersichtsseite hat die CA die Schlüssel fehlerhaft erzeugt, sodass sie sich aus den Zertifikaten selbst zurückrechnen ließen. Das war seit der Erstellung der Zertifikate im April 2025 möglich. In den Certificate-Transparency-Logs finden sich für diesen Zeitraum keine Zertifikate unter diesen Zwischenstellen. Clients, die CT erzwingen, hätten untergeschobene Zertifikate daher nicht akzeptiert.

Welche Zertifikate betroffen sind

Betroffen sind sechs TLS- und zwei Code-Signing-Zwischenzertifikate, jeweils in den Varianten G3B (eMudhra BV, Niederlande) und G3C (eMudhra Inc, USA):

• EM DV TLS CA G3B und G3C (Domain-validiert)
• EM OV TLS CA G3B und G3C (Organisation validiert)
• EM EV TLS CA G3B und G3C (Extended Validation)
• EM OV CS CA G3B und G3C (Code Signing)

Die TLS-Zwischenstellen hängen an der Wurzel emSign ECC Root CA G3. Zu jedem Zertifikat existiert zusätzlich eine von Sectigo unter AAA Certificate Services quersignierte Kopie mit demselben öffentlichen Schlüssel. Mozilla hat die Wurzel emSign ECC Root CA G3 mit NSS 3.131.1 aus der Vertrauensliste entfernt.

Wer ist betroffen?

Geschützt sind Chrome, Firefox mit aktiven Remote Settings sowie aktuelle Apple- und Microsoft-Systeme. Nicht automatisch geschützt ist alles, was eigene Zertifikatsbündel mitbringt und keine Sperrlisten prüft. Dazu zählen laut den Fix-Übersichten:

• Go-Programme, die mit einer älteren Go-Version als 1.27.3 oder 1.26.10 gebaut wurden
• Python-Anwendungen mit certifi älter als 2026.10.19
• Rust-Anwendungen mit webpki-roots älter als 1.0.10
• Node.js und das Composer-ca-bundle, für die zum Stand 20. Oktober nur offene Änderungen existierten
• Linux-Systeme, deren ca-certificates-Paket noch nicht aktualisiert wurde
• Firefox-Installationen, in denen Remote Settings per Richtlinie abgeschaltet oder im Netz blockiert sind

Wie kritisch ist das?

Ein Angreifer mit einem der Schlüssel und einer Position im Netzwerkpfad könnte Webseiten und Dienste fälschen und Verkehr mitlesen oder verändern. Da die Schlüssel laut Übersichtsseite aus den Zertifikaten rekonstruierbar waren, ist nicht auszuschließen, dass weitere Personen sie kennen. Gegenüber Browsern ist das Risiko inzwischen gering. Für Server-zu-Server-Verbindungen, Agenten, CLI-Werkzeuge und Container mit eingefrorenen Zertifikatsbündeln bleibt es bestehen, bis diese aktualisiert sind. Wer TLS-Client-Zertifikate gegen öffentliche Wurzeln prüft, sollte zusätzlich aufhorchen.

Verfügbare Updates

• Go 1.27.3 und 1.26.10 vom 20. Oktober filtern Ketten mit den acht Zwischenzertifikaten heraus (CVE-2026-111943). Wirksam erst nach einem Neubau der Programme.
• Firefox 158.0.1, ESR 153.5.1 und ESR 115.43.1 bringen die OneCRL-Sperre fest mit (CVE-2026-113470).
• NSS 3.131.1 entfernt emSign ECC Root CA G3.
• certifi 2026.10.19 und webpki-roots 1.0.10 entfernen dieselbe Wurzel.

Das Entfernen einer Wurzel trifft auch legitime Zertifikate. Mozilla weist darauf hin, dass einzelne Server für Nutzer seiner Vertrauensliste außerhalb von Firefox unerreichbar werden können, bis sie auf neue Ketten umgestellt sind.

Was Admins jetzt tun sollten

• Inventar prüfen: Go-Binaries mit go version -m auf die Toolchain-Version prüfen, certifi-Versionen in virtuellen Umgebungen und Container-Images erfassen, Stand des Pakets ca-certificates je Distribution notieren.
• Eigene Go-Dienste mit Go 1.27.3 oder 1.26.10 neu bauen und ausrollen. Go 1.25 und älter erhält keine Korrekturen mehr.
• Distributionsupdates für ca-certificates einspielen, sobald sie verfügbar sind, und Container-Images neu bauen.
• Firefox-Flotten mit deaktivierten Remote Settings auf 158.0.1 beziehungsweise die passenden ESR-Versionen heben.
• Clients gegen die Testhosts prüfen, etwa mit curl https://dv-g3b-emudhra.we-have-a-problem.com/. Ein Zertifikatsfehler ist hier das gewünschte Ergebnis.
• Eigene Dienste mit eMudhra- oder emSign-Zertifikaten frühzeitig auf eine andere Kette umstellen, um Ausfälle nach dem Entfernen der Wurzel zu vermeiden.

Einordnung

Der Fall zeigt, wie unterschiedlich schnell Sperren wirken. Browser erhalten Sperrlisten im Hintergrund, viele Server-Werkzeuge vertrauen dagegen einem Zertifikatsbündel, bis jemand neu baut oder aktualisiert. Go-Maintainer Filippo Valsorda begründete die fest einkompilierte Sperre laut The Hacker News damit, dass Sperrinformationen unter Linux kaum bei Anwendungen ankommen. Wie es zu den fehlerhaften Schlüsseln kam, ist noch offen. Mozilla kündigt weitere Informationen an, Chrome prüft zusätzlich den Status der zweiten eMudhra-Wurzel emSign Root CA G1. Zur letzten Firefox-Hauptversion bietet S-EDV einen eigenen Überblick zu Firefox 158 und dem Supportende von ESR 140.

Passende Anleitungen auf S-EDV

• TLS-Zertifikate mit Let's Encrypt und Certbot: Umstieg auf eine andere Zertifikatskette für eigene Dienste.
• Gesperrtes TLS-Zertifikat bei der AusweisApp-Website: ein weiterer Fall, in dem eine Zertifikatssperre direkte Folgen hatte.

Quellen

• Mozilla Security Blog: Schutz für Firefox-Nutzer nach der eMudhra-Kompromittierung (20.10.2026)
• Mozilla Foundation Security Advisory 2026-111
• golang-announce: Go 1.27.3 und Go 1.26.10 veröffentlicht
• Übersichtsseite zur eMudhra-Kompromittierung mit Testhosts
• The Hacker News: Eight eMudhra CA Keys Compromised
• LWN.net: eMudhra intermediate CA compromise