Google und Apple vertrauten erratbaren eMudhra-Schlüsseln

Mozilla und Google entziehen der eMudhra-Wurzel emSign ECC Root CA – G3 das Vertrauen. Acht ihrer Zwischenzertifikate hatten private Schlüssel, die sich praktisch sofort zurückrechnen ließen. Die Browser-Sperren erreichen keine Software, die weder Sperrlisten noch Certificate Transparency prüft. Schutz bringt erst eine neue Vertrauensliste oder ein Prüfer-Update, das die acht Zertifikate sperrt.

Verwandt: Wenn gekaufte KI-Router Schadcode einschleusen  ·  KnowBe4: Ein Link startet drei Phishing-Wege

Die Meldung vom 17. Oktober

Am Samstag, dem 17. Oktober, ging um 20:06 UTC bei Mozilla eine vom Chrome-Root-Programm weitergeleitete Meldung ein. Die privaten Schlüssel von acht Zwischenzertifikaten der Zertifizierungsstelle eMudhra seien kompromittiert, ein Nachweis der Schlüsselkontrolle lag bei. Zwischenzertifikate stehen zwischen einer Wurzel und den Zertifikaten, mit denen sich Websites oder Software ausweisen. Wer ihren Schlüssel besitzt, kann Zertifikate ausstellen, denen Software mit dieser Wurzel vertraut.

Um 21:48 UTC hatte Mozilla die Schlüssel unabhängig rekonstruiert, ohne den Weg des Melders zu kennen. Um 22:59 UTC war die Sperre in Firefox über OneCRL abgeschlossen, Mozillas zentrale Sperrliste für Zwischenzertifikate. Sechs der acht Zwischenzertifikate dienen TLS, der Verschlüsselung von Verbindungen im Netz. Ihnen vertrauen die Root-Programme von Chrome, Mozilla, Microsoft und Apple. Die zwei übrigen dienen der Codesignatur, ihnen vertraut Microsoft.

Was ist eine Vertrauensliste? Eine Vertrauensliste, auch Root Store genannt, enthält die Wurzelzertifikate, denen eine Software beim Prüfen von Zertifikaten vertraut. Browser, Betriebssysteme und Programmiersprachen führen eigene Listen oder übernehmen abgeleitete Fassungen, etwa die von Mozilla. Fehlt eine Wurzel in der Liste und führt keine andere Kette, etwa über eine Cross-Signatur, zu einer vertrauten Wurzel, scheitern die darunter ausgestellten Zertifikate an der Prüfung, auch ohne Abfrage einer Sperrliste.

Der Fehler in der Schlüsselzeremonie

Die acht Schlüssel stammen aus einer Charge von 24 Zwischenzertifikaten vom 30. April 2025. Als Schlüssel auf der elliptischen Kurve P-384 hätten sie zufällige Zahlen bis zur Gruppenordnung sein müssen, der Größe des Zahlenraums dieser Kurve. Tatsächlich waren alle acht ganze Zahlen kleiner als 256 und damit praktisch sofort zurückzurechnen. Dennis Jackson von Mozilla gab lokalen KI-Agenten eine einfache Aufgabenstellung im Stil eines Hacker-Wettbewerbs. Die Agenten rechneten den Schlüssel beim ersten Versuch zurück.

Nach Darstellung von eMudhra liegt die Ursache in der Schlüsselzeremonie im April 2025. Ein Schritt zum Ver- und Entpacken der Schlüssel erzeugte neben den starken Schlüsseln einen zweiten, schwachen Satz, der versehentlich verwendet wurde. Die Schlüssel entstanden auf Hardware-Sicherheitsmodulen nach FIPS 140-2 Level 3, zertifizierter Spezialhardware für kryptografisches Material. Mitte 2025 kam die Hierarchie in die Vertrauenslisten der Browser und bestand seitdem zwei unabhängige Auditzyklen, ohne dass die schwachen Schlüssel auffielen.

Sieben der acht Zwischenzertifikate liefen nach Angaben des Unternehmens nie produktiv. Das achte stellte kein Endteilnehmerzertifikat aus, was öffentliche Einträge in Certificate Transparency bestätigen, dem offenen Logbuch ausgestellter Zertifikate.

Die Sperrkette bis zum Wurzelentzug

eMudhra markierte die acht Zertifikate am 18. Oktober um 09:38 UTC als widerrufen und nannte als Grund die Kompromittierung der Zertifizierungsstelle. Sectigo widerrief am 19. Oktober seine Cross-Signaturen für die betroffenen Zwischenzertifikate, also die Beglaubigungen durch eine zweite Zertifizierungsstelle. Apple-Geräte blockieren die Zwischenzertifikate seit dem 19. Oktober, Microsoft-Plattformen seit dem 20. Oktober.

Weil mehrere Personen die Schlüssel unabhängig rekonstruiert und teils öffentlich gezeigt hatten, entzog Mozilla am 20. Oktober der Wurzel emSign ECC Root CA – G3 im Notverfahren das Vertrauen. Der Schritt soll Clients ohne Sperrlistenprüfung schützen, die RSA-Wurzel emSign Root CA – G1 bleibt vertraut. Zusätzlich entfernt Mozilla die Wurzel aus der Vertrauensliste in NSS 3.131.1, der Kryptobibliothek des Projekts. Das soll Anwendungen schützen, die Mozillas Liste oder abgeleitete Fassungen nutzen und keine OneCRL-Aktualisierungen empfangen.

Google entfernt die Wurzel ebenfalls aus dem Chrome Root Store, um Nutzer ohne Aktualisierungen von CRLSet zu schützen, der Sperrliste von Chrome. Google erwartet, dass die Entfernung alle abhängigen Geräte am Morgen des kommenden Dienstags, 27. Oktober, pazifischer Zeit erreicht, Vorabkanäle früher. Vor der Sperre waren unter den sechs TLS-Zwischenzertifikaten keine TLS-Zertifikate in Certificate Transparency protokolliert. Gegen Clients mit CT-Pflicht wie Chrome waren gefälschte Zertifikate deshalb nicht einsetzbar.

Wo die Sperre nicht ankommt

Scott Helme stellte mit einem rekonstruierten Schlüssel ein Zertifikat für eine fremde API-Domain aus. Auf den getesteten Linux- und macOS-Systemen akzeptierten curl, Python und Node die Verbindung. Windows CryptoAPI akzeptierte die Kette ohne Sperrprüfung.

Auf macOS blockiert das System die Zwischenzertifikate. Das mitgelieferte /usr/bin/curl prüft Zertifikate jedoch gegen die Datei /etc/ssl/cert.pem und ohne Sperrprüfung. Am 20. Oktober war diese Datei noch nicht aktualisiert.

Cloudflare fand bei der eigenen Prüfung keine aktive Ausnutzung auf seinen Diensten und baute Container-Images sowie gemeinsame Vertrauenslisten neu. Der Dienstleister rät, Anwendungen über ihren tatsächlichen TLS-Prüfpfad zu testen. Ein erfolgreicher Test im Browser oder mit curl decke einen Hintergrunddienst mit anderem Prüfer nicht ab. Zudem warnt Cloudflare davor, die Zertifikatsprüfung nach dem Update abzuschalten, um Fehler zu umgehen. Ein Update des SDK, des Entwicklerbaukastens einer Plattform, ändere allein die zugrunde liegende Vertrauensregel nicht immer.

Updates und der Zertifikatsumzug

Website-Betreiber mit Zertifikaten unter emSign ECC Root CA – G3 müssen nach Vorgabe von Google sofort ein neues TLS-Zertifikat aus einer anderen Hierarchie im Chrome Root Store beschaffen und installieren, um Verbindungsfehler zu vermeiden. eMudhra stoppte die Ausstellung unter der G3-Wurzel. Rund 30.000 Zertifikate müssen umziehen, Ziel ist die RSA-Wurzel G1. Etwa 97 Prozent davon wurden automatisiert über ACME ausgestellt, ein Protokoll für die automatische Ausstellung von Zertifikaten.

Bis zum 20. Oktober haben unter anderem die ca-certificates-Pakete von Ubuntu, Debian, Fedora, Alpine und Arch Linux nachgezogen, dazu das curl-CA-Bundle und Perl Mozilla::CA. Bei Programmiersprachen und Werkzeugen folgten Python certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Go 1.27.3 und 1.26.10, Rust webpki-roots 1.0.10, Electron 44.9.1 und Composer ca-bundle 1.6.0. Node.js veröffentlichte die Korrektur am 21. Oktober in den Versionen 26.12.1, 24.22.1 und 22.23.4. Für Bun lag sie am 20. Oktober im Hauptzweig, eine neue Version stand am 21. Oktober noch aus.

Ebenfalls am 21. Oktober schloss das PHP-Projekt zwei kritische Lücken, über die Angreifer ohne Anmeldung Code auf Webservern ausführen können. Auch dort wirkt der Fix erst, wenn Hoster, Distribution oder das eigene Team die PHP-Runtime austauschen.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Wie lässt sich prüfen, ob ein Client den Zwischenzertifikaten noch vertraut?

Dafür stehen die HTTPS-Testendpunkte dv-g3b-emudhra.we-have-a-problem.com und dv-g3b-aaa-emudhra.we-have-a-problem.com bereit. Meldet ein Client dort einen Zertifikatsfehler, vertraut er den kompromittierten Zwischenzertifikaten nicht.

Welche Firefox-Versionen enthalten den Schutz?

Firefox 158.0.1 für Desktop sowie Firefox ESR 115.43.1 und ESR 153.5.1 bringen den Schutz auch zu Nutzern mit abweichenden Einstellungen. Für Firefox für Android meldeten Nutzer nach Version 158.0.1 ein Problem mit der Sperrwirkung, Mozilla bestätigte es als bekannt.

Was droht über die beiden Codesignatur-Zwischenzertifikate?

Die beiden Zwischenzertifikate hängen an einer Wurzel, der Windows direkt vertraut. Ohne Sperrprüfung würde damit signierte Schadsoftware wie echte Software eines Herstellers wirken.

Lesetipps der Redaktion

LesetippPHP-Exploits sind öffentlich, Hoster müssen jetzt patchenLesetippWenn der Security-Stack schneller wächst als die StrategieLesetippOpenSSL: Was Hersteller jetzt nachweisen müssen

Mehr aus dem MBF Media Netzwerk

cloudmagazinGoogle kontert Meta mit Spitzen-KI zum halben Preis MyBusinessFutureNachfolge: Käufer brauchen die Bankzusage vor dem Termin Digital ChiefsMicrosoft: Deutschland ist EU-Spitze bei Cyberangriffen

Bildquelle: KI-generiert (Oktober 2026)