22. Oktober 2026eMudhra · SicherheitKuratiert

Acht CA-Schlüssel kleiner als 256: Warum eMudhra das TLS-Geschäft aufgibt

Zusammenfassung

Die indische Zertifizierungsstelle eMudhra hat am 22. Oktober 2026 angekündigt, sich aus dem weltweiten Geschäft mit TLS-Zertifikaten zurückzuziehen. Auslöser war ein Vorfall, bei dem die privaten Schlüssel von acht Zwischenzertifikaten so schwach erzeugt worden waren, dass jeder sie aus den Zertifikaten zurückrechnen und damit Zertifikate für beliebige Domains ausstellen konnte. Der Beitrag ordnet die Pressemitteilung anhand des Mozilla-Fehlerberichts ein und zeigt, warum Browser schnell geschützt waren, viele andere Programme aber erst ein Update brauchen.

Terminalausgabe „The key's randomart image is:“ mit einem Rahmen RSA 2048 und SHA256, in dem statt eines Musters nur eine einzelne 4 steht — Symbolbild: eine Randomart fast ohne Inhalt. Echte Randomart sähe auch bei einem schwachen Schlüssel unauffällig aus, siehe Bemerkungen.

Was passiert ist

Am 17. Oktober 2026 um 18:05 UTC ging bei den Root-Programmen von Apple, Chrome, Microsoft und Mozilla sowie bei eMudhra eine Meldung ein: Die im Mozilla-Fehlerbericht als Wayne geführte Person besaß die privaten Schlüssel von acht eMudhra-Zwischenzertifikaten. Als Beweis lag für jeden Schlüssel eine Signatur über die Nachricht „We have a problem here“ bei, die Schlüssel selbst wurden nicht herausgegeben. Mozilla konnte die Schlüssel um 21:48 UTC ohne Hinweise auf den Weg selbst zurückrechnen und sperrte die Zertifikate bis 22:59 UTC über OneCRL.

Sechs der Zwischenzertifikate sind für TLS (DV, OV und EV, jeweils in den Reihen G3B und G3C) und stammen von der Wurzel emSign Root TLS CA - G3. Diese ist von emSign ECC Root CA - G3 querzertifiziert, der alle vier großen Root-Programme vertrauten. Zwei weitere dienen der Codesignatur und galten bei Microsoft als vertrauenswürdig. Sectigo hatte alle acht zusätzlich über seine Wurzel AAA Certificate Services querzertifiziert, der noch Apple und Microsoft vertrauen; diese Querzertifikate sperrte Sectigo am 19. Oktober. eMudhra selbst sperrte die acht Zwischenzertifikate am 18. Oktober zwischen 09:24 und 09:38 UTC mit dem Grund cACompromise.

Wie so schwache Schlüssel entstehen konnten

Ein privater P-384-Schlüssel ist eine Zufallszahl zwischen 1 und der Gruppenordnung, einer Zahl mit 116 Dezimalstellen. Laut Dennis Jackson von Mozilla waren die acht betroffenen Schlüssel alle kleiner als 256, bestanden also bis auf das letzte Byte aus Nullen. Wer das weiß, findet sie fast sofort. Mozilla berichtet, dass lokale KI-Agenten sie mit einer einfachen Aufforderung im ersten Versuch fanden.

Die Schlüssel stammen aus einer Schlüsselzeremonie am 30. April 2025, in der 24 Zwischenzertifikate in drei Reihen entstanden, je mit RSA-4096 und P-384. Betroffen sind genau die P-384-Schlüssel der Reihen B und C. Nach eMudhras vorläufiger Darstellung entstanden zuerst korrekte Schlüssel im HSM. Eine genehmigte Abweichung vom Ablauf sollte das Export-Verfahren (wrap/unwrap) testen, weil die Schlüssel für Rechenzentren in den USA und Europa gedacht waren. Ein Fehler im Skript erzeugte dabei ein zweites, schwaches Schlüsselpaar, das wegen ähnlicher Bezeichnungen versehentlich für die Zertifikatsanträge verwendet wurde.

Offen ist, wie ein nach FIPS 140-2 Level 3 zertifiziertes HSM von Utimaco solche Schlüssel überhaupt erzeugen konnte. Im Fehlerbericht verlangen Beteiligte das Zeremonie-Skript, die Protokolle und den genauen Aufruf, mit dem das zweite Schlüsselpaar entstand. Ein Beteiligter hält fest, dass ein Wert unter 256 nicht aus der regulären Schlüsselerzeugung im Modul stammen kann, sondern nur aus von außen vorgegebenem oder eingespieltem Schlüsselmaterial.

Wer geschützt war und wer nicht

Firefox und Chrome blockierten die Zwischenzertifikate seit dem 17. Oktober, Microsoft seit dem 20. und Apple seit dem 22. Oktober. Browser holen Sperrinformationen über eigene Kanäle wie OneCRL, CRLite und CRLSets nach. Zudem verlangen sie Certificate Transparency: Ein Zertifikat, das in keinem öffentlichen Log steht, lehnen sie ab. Laut der Informationsseite zum Vorfall gibt es für die Zeit seit April 2025 keine Log-Einträge zu diesen Zwischenzertifikaten, deshalb waren Browser nach heutigem Wissen nicht angreifbar.

Anders sieht es bei Programmen aus, die keine Sperrlisten abrufen und Certificate Transparency nicht prüfen, etwa curl, Bibliotheken mit eigener Zertifikatsliste und Electron-Anwendungen wie Slack und Discord. Sie brauchen ein Software-Update. Go veröffentlichte am 20. Oktober die Versionen 1.27.3 und 1.26.10 mit einer festen Sperrliste in crypto/x509 (CVE-2026-111943), Python certifi, curl, Node.js, Electron und die Linux-Distributionen zogen nach. Ob jemand die Schwäche seit April 2025 gegen solche Clients ausgenutzt hat, ist laut Informationsseite nicht bekannt.

Weil inzwischen mehrere Personen die Schlüssel unabhängig gefunden hatten und mitmproxy eine Option zum Signieren mit einem der Schlüssel einbaute, entzog Mozilla am 20. Oktober der Wurzel emSign ECC Root CA - G3 das Vertrauen ganz; Chrome kündigte dasselbe an. eMudhra stellte die Ausstellung unter dieser Wurzel ein. Nach eigenen Angaben müssen rund 30.000 Zertifikate umziehen, etwa 97 Prozent davon kamen per ACME.

Was die Pressemitteilung sagt

eMudhra begründet den Ausstieg mit steigenden Kosten und Anforderungen und damit, dass große Anbieter TLS-Zertifikate kostenlos ausstellen; das Geschäft bringe nur etwa ein Prozent des Umsatzes. Die RSA-Wurzeln der Generation G1 sollen bis zum Abschluss des Übergangs weiterlaufen, betroffene Kunden Ersatzzertifikate von Partnern kostenlos erhalten. Sperrdienste wie CRL und OCSP sollen laufen, bis jedes ausgestellte Zertifikat abgelaufen oder ersetzt ist, und ein vollständiger Ursachenbericht für die Root-Programme soll folgen.

Am 23. Oktober stellte Mozilla fest, dass eMudhra auf Fragen vom 20. Oktober noch nicht geantwortet hatte. Chrome wies eMudhras Hinweis auf Druck aus sozialen Medien und von Investoren zurück: Die Aufmerksamkeit sei die vorhersehbare Folge eines eigenen Fehlers, der es jedem erlaubt habe, Zertifikate für jede Domain auszustellen.

Ideen

Eine Schlüsselzeremonie ist nur so sicher wie das Skript, das sie steuert.
Ähnliche Schlüsselbezeichnungen im HSM machen Verwechslungen zwischen Test- und Produktivschlüssel möglich.
Eine signierte Nachricht beweist Schlüsselbesitz, ohne den Schlüssel preiszugeben.
Browser sperren Zwischenzertifikate in Stunden, andere Clients brauchen ein Software-Update.
Certificate Transparency schützt nur Clients, die sie auch durchsetzen.
Ungültige CRL-Signaturen können früh auf falsch zugeordnete Schlüssel hinweisen.
Eine öffentliche Prüfseite zeigt Admins in Sekunden, ob ein Client noch vertraut.

Einsichten

Die Schwäche lag nicht in P-384, sondern im Ablauf: Ein Testschritt erzeugte Nebenschlüssel, und niemand prüfte, welcher Schlüssel in den Zertifikatsantrag ging. Zertifizierte Hardware schützt nicht vor einem falschen Aufruf und einer fehlenden Gegenkontrolle.
Rücknahme wirkt ungleich. Browser haben eigene Sperrkanäle, viele Laufzeitumgebungen, Bibliotheken und Anwendungen bringen dagegen eigene Zertifikatslisten mit, die erst ein neues Release bereinigt. Deshalb braucht ein Fehler bei einer einzelnen CA Updates für Go, Python und Electron.
Das Warnsignal war seit Juni 2025 sichtbar: Schon damals hatten die Sperrlisten genau dieser Zwischenzertifikate ungültige Signaturen (Mozilla-Bug 1970728). Laut eMudhra wurden sie danach mit den schwachen Schlüsseln neu signiert, statt der Abweichung auf den Grund zu gehen.

Zitate

„However, the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business.“ (eMudhra, Pressemitteilung vom 22. Oktober 2026; sinngemäß: Die Verstärkung in sozialen Medien habe zu einer Aufmerksamkeit geführt, die in keinem Verhältnis zur Bedeutung von TLS für das Geschäft stehe.)

Fakten

Die Meldung ging am 17. Oktober 2026 um 18:05 UTC an die Root-Programme; Mozilla sperrte die Zertifikate bis 22:59 UTC per OneCRL.
Die acht privaten P-384-Schlüssel waren kleiner als 256 und stammen aus einer Zeremonie am 30. April 2025.
Betroffen sind sechs TLS- und zwei Codesignatur-Zwischenzertifikate sowie die Querzertifikate von Sectigo.
Unter der Wurzel emSign ECC Root CA - G3 müssen laut eMudhra rund 30.000 Zertifikate umziehen, etwa 97 Prozent kamen per ACME.
Go 1.27.3 und 1.26.10 sperren die Zwischenzertifikate fest in crypto/x509 (CVE-2026-111943).

Referenzen

Kritik

Die Pressemitteilung benennt weder die betroffene Wurzel noch die Zwischenzertifikate und erklärt Kunden nicht, wie sie prüfen, ob ihre Zertifikate betroffen sind. Den Rückzug schreibt sie teils der Aufmerksamkeit in sozialen Medien zu, obwohl die Schlüssel von jedem zurückgerechnet werden konnten.
Die Aussage, die Infrastruktur sei nicht kompromittiert worden, stimmt nur formal: Für einen Missbrauch war kein Einbruch nötig, weil die Schlüssel schon bei der Erzeugung unbrauchbar waren.

Bemerkungen

Das Symbolbild ist eine Anspielung. Randomart, wie ssh-keygen sie zeichnet, stellt den Hash des öffentlichen Schlüssels dar und sähe auch bei einem Schlüssel mit fast keinem Zufall unauffällig aus; auch die Beschriftung RSA 2048 passt nicht zu den betroffenen P-384-Schlüsseln. Gerade das ist der Punkt: Schwache Schlüssel fallen beim Hinsehen nicht auf.
Laut eMudhra war nur eines der TLS-Zwischenzertifikate (EM DV TLS CA - G3C) in Betrieb, Endzertifikate seien daraus nicht ausgestellt worden. Das lässt sich ohne Ursachenbericht nicht unabhängig prüfen.

Empfehlungen

Auf Servern, in Containern und auf Clients curl https://dv-g3b-emudhra.we-have-a-problem.com/ aufrufen: Ein Zertifikatsfehler ist das gewünschte Ergebnis, eine geladene Seite heißt, dass der Client den kompromittierten Schlüsseln noch vertraut.
ca-certificates der Distribution aktualisieren (Debian 13: 20250419+deb13u1), Go-Programme mit 1.27.3 oder 1.26.10 neu bauen und Python certifi auf 2026.10.19 oder neuer bringen.
Eigene Zertifikatslisten in Java-Keystores, Container-Images, Appliances und Anwendungen mit mitgeliefertem Bundle nach emSign ECC Root CA - G3 durchsuchen; Electron-Anwendungen erst nach ihrem eigenen Update als bereinigt betrachten.
Wer Zertifikate von eMudhra oder emSign per ACME bezieht, den ACME-Client jetzt auf eine andere CA umstellen.

Pressemitteilung lesen

Im Webarchiv suchen