Dass Verschlüsselung im Web funktioniert, hängt an einer einzigen Voraussetzung: Die geheimen Schlüssel der Zertifizierungsstellen bleiben geheim. Bei der indischen CA eMudhra war das zuletzt nicht der Fall — und der Grund dafür ist technisch fast schon peinlich banal.
WAS GENAU PASSIERT IST
Ein Sicherheitsforscher meldete dem Chrome Root Program am 17. Oktober um 18:05 UTC, dass er die privaten Schlüssel von acht eMudhra-Zwischenzertifikaten rekonstruieren konnte — sechs davon für normale TLS-Website-Zertifikate, zwei für Code-Signing. Mit einem solchen Schlüssel könnte theoretisch jeder ein gültiges Zertifikat für jede beliebige Website ausstellen, dem Browser und Nutzer vertrauen würden.
Google reagierte in 100 Minuten: Um 19:45 UTC desselben Tages blockierte Chrome die betroffenen Zertifikate per CRLSet. Mozilla erhielt die Meldung um 20:06 UTC und zog um 22:59 UTC per OneCRL nach. Apple und weitere Root-Programme wurden am 19. Oktober informiert.
SCHOCK! Der Fehler steckte in der Zufallszahl
Die technische Ursache ist der eigentlich bemerkenswerte Teil der Geschichte: Private Schlüssel vom Typ P384 sollen eine zufällig gewählte, riesige Zahl sein. Bei den acht betroffenen Schlüsseln aber lag diese Zahl jeweils unter 256 — praktisch null, nur mit dem letzten Byte belegt. Damit ließen sich die Schlüssel nicht einmal mit komplizierter Mathematik knacken: Es reichte, die ersten 256 möglichen Schlüssel einfach durchzuprobieren, oder den sogenannten Baby-Step-Giant-Step-Algorithmus anzuwenden, der das Problem in Sekunden löst.
eMudhras eigene Untersuchung führt die Ursache auf eine fehlerhafte Schlüssel-Zeremonie vom 30. April 2025 zurück: Ein Skript für die Erzeugung elliptischer Kurven-Schlüssel enthielt einen Fehler, eine „genehmigte Abweichung“ für einen Wrap/Unwrap-Test führte zusätzlich einen kritischen Bug ein — und am Ende wurden die schwachen Test-Schlüssel versehentlich für die echte Zertifikatssignierung verwendet, statt sie zu verwerfen. Mehrere menschliche Kontrollschritte griffen nicht. RSA-Schlüssel aus derselben Zeremonie waren davon nicht betroffen.
NOTFALL-PATCHES am 20. Oktober
Am 20. Oktober veröffentlichten gleich mehrere Projekte Notfall-Updates: Go 1.27.3 und 1.26.10 (CVE-2026-111943) sowie Firefox 158.0.1 (CVE-2026-113470). Chrome und Mozilla hatten ihre Blockaden bereits zuvor per CRLSet/OneCRL ausgerollt, ohne dass Nutzer dafür etwas installieren mussten.
Die gute Nachricht: Bislang wurde in den öffentlichen Certificate-Transparency-Logs kein einziges missbräuchlich ausgestelltes Zertifikat gefunden, das auf einen der sechs betroffenen Web-Zwischenzertifikate zurückgeht. Ob die Schlüssel tatsächlich außerhalb von eMudhra zirkulierten, ist weiterhin unklar — das Unternehmen weiß selbst nicht genau, wie, wann oder ob Dritte sie in der Hand hatten.
WARUM DICH DAS BETRIFFT, AUCH OHNE eMudhra-ZERTIFIKAT
Die meisten Leser haben vermutlich kein eigenes eMudhra-Zertifikat im Einsatz. Relevant wird der Fall trotzdem für jeden: Er zeigt, wie schnell ein einzelner Fehler in einer Zeremonie das gesamte Vertrauensmodell von HTTPS ins Wanken bringen kann — und wie wichtig es ist, Go-Anwendungen und Browser zeitnah zu aktualisieren, auch wenn ein Update auf den ersten Blick „nur“ eine CA-Geschichte betrifft.
FAZIT: Das System hat funktioniert — diesmal
Vom Fund bis zur ersten Blockade vergingen keine zwei Stunden. Das ist die eigentlich gute Nachricht in dieser Geschichte. Die schlechte: Ein Fehler in einer einzigen Schlüssel-Zeremonie aus dem April 2025 lag über ein Jahr lang unentdeckt im System, bis ihn ein externer Forscher fand.