Zwischenzertifikate von eMudhra kompromittiert: Jeder konnte die privaten Schlüssel berechnen

Michael Dobler

Autor Dr. Web

21. Okt. 2026

3 Min. Lesezeit

Acht Zwischenzertifikate der indischen Zertifizierungsstelle eMudhra hatten private Schlüssel unter 256 statt einer Zufallszahl mit bis zu 116 Stellen. Mozilla und Google streichen deshalb das zugehörige Wurzelzertifikat. Browser waren rechtzeitig geschützt, Server mit veralteter Zertifikatsliste nicht, auch WordPress 7.1.3 vertraut dem Wurzelzertifikat noch.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

„We have a problem here“, signiert mit jedem der acht geheimen Schlüssel: Mit diesem Satz belegte ein Sicherheitsforscher am 17. Oktober seinen Fund gegenüber Apple, Google, Microsoft, Mozilla und eMudhra.^[1] Knapp zwei Stunden nach Eingang der Meldung berechnete Mozilla die Schlüssel selbst, ohne jeden Hinweis auf die Methode.^[2]

Das Wichtigste in Kürze

Mit den Schlüsseln ließen sich gültige HTTPS-Zertifikate für beliebige Websites ausstellen.
Firefox und Chrome sperren die Zwischenzertifikate seit dem 17. Oktober, Apple und Microsoft seit dem 19. und 20. Oktober.
Rund 30.000 Zertifikate von eMudhra müssen unter einer anderen Zertifikatskette neu ausgestellt werden.
Server, Programmiersprachen und WordPress brauchen eine aktualisierte Zertifikatsliste.

Wie konnten die Schlüssel so schwach ausfallen?

Geöffneter Tresor, blauer Schlüssel, Anhänger mit „1 BYTE“ und Aufkleber „Datenlücke“ — Acht P-384-Schlüssel waren fehlerhaft unter 256, statt über 116-stellig. Angreifer konnten sie durch Durchprobieren von 256 Werten knacken

Ein privater Schlüssel auf der Kurve P-384 ist eine zufällige Zahl zwischen 1 und einer Obergrenze mit 116 Dezimalstellen. Die acht betroffenen Schlüssel lagen alle unter 256, waren also bis auf das letzte Byte null. Nach Angaben von Mozilla-Ingenieur Dennis Jackson genügt dafür ein Durchrechnen der ersten 256 möglichen Schlüssel.^[2] Das Signaturverfahren ECDSA bleibt davon unberührt, auch die umstrittene Herkunft der NIST-Kurven spielt keine Rolle.

Den Fehler verortet eMudhra in der Schlüsselzeremonie vom 30. April 2025, dem protokollierten Termin, an dem die Schlüssel erzeugt wurden. Für einen Test, Schlüssel verschlüsselt aus dem Hardware-Sicherheitsmodul zu exportieren, wich das Team vom üblichen Skript ab. Dabei entstand ein zweites, schwaches Schlüsselpaar mit ähnlicher Bezeichnung, das versehentlich in die Zertifikatsanträge geriet, auch in jene, die Sectigo zusätzlich mit einem eigenen Wurzelzertifikat signierte (Cross-Zertifizierung).^[2]

Warum reicht der Widerruf nicht?

Browser verteilen Sperrlisten selbst und verlangen, dass jedes Zertifikat in öffentlich einsehbaren Logs steht (Certificate Transparency). Zertifikate unter den acht Zwischenzertifikaten tauchen dort nicht auf, ein Angriff auf Firefox, Chrome, Edge oder Safari war daher ausgeschlossen.^[1] Viele andere Programme prüfen weder Sperrlisten noch diese Logs.

Weil inzwischen mehrere Personen die Schlüssel unabhängig berechnet haben, entfernt Mozilla das Wurzelzertifikat emSign ECC Root CA G3 aus seiner Liste, Google kündigt denselben Schritt für Version 43 seiner Liste vertrauenswürdiger Wurzelzertifikate an.^[3] Rund 30.000 Zertifikate unter diesem Wurzelzertifikat müssen neu ausgestellt werden, 97 Prozent davon stellte eMudhra automatisiert per ACME aus.^[2] Wegen missbrauchter Schlüssel entzog Mozilla bereits 2011 der Zertifizierungsstelle DigiNotar das Vertrauen.^[6] Anders als bei den erschlichenen Google-Zertifikaten im Oktober versagte diesmal die Zertifizierungsstelle selbst.

Ein Schlüssel unter 256 schützt nichts. Browser haben das nach Stunden abgefangen, Server warten auf ein Update.
Markus Seyfferth, Chefredakteur Dr. Web

Der eMudhra-Vorfall in Zahlen

Acht berechenbare Schlüssel und wer seit wann geschützt ist

Zwischenzertifikate betroffen, sechs für HTTPS und zwei für Code-Signaturen

< 256

lag jeder private Schlüssel, vorgesehen ist eine Zufallszahl mit bis zu 116 Stellen

30.000

Zertifikate von eMudhra müssen nach Angaben des Anbieters neu ausgestellt werden

535 Tage

lagen zwischen Schlüsselzeremonie (30. April 2025) und Fund (17. Oktober 2026)

Seit wann die Zwischenzertifikate gesperrt sind

Firefox und ChromeSperrliste ohne Browser-Update

Seit17. Oktober

Statusgeschützt

AppleiPhone, iPad, Mac

Seit19. Oktober

Statusgeschützt

MicrosoftWindows und Edge

Seit20. Oktober

Statusgeschützt

Linux, Python, Go, ComposerZertifikatsliste als Paket

Seitje nach Paket

Statusnach Update

WordPress 7.1.3mitgelieferte Zertifikatsliste

Seitoffen

StatusKorrektur nur im Entwicklungszweig

Was müssen Server- und WordPress-Betreiber tun?

WordPress prüft ausgehende HTTPS-Verbindungen, etwa zu Schnittstellen und Zahlungsdiensten, gegen eine eigene Zertifikatsliste. In WordPress 7.1.3 steht das betroffene Wurzelzertifikat noch darin. Im Entwicklungszweig ersetzt seit dem 21. Oktober composer/ca-bundle 1.6.0 die Liste, eine WordPress-Version mit dieser Änderung ist noch nicht erschienen.^[4]^[5]

Systemliste aktualisieren: Spielen Sie das Paket ca-certificates Ihrer Linux-Distribution ein, korrigierte Fassungen liegen für Debian, Ubuntu, Fedora, Alpine und Arch vor.^[1]
Abhängigkeiten aktualisieren: Python certifi 2026.10.19, Go 1.27.3 oder 1.26.10, Composer ca-bundle 1.6.0. Für Node.js steht die Korrektur noch aus.
Selbst testen: Rufen Sie vom Server aus dv-g3b-emudhra.we-have-a-problem.com auf. Meldet curl einen Zertifikatsfehler, vertraut der Server den Zwischenzertifikaten nicht mehr.

Ob jemand die Schlüssel außerhalb der Browser missbraucht hat, weiß bisher niemand. eMudhra will binnen einer Woche alle bisherigen Schlüsselzeremonien erneut prüfen, Google prüft zugleich das verbliebene Wurzelzertifikat des Anbieters in Chrome.