eMudhra-CA-Kompromiss: acht private Schlüssel, von denen einer die Ziffer 4 enthält

‍TL;DR

eMudhra, eine Zertifizierungsstelle, der alle gängigen Browser vertrauen, hat die privaten Schlüssel für acht ihrer Signaturzertifikate so generiert, dass einer davon lediglich aus der Zahl 4 besteht – ein Schlüssel, der kaum einfacher zu erraten sein könnte. Um einen ordnungsgemäß generierten Schlüssel zu knacken, sind etwa 10^115 Versuche erforderlich. Bei diesen Schlüsseln reichten höchstens 256 Versuche aus – genug, damit jeder, der Ihren Datenverkehr abfangen kann, sich als beliebige Website ausgeben kann.

• Wer ist betroffen: Browser haben die Zertifikate bereits blockiert. Server, CI-Pipelines, Docker-Images und Befehlszeilentools wie curl und git könnten ihnen weiterhin vertrauen, da sie nie überprüfen, ob ein Zertifikat widerrufen wurde.
• Vorgehensweise: Aktualisieren Sie Ihr CA-Bundle und erstellen Sie Ihre Images neu. Die einzelnen Schritte finden Sie weiter unten.
• So hilft „ Aikido “: „ Aikido “ stuft Bilder unter container , die noch die betroffenen Zertifikatsbündel enthalten, als „kritische“ oder „hohe“ Probleme ein.

Wer ist betroffen

Die meisten Browser-Nutzer sind davon betroffen. Firefox und Chrome blockieren die Zertifikate seit dem 17. Oktober, Apple-Geräte seit dem 19. Oktober und Microsoft-Plattformen seit dem 20. Oktober – unter Verwendung der Sperrlisten, die ihre Anbieter an die Nutzer weitergeben.

Bei den acht betroffenen Zertifikaten handelt es sich um Zwischenzertifizierungsstellen (Intermediate CAs), also Signaturzertifikate, die in einer Kette bis zu einer vertrauenswürdigen Stammzertifizierungsstelle führen. Wer den privaten Schlüssel einer Zwischenzertifizierungsstelle besitzt, kann für jede beliebige Domain ein gültiges Zertifikat signieren. Diese acht Zertifikate sind mit der „emSign ECC Root CA – G3“ verknüpft, die Mozilla aus seinem Vertrauensspeicher entfernt hat und deren Entfernung Chrome voraussichtlich am 27. Oktober nachziehen wird.

Die Sicherheitslücke befindet sich in einer Software, die ihre eigene Zertifikatsprüfung durchführt:

• Befehlszeilen-Tools. Unter macOS ist die integrierte curl, git, python3, Perl, Rubin und openssl mit … abgleichen /etc/ssl/cert.pem ohne die Gültigkeit zu überprüfen, und diese Datei wird nicht automatisch aktualisiert. Der Inhalt dieser Datei und damit auch Ihre Linux-Tools hängen von der ca-Zertifikate Paket Ihrer Distribution.
• Container und CI. Ein Image enthält das CA-Bundle, mit dem es erstellt wurde. Viele Images enthalten jedoch nach wie vor das alte Bundle.
• Sprach-Laufzeitumgebungen. Go, Java, Node.js, Python certifi, Rusts „webpki-roots“ und andere bündeln ihre eigenen Zertifikatsstämme, und für jeden war eine eigene Version erforderlich.
• IoT: Geräte des Internets der Dinge werden mit CA-Zertifikaten in ihrer Firmware ausgeliefert und werden aufgrund der Schwierigkeiten bei der Aktualisierung wahrscheinlich noch jahrelang anfällig bleiben.
• Code-Signierung. Sechs der acht Zwischenzertifikate dienten der TLS-Verschlüsselung, zwei waren von Microsoft als vertrauenswürdig eingestufte Zertifizierungsstellen für die Code-Signierung. Ein Angreifer hätte somit auch Malware unter einem beliebigen Herausgebernamen signieren können. Microsoft hat diese Zertifikate seit dem 20. Oktober gesperrt.

Die Verwendung eines gefälschten Zertifikats setzt nach wie vor eine Position auf dem Netzwerkpfad voraus, beispielsweise ein böswilliges WLAN-Netzwerk oder einen kompromittierten Router. Die Website, die über den Vorfall berichtet, gibt außerdem an, dass die acht Zwischenzertifikate vor der Sperrung nicht in den Zertifikatstransparenz-Protokollen auftauchten, sodass Clients, die Transparenz durchsetzen (Firefox, Chrome, Edge und Safari), nicht angegriffen worden sein können. Clients, die dies nicht durchsetzen, könnten ins Visier geraten sein, und die Website gibt an, nicht zu wissen, ob Angreifer die fehlerhaften Schlüssel gegen sie eingesetzt haben.

Was jetzt zu tun ist

1. Aktualisieren Sie Ihr Betriebssystem und Ihre Browser. Damit ist der Großteil der Nutzer abgedeckt.
2. Aktualisieren Sie das CA-Bundle auf den Servern und in den Images. Die geflickten ca-Zertifikate Die Version hängt von Ihrer Distribution ab: Ubuntu wird ausgeliefert mit 20260816ubuntu0.*, Debian 12 wird ausgeliefert 20250419~deb12u2, Schiffe der Alpine-Flotte 20261020-r0, Fedora wird ausgeliefert 2026.2.92_v9.0.319. Bei einer Ein-Version-Grenzwertfestlegung werden einige davon falsch klassifiziert; überprüfen Sie daher die Tabelle zum Unfallort für Ihre Distribution und Laufzeitumgebung. Erstellen Sie den aktiven Vertrauensspeicher neu, sofern dies für Ihre Distribution erforderlich ist.
3. Bilder neu erstellen und Dienste neu starten. Lade ein aktuelles Basis-Image herunter (docker build --pull --no-cache), sodass das aktualisierte Bundle integriert wird. Beachten Sie, dass noch nicht alle Images aktualisiert wurden. Ein laufender „ container “ behält das alte Image bei.
4. Testen Sie es. Führen Sie die beiden folgenden Befehle aus. Ein SSL-Fehler mit dem HTTP-Code 000 ist das gewünschte Ergebnis.
5. Kümmere dich um die Nachzügler. Für integrierte macOS-Tools, die Apple noch nicht aktualisiert hat, veröffentlicht die Website zu dem Vorfall Befehle zur Problemumgehung. Mitgelieferte Laufzeitumgebungen wie Node.js, Go, Java und certifi Jede davon benötigt eine eigene gepatchte Version.

curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Ein Client, der den kompromittierten Zwischenzertifikaten nicht mehr vertraut, weist beide Anfragen mit einem SSL-Fehler zurück und gibt folgende Meldung aus: HTTP 000:

curl: (60) Problem mit dem SSL-Zertifikat: Abfrage fehlgeschlagen lokales Ausstellerzertifikat
HTTP 000

A 200 bedeutet, dass der Kunde ihnen weiterhin vertraut.

Um zu sehen, welche ca-Zertifikate Ihre Version:

dpkg -s ca-certificates | grep Version   # Debian, Ubuntu
apk info ca-certificates                 # Alpine
rpm -q ca-certificates                   # Fedora, RHEL

Wie „ Aikido “ hilft

Wenn Sie Kunde von „ Aikido “ sind, werden die „ container “-Images automatisch überprüft. Die Überprüfung umfasst sowohl Pakete, die eigene Zertifikatsbündel enthalten, als auch den vom System bereitgestellten Trust Store, und für jedes davon wird ein separates Problem gemeldet.

Bei Paketen mit eigenem Bundle, wie beispielsweise „certifi“ von Python vor Version 2026.10.18, wird für ein Image ein „Critical“-Problem gemeldet. Für den System-Trust-Store, der weiterhin Zertifikatsketten über die kompromittierten Zwischenzertifikate akzeptiert, wird ein „High“-Problem gemeldet. Für jedes Problem gibt es eine Korrektur, die den oben genannten Schritten entspricht, und Anwendungen, die eigene Stammzertifikate einbetten, benötigen separate Updates.

Außerdem haben wir „Device Protection“ v1.10.20 als Hotfix für dieses Problem veröffentlicht. Wenn Sie „Device Protection“ verwenden, empfehlen wir Ihnen, auf diese Version zu aktualisieren.

Was ist passiert: acht Tasten, und eine davon ist die 4

eMudhra ist eine in Indien ansässige Zertifizierungsstelle: Sie überprüft, wer eine Website betreibt, und stellt das Zertifikat aus, das hinter dem Browser-Schloss angezeigt wird. Die Stammzertifikate von Firefox, Chrome, Apple und Microsoft vertrauen dieser Zertifizierungsstelle. Eine Zwischenzertifizierungsstelle ist ein Signaturzertifikat, das mit einem dieser vertrauenswürdigen Stammzertifikate verknüpft ist, und wer auch immer über den privaten Schlüssel verfügt, kann ein gültiges Zertifikat für jede beliebige Domain ausstellen.

Am 17. Oktober teilte ein als Wayne bekannter Forscher den Entwicklungsteams für Browser und Betriebssysteme mit, dass die privaten Schlüssel von acht eMudhra-Zertifikaten der Zwischenzertifizierungsstelle kompromittiert worden seien. Um dies zu beweisen, signierte Wayne die Nachricht„Wir haben hier ein Problem“ mit jedem der acht Schlüssel. Die Zertifikate stammen aus dem April 2025. eMudhra hat die Schlüssel fehlerhaft generiert, was bedeutet, dass jeder sie aus den öffentlichen Zertifikaten rekonstruieren kann.

Ein privater Schlüssel ist eine geheime Zahl, die unmöglich zu erraten sein muss. Ein ordnungsgemäß generierter Schlüssel dieser Art wird aus einem Bereich von etwa 10^115 Werten ausgewählt, also einer 1 gefolgt von 115 Nullen. Nach der Analyse unseres Teams liegt jeder dieser acht Schlüssel unter 256, und einer davon ist die 4.

Eine mögliche Erklärung für die kleinen Schlüssel wäre ein klassischer Typumwandlungsfehler, bei dem die große Zufallszahl versehentlich in ein Byte umgewandelt wurde. Eine weitere Theorie bezog sich auf ein früheres Verhalten von Go, bei dem eine Dezimalkonvertierung die Zahl auf ein einzelnes Byte gekürzt hätte.

Vier ist auch die Zahl aus xkcd 221, wo eine Zufallszahlfunktion die 4 zurückgibt und ein Kommentar schwört, dass sie durch einen fairen Würfelwurf ermittelt wurde. Ein Angreifer benötigte höchstens 256 Versuche, um einen der acht Schlüssel zu finden – statt der etwa 10^115, die eigentlich nötig gewesen wären –, und ein Laptop kann alle 256 Kombinationen durchprobieren, bevor Sie diesen Satz zu Ende gelesen haben. Ein dreistelliges Fahrradschloss hat 1.000 Kombinationen, sodass das Schloss an Ihrem Fahrrad einem Dieb mehr Arbeit bereitet als diese Schlüssel einem Angreifer.

​

Warum Browser behoben sind und curl möglicherweise nicht

Mozilla, Google, Apple und Microsoft übermitteln Sperrinformationen über Mechanismen wie OneCRL, CRLite und CRLSets an ihre Browser, sodass eine ungültige Zwischenzertifikatsstelle blockiert werden kann, ohne auf ein Software-Update warten zu müssen. Auch eMudhra hat die Zertifikate gesperrt, doch dies wird nur von einem Client erkannt, der die Sperrung überprüft.

Die meisten Befehlszeilentools und Laufzeitumgebungen führen keine Überprüfung durch. Sie verfügen über eine Liste vertrauenswürdiger Stammzertifikate und akzeptieren alles, was mit einem solchen Zertifikat in einer Kette verbunden ist. Die einzige Möglichkeit, zu verhindern, dass sie einem kompromittierten Zwischenzertifikat vertrauen, besteht daher darin, eine neue Liste bereitzustellen. Laut der Website zum Vorfall ignorieren viele Clients außerhalb des Browser-Ökosystems Sperrdaten vollständig, sodass nur ein Software-Update sie schützen kann.

macOS ist das deutlichste Beispiel dafür. Apple-Geräte blockieren die Zertifikate auf Betriebssystemebene, doch das integrierte „curl“ liest /etc/ssl/cert.pem, das noch nicht aktualisiert wurde. Ein Browser und ein Terminal auf demselben Laptop können unterschiedliche Auffassungen darüber haben, ob dasselbe Zertifikat gültig ist.

Container verursachen eine eigene Verzögerung. Ein Docker-Image friert sein CA-Bundle zum Zeitpunkt der Erstellung ein, sodass jedes Image, das vor der Korrektur erstellt wurde, sowie jedes Image, das seitdem auf Basis einer alten Basisebene erstellt wurde, weiterhin den kompromittierten Zwischenzertifikaten vertraut, bis jemand das Image neu erstellt. Einige Beispiele vom 22. Oktober sind: grafana/grafana:latest, mysql:neueste Version, jenkins/jenkins:latest & bitnami/postgresql:neueste Version.

Wie die Zertifikatsvertrauensstellung funktioniert – kurz erklärt

Ein Zertifikat ist der digitale Ausweis einer Website. Wenn Sie eine HTTPS-Seite öffnen, sendet der Server sein Zertifikat, und Ihr Client überprüft, ob der Name mit der Website übereinstimmt, die Daten gültig sind und die Signatur von einer vertrauenswürdigen Stelle stammt.

Der Unterzeichner ist eine Zertifizierungsstelle (CA). Ihr Betriebssystem oder Ihr Browser verfügt über eine integrierte Liste von Stamm-Zertifizierungsstellen, denen er vertraut. Stamm-Zertifizierungsstellen bleiben offline und delegieren die tägliche Arbeit an Zwischen-Zertifizierungsstellen, die die Zertifikate signieren, die von Websites tatsächlich verwendet werden. Ein Zertifikat, dessen Signaturkette über eine Zwischen-Zertifizierungsstelle zu einer vertrauenswürdigen Stamm-Zertifizierungsstelle führt, wird akzeptiert.

Der private Schlüssel einer Zwischenzertifizierungsstelle kann ein gültiges Zertifikat für jede beliebige Domain signieren. Wenn also ein Schlüssel in die falschen Hände gerät, wird die Autorität der Stammzertifizierungsstelle missbraucht, bis die Clients angewiesen werden, ihr nicht mehr zu vertrauen.

Zeitplan

Aktualisierungen und Quellen

22. Oktober 2026: Erstveröffentlichung. Der Status der Patches ändert sich täglich. Überprüfen Sie daher die Tabelle auf der Incident-Website für Ihre Distribution und Laufzeitumgebung.

Quellen:

• eMudhra Intermediate CA Compromise, Website zu diesem Vorfall, gepflegt von Dennis Jackson und Mitwirkenden
• Mozilla-Störungsmeldung, verlinkt von der Störungsseite

​