eMudhra: Acht Zertifizierungsstellen mit Ein-Byte-Schlüsseln
Bei acht Zwischenzertifizierungsstellen von eMudhra bestand der private Schlüssel aus einem einzigen Byte. Damit hätte jeder Zertifikate für beliebige Domains ausstellen können. Browser sind schon geschützt. Server, Container und Apps mit eigenem Zertifikatsspeicher brauchen dagegen ein Update.
Das Schloss in der Adresszeile des Browsers beruht auf Vertrauen in Zertifizierungsstellen. Bei einer davon war dieses Vertrauen 17 Monate lang nichts wert. Der indische Anbieter eMudhra hat acht Zwischenzertifizierungsstellen betrieben, deren private Schlüssel jeweils nur ein Byte lang waren. Ein Sicherheitsforscher hat das am 17. Oktober gemeldet. Cloudflare und der Sicherheitsexperte Scott Helme haben am 20. Oktober die Einzelheiten veröffentlicht.
Was passiert ist
Nach der Analyse von Scott Helme hat eMudhra im April 2025 acht Zwischenzertifikate erzeugt: sechs für TLS, also für Websites, und zwei für das Signieren von Software. Sie nutzen das Verfahren ECC P-384, das an sich als sicher gilt. Nur lagen die privaten Schlüssel bei Werten wie 4, 56 oder 115. Ein Schlüssel mit 256 möglichen Werten lässt sich in Sekundenbruchteilen durchprobieren.
Im Mai 2025 hat zusätzlich Sectigo die acht Zwischenzertifikate über seine Wurzel „AAA Certificate Services“ quersigniert. Dadurch reichte das Vertrauen in sehr viele Systeme hinein. Wer einen der Schlüssel kannte, hätte gültige Zertifikate für jede beliebige Domain ausstellen können, also etwa für eine Bank, einen Webshop oder das Firmen-Login. Helme bringt es auf den Punkt:
„The key was effectively public from the day the certificate existed.“
Als Ursache nennt eMudhra einen Fehler in einem Skript, das auf dem Hardware-Sicherheitsmodul ein zweites, schwaches Schlüsselpaar erzeugte. Bei der Zertifikatsanfrage wurde dann versehentlich dieses Paar verwendet.
Browser reagierten schnell
Chrome hat die Zwischenzertifikate noch am Abend des 17. Oktober gesperrt, Firefox wenige Stunden später. Apple zog laut iTnews am 19. Oktober nach. Mozilla entfernt die zugehörige Wurzel „emSign ECC Root CA - G3“ komplett aus seinem Zertifikatsspeicher, Chrome geht einen ähnlichen Weg. Nach eigener Schätzung von eMudhra müssen rund 30.000 Zertifikate auf eine neue Kette umziehen.
Cloudflare hat in seinen Netzen nach eigenen Angaben keine Ausnutzung gefunden und seine Dienste bis zum 20. Oktober abgesichert. Ob die schwachen Schlüssel vorher von Angreifern entdeckt wurden, weiß aber niemand.
Das Problem liegt hinter dem Browser
Wer einen aktuellen Browser nutzt, ist geschützt. Das gilt aber nicht für alles andere, was verschlüsselte Verbindungen aufbaut. Cloudflare warnt ausdrücklich: „A successful browser test does not prove that a background service is protected.“ Viele Programme bringen ihren eigenen Zertifikatsspeicher mit. Helme nennt das Paket ca-certificates des Betriebssystems, die Python-Bibliothek certifi, Node.js und Homebrew. Container-Images enthalten eine eingefrorene Kopie davon. Laut iTnews akzeptierte curl auf macOS die Kette trotz Apples Sperre noch, weil es eine eigene Datei prüft.
Besonders heikel ist mutual TLS, bei dem sich Clients per Zertifikat ausweisen. Dort sollten die hinterlegten Zertifizierungsstellen überprüft werden. Cloudflare rät außerdem dringend davon ab, Fehlermeldungen einfach wegzuklicken:
„It's important to not resolve these errors by disabling verification.“
Wir hatten erst kürzlich über ein ähnlich unscheinbares Infrastruktur-Thema berichtet: Windows-Rechner, denen 2027 neue Zertifikate fehlen. Auch beim DNS-Schlüsselwechsel für die Telematikinfrastruktur lag das Problem nicht im Browser, sondern in Geräten, die niemand aktualisiert hatte.
Was das für Ihr Unternehmen heißt
- Zertifikatsspeicher aktualisieren: Auf Servern das Paket ca-certificates einspielen, in Projekten certifi und Node.js auf den neuesten Stand bringen.
- Container neu bauen: Docker-Images übernehmen das Update erst, wenn das Basis-Image es enthält und das Image neu gebaut wird.
- mTLS und Schnittstellen prüfen: Wo Partner oder Geräte sich per Zertifikat anmelden, die hinterlegten Zertifizierungsstellen kontrollieren.
- Eigene Zertifikate prüfen: Wer selbst ein Zertifikat von eMudhra nutzt, braucht ein neues, sonst melden Browser Fehler.
- Geräte nicht vergessen: Kassen, Scanner, Industrie- und IoT-Geräte mit fester Firmware beim Hersteller nachfragen.
- Nie die Prüfung abschalten: Ein Zertifikatsfehler ist ein Warnsignal und kein lästiges Hindernis.
Fazit
Der Fall eMudhra zeigt, wie viel an einer einzigen Stelle hängt. Die Browser-Hersteller haben in wenigen Stunden reagiert, für den Rest der IT gilt das nicht automatisch. Wer jetzt Zertifikatsspeicher, Container und Schnittstellen durchgeht, schließt die Lücke auch dort, wo niemand hinschaut. Wenn Sie dabei Unterstützung brauchen, sprechen Sie mich gern an.
