Am 17. Oktober 2026 meldeten Sicherheitsforscher Apple, Google, Microsoft, Mozilla und der Zertifizierungsstelle (CA) eMudhra gleichzeitig ein gravierendes Problem: Acht von eMudhra ausgestellte Zwischenzertifikate (Intermediate CAs) verwendeten private Schlüssel, die lediglich Ein-Byte-Ganzzahlen waren – konkret die Werte 4, 56, 66, 115, 155, 156, 230 und 237.
Die Zertifikate basieren auf der elliptischen Kurve P-384. Gemäß kryptographischen Standards muss ein privater Schlüssel eine kryptographisch sichere 384-Bit-Zufallszahl sein. Bei einem Wertebereich von rund 3,9 × 10¹¹⁵ ist ein Brute-Force-Angriff in der Praxis ausgeschlossen. Wenn der private Schlüssel jedoch lediglich den Skalarwert 4 oder 56 besitzt, muss ein Angreifer lediglich Vielfache des Basispunkts berechnen (1×G, 2×G … bis maximal 255×G), um den geheimen Schlüssel zu rekonstruieren. Der Sicherheitsforscher Scott Helme stellte alle acht privaten Schlüssel für insgesamt 16 Zertifikate auf einem gewöhnlichen Laptop in weniger als einer Sekunde wieder her.
Formal völlig unauffällig
Die Schwachstelle verbarg sich genau in jenem toten Winkel, den automatisierte Prüfmechanismen übersehen: Obwohl die acht Schlüssel eine Entropie nahe Null aufwiesen, waren sie formal makellos. Multipliziert man den Basispunkt der P-384-Kurve mit 4, so ist der resultierende öffentliche Schlüssel ein mathematisch einwandfreier Punkt auf der Kurve. Kodierung, Kurvenparameter und Algorithmen-Signaturen waren syntaktisch korrekt. Auch die Zertifikatskette, Gültigkeitszeiträume und X.509-Erweiterungen gaben keinerlei Anlass zum Zweifel.
Um die Anomalie aufzudecken, hätte man kleine Ganzzahlen gezielt ausprobieren müssen – eine Prüfung, die in den regulären CA-Audit-Verfahren schlicht nicht existierte. Aus diesem Grund blieben die kompromittierten Zertifikate 17 Monate lang unbemerkt im öffentlichen Netz aktiv.
Die acht Zwischenzertifikate wurden im April 2025 ausgestellt und umfassten sechs TLS-Ausstelle-CAs (je zwei Generationen für DV, OV und EV) sowie zwei Code-Signing-CAs. Im Mai 2025 erhielten sie zudem Cross-Signatures durch das AAA Certificate Services-Root von Sectigo, was die Gesamtzahl betroffener Zertifikate auf 16 verdoppelte. Als Ablaufdatum war der Juli 2039 festgesetzt.
Ein pikantes Detail lieferte die Stellungnahme von eMudhra: Das Unternehmen betonte, die privaten Schlüssel hätten sich ausnahmslos in Hardware-Sicherheitsmodulen (HSM) befunden. Wenn dies zutrifft, hat das HSM schlichtweg treu einen Schlüssel mit dem Wert 4 verwahrt. Hardware-Zertifizierungen und kryptographische Schlüsselqualität sind zwei völlig voneinander getrennte Dinge. In Community-Diskussionen wurde das Dilemma schnell auf den Punkt gebracht: Da die Schlüssel im HSM weggesperrt waren, warf vermutlich nie jemand einen prüfenden Blick auf das Material – und niemand bemerkte, dass der Zufallszahlengenerator gar nicht arbeitete.
Abbildung: Das Logo der betroffenen Zertifizierungsstelle eMudhra. Acht ihrer Zwischenzertifikate waren 17 Monate lang im öffentlichen Internet exponiert. Quelle: Blog von Scott Helme via eMudhra
Mit Schlüssel 4 für Stripe signiert: curl akzeptierte anstandslos
Da die privaten Schlüssel praktisch öffentlich waren, war die Fälschung beliebiger Identitäten ein Kinderspiel.
Scott Helme signierte mit dem privaten Schlüssel 4 ein Zertifikat für die Domain api.stripe.com, startete lokal einen openssl s_server und verband sich mit gängigen Standard-Clients. Das Resultat war alarmierend: curl unter Linux und macOS meldete SSL certificate verify ok; Pythons TLS-Handshake schloss fehlerfrei ab; Node.js meldete authorized: true; und Microsofts Windows CryptoAPI akzeptierte das Zertifikat ohne Beanstandung, sofern keine strikte Online-Widerrufsprüfung erzwungen wurde.
Der entscheidende Unterschied liegt in der Architektur der jeweiligen Zertifikatsspeicher (Trust Stores). Webbrowser verfügen über eine zentralisierte, ferngesteuert aktualisierbare Vertrauensinfrastruktur: Chrome überführte die betroffenen Zertifikate noch am Abend des 17. Oktober in sein CRLSet, Mozilla zog wenige Stunden später mit OneCRL nach. Am 20. Oktober veröffentlichte Mozilla eine Sicherheitswarnung und entfernte die eMudhra-Roots aus NSS; Google bereinigte anschließend im Chrome Root Store v43 das Vertrauen. Zudem erwies sich die für Browser verpflichtende Certificate Transparency (CT) als Schutzwall: Audits bestätigten, dass keine gefälschten Zertifikate in CT-Logs eingereicht wurden, sodass normale Webnutzer vor akuten Angriffen bewahrt blieben.
Kommandozeilenwerkzeuge, Backend-SDKs und IoT-Geräte gehorchen jedoch einer völlig anderen Logik: Ihre Trust Stores werden als statische Dateien mit der Software ausgeliefert. Sie rufen standardmäßig keine CRL- oder OCSP-Endpunkte ab und ignorieren CT-Logs vollständig. Zertifikate, die im Browser längst blockiert sind, gelten in diesen Umgebungen nach wie vor als vollwertige, vertrauenswürdige Ausweise.
Abbildung: Der Bruchpunkt digitaler Vertrauensketten lag nicht in der mathematischen Kurve, sondern im Generierungsprozess des Schlüssels. Quelle: Ars Technica
Der Widerruf erreichte nur die Browserwelt
Eine Bestandsaufnahme der Angriffsflächen offenbart, wie gravierend die langfristigen Risiken sind.
Installationsskripte nach dem Muster curl | sh (wie etwa rustup, nvm oder Homebrew) verlassen sich auf HTTPS. Ein Angreifer in Netzwerkposition könnte die Gegenstelle fälschen und Schadsoftware mit Administratorrechten auf Entwicklungsrechner aufspielen. Noch kritischer sind CI/CD-Umgebungen: In Containern von GitHub Actions, GitLab Runnern oder Jenkins liegen Cloud-Zugangsdaten und Deployment-Schlüssel. In solchen Umgebungen aktualisiert kaum ein Administrator manuell die Zertifikatsspeicher. Auch die Machine-to-Machine-Kommunikation von Microservices (Payment-Gateways, Webhooks, OAuth-Schnittstellen) hängt an den CA-Paketen der Container-Basis-Images. Hinzu kommt das Code-Signing unter Windows: Mit den kompromittierten eMudhra-Zertifikaten signierte Malware wird auf Rechnern ohne Online-Widerrufsprüfung als authentische Software ausgeführt.
Kryptographie-Experte Filippo Valsorda vermutete, dass der Bereinigungsaufwand jenen von Heartbleed übertreffen könnte: Vergessene Linux-Server, verwaiste Container-Images und veraltete CLI-Tools bilden ein extrem langes Risiko-Nachspiel. Ben Cartwright-Cox spekulierte, dass Beispielcode aus Dokumentationen versehentlich in die Produktion gewandert sein könnte, und rügte, dass kein Audit dies in anderthalb Jahren entdeckte. Ian Carroll formulierte es treffend: Diese Ein-Byte-Schlüssel kann jeder berechnen – und einmal in Umlauf gebracht, gibt es keinen Weg, sie wieder vollständig einzufangen.
Ein 13 Jahre währender Nachhall
Die Handlungsmöglichkeiten für Administratoren sind begrenzt. Auf selbst verwalteten Servern gehört das Entfernen der eMudhra-Roots oder das Eintragen der Zwischenzertifikate in Blocklisten zum Standardrepertoire. Systeme auf OpenSSL-Basis müssen sicherstellen, dass die CA-Zertifikate des Host-Systems erneuert wurden. Die unkontrollierbaren Altlasten bilden das eigentliche Problem: Heimrouter, Überwachungskameras, industrielle Steuerungen, Fahrzeugelektronik und POS-Terminals besitzen ab Werk fest verdrahtete Zertifikatsspeicher. Sobald der Hersteller den Firmware-Support einstellt, bleibt oft nur der Austausch der Hardware – und die Zertifikate laufen erst im Juli 2039 regulär ab.
Für Softwarearchitekten und Systemdesigner hält dieser Vorfall eine ernüchternde Lehre bereit: Ein fest einkompilierter Root-Store spart zwar eine Netzwerkabfrage beim Handshake, beraubt das System jedoch für das nächste Jahrzehnt jeder Widerrufsmöglichkeit. Und ein Sicherheitsmodell, das sich einzig darauf verlässt, dass niemand in den privaten Schlüssel hineinsieht, kollabiert in dem Augenblick, in dem ein Zufallszahlengenerator unbemerkt seinen Dienst verweigert.
Weiterführende Quellen:
- Technischer Blog von Scott Helme
- Incident-Bericht auf We Have A Problem
- Ausführliche Berichterstattung auf Ars Technica
- Offizieller Mozilla Security Blog
- Diskussion auf Hacker News
