Schwache eMudhra-Schlüssel: Was Unternehmen jetzt patchen müssen

Acht Schlüssel, die jeder ausrechnen konnte

Am 19. Oktober 2026 erfuhren erste Betroffene, seit dem 20. Oktober ist es öffentlich: Acht Zwischenzertifikate der indischen Zertifizierungsstelle (CA) eMudhra waren mit extrem schwachen privaten Schlüsseln erzeugt worden. Die Schlüssel lauteten 4, 56, 66, 115, 155, 156, 230 und 237. Korrekt erzeugt hätte jeder rund 384 Bit Zufall enthalten müssen. Die Zertifikate wurden von allen großen Browsern akzeptiert. Wer die Schlüssel kennt, kann für jede beliebige Domain ein Zertifikat ausstellen, dem ungepatchte Clients vertrauen.

Am 30. Oktober hat Cloudflare eine Bilanz veröffentlicht: wie schnell das eigene Netz gepatcht war, ob die Schlüssel missbraucht werden und wie viele Besucher ihnen noch vertrauen.

Was Admins wissen müssen:

• Anders als bei früheren CA-Vorfällen (DigiNotar, TÜRKTRUST) hat nicht ein begrenzter Kreis Zugriff, sondern jeder. Die Schlüssel lassen sich aus den öffentlichen Zertifikaten zurückrechnen.
• Browser haben die Zertifikate innerhalb von ein bis zwei Tagen gesperrt. Betriebssysteme, Container-Images, Bibliotheken und Geräte mit eigenem Zertifikatsspeicher brauchen eigene Updates.
• Clients, die Certificate Transparency erzwingen, lehnen gefälschte Zertifikate in der Regel ab. Viele Server-Anwendungen und Geräte tun das nicht.
• eMudhra steigt laut eigener Mitteilung aus dem Geschäft mit öffentlichen TLS-Zertifikaten aus.

Was bei eMudhra schiefging

Laut der Stellungnahme von eMudhra, die Ars Technica zitiert, entstanden die Zertifikate bei einer Schlüsselzeremonie am 30. April 2025 mit Hardware-Sicherheitsmodulen. Ein Fehler in einem Skript erzeugte beim Test eines Export-Schritts ein zweites, schwaches Schlüsselpaar. Weil die Bezeichnungen ähnlich waren, wurde dieses für die Zertifikatsanträge verwendet. Die Anträge gingen auch an Sectigo zur Cross-Signierung.

Das ist für die Praxis wichtig. Laut Trend Micro reicht es nicht, nur die eMudhra-Wurzelzertifikate aus einem Zertifikatsspeicher zu entfernen: Systeme, die der Sectigo-Wurzel vertrauen, können die cross-signierten Kopien weiter als gültig ansehen. Zuverlässig hilft nur das Update, das die betroffenen Zwischenzertifikate ausdrücklich sperrt.

Missbrauch: gefälschte Zertifikate nach wenigen Stunden

Cloudflare hat Pingora, den Proxy für die Verbindungen zu Kunden-Servern, noch am 19. Oktober gepatcht und ab dem 21. Oktober protokolliert, wann ein Server ein Zertifikat mit den schwachen Schlüsseln vorlegt. In einer Woche kamen rund 22.000 Verbindungsversuche zusammen. Zwei Drittel davon waren Testseiten, fast der ganze Rest Server, die sich selbst ein Zertifikat mit den schwachen Schlüsseln ausgestellt hatten.

Etwa 160 Verbindungen fielen auf, weil die vorgelegten Zertifikate fremde Domains nannten, teils Domains von IoT-Geräten. Eines davon war am 20. Oktober um 18:19 UTC erstellt, weniger als eine Stunde nachdem Mozillas Fehlerbericht öffentlich wurde. Hinweise auf abgefangene Verbindungen fand Cloudflare nicht. Gezielte Angriffe auf einzelne Ziele schließt das aber nicht aus.

Für die eigene Sicherheit hatte Cloudflare zusätzlich den Quellcode mit KI-Unterstützung nach Systemen durchsucht, die diesen Schlüsseln vertrauen. Die Analyse lag nach vier Stunden vor, je System gab es ein Ticket mit Prüfauftrag.

Wer den Schlüsseln noch vertraut

Über Testverbindungen auf seinen Challenge-Seiten hat Cloudflare in einer Woche rund 50 Millionen Messungen gesammelt. Der Verkehr ist stark von Bots geprägt, die Zahlen sind deshalb nur ein Richtwert:

• Aktuelle Browser sind größtenteils gepatcht.
• Eingebettete Browser wie Android WebView akzeptieren noch zu 30 bis 40 Prozent die kompromittierte Kette.
• In den großen Netzen akzeptieren mehr als die Hälfte der Messungen die Kette weiterhin, nach dem ersten Wochenende kaum Bewegung.

Cloudflare zieht daraus den Schluss: Bots sind auch nur Software, die Updates braucht. Wenn sie für den Rest der Software stehen, ist die Lage ernst.

Was Unternehmen jetzt tun sollten

• Unter das SDK schauen: Ein API-Client überlässt die Zertifikatsprüfung oft einer HTTP-Bibliothek, der Laufzeitumgebung oder dem Betriebssystem. Das SDK zu aktualisieren reicht dann nicht.
• Abhängigkeiten aktualisieren, Images neu bauen: Mozilla-Entwickler Dennis Jackson führt eine gemeinsam gepflegte Liste gepatchter Pakete. Danach Container neu bauen und Dienste neu starten, sonst greift das Update nicht.
• Den echten Pfad testen: Ein erfolgreicher Browsertest sagt nichts über einen Hintergrunddienst. Prüfen musst du über den TLS-Pfad, den die Anwendung tatsächlich nutzt.
• Fehler nicht wegkonfigurieren: Nach dem Patch können Zertifikatsfehler auftauchen. Die Prüfung abzuschalten hebelt genau den Schutz aus, den das Update bringt.
• Cloudflare-Kunden: cloudflared mindestens auf 2026.10.2 und den WARP-Client (Cloudflare One) auf die von Cloudflare genannten Versionen aktualisieren, mTLS-Vertrauensspeicher und Origin-Zertifikate prüfen.
• Geräte erfassen: Drucker, Kameras, Appliances und alte Linux-Systeme mit eigenem Zertifikatsspeicher bekommen oft spät oder nie ein Update. Sie gehören auf eine Liste mit Ersatz- oder Abschottungsplan.

Fazit

Der eMudhra-Vorfall zeigt, wie ungleich verteilt die Reaktionsfähigkeit ist. Browser-Hersteller sperren ein Zertifikat per Fernschalter, Unternehmen müssen Hunderte Anwendungen, Images und Geräte einzeln anfassen. Für die IT heißt das kurzfristig: Bestandsaufnahme aller eigenen Zertifikatsspeicher und gezielte Updates. Langfristig lohnt die Frage, wie schnell die eigene Infrastruktur einer CA das Vertrauen entziehen kann. Cloudflare setzt dafür auf Projekte wie upki, die Vertrauensspeicher laufend aktualisieren statt als feste Liste auszuliefern.