CA-Schlüssel aus acht Bits: Der eMudhra-Fall im Klartext

Am 17. Oktober 2026 ist dem Vertrauenssystem des Web nichts gestohlen worden. Es ist etwas gebaut worden, und zwar nachweislich: Die privaten Schlüssel von acht Zwischenzertifikaten der Zertifizierungsstelle eMudhra bestehen aus einem einzigen Byte. Einer davon ist die Zahl 4, einer die Zahl 56, einer die Zahl 115. Scott Helme hat alle acht Schlüssel aus den öffentlichen Zertifikaten auf seinem Laptop widerhergestellt, der gesamte Durchlauf hat unter einer Sekunde gebraucht. Das ist eine eigene Kategorie des Vertrauensbruchs: kein Diebstahl, kein Leck, kein Schadprogramm, sondern ein Konstruktionsfehler genau an der Stelle, an der Vertrauen hergestellt wird. Ich habe dem Fall am 23. Oktober auf meinem eigenen Setup, dem HUNTER-Cyberdeck auf einem Pixel 6a, eine Messung hinzugefügt, damit klar ist, was das für alle Clients bedeutet, die kein Browser sind. Das Ergebnis: curl und Python mit der Standardkonfiguration akzeptieren ein widerrufenes Zertifikat mit HTTP 200, ohne jede Warnung. Meine These: Ein solcher Fall lässt sich nicht mit Meldungen und Widerruf verwalten, weil das Vertrauen von Anfang an nie vollständig bezahlt wurde. Die Browser sind erledigt, es geht um den Rest des Internets.

Was am 17. Oktober passiert ist

Am Samstag, den 17. Oktober 2026, meldete ein Sicherheitsforscher an Apple, Google, Microsoft, Mozilla und eMudhra, dass die privaten Schlüssel von acht eMudhra-Zwischenzertifikaten kompromittiert sind. Noch am selben Abend verteilte Chrome ein CRLSet-Update, das die acht Zertifikate blockiert. Wenige Stunden später zog Firefox mit OneCRL nach. Am Dienstag, den 20. Oktober, machte Mozilla den Fall öffentlich, verteilte ein NSS-Update, das den eMudhra-Root komplett aus dem Zertifikatsspeicher entfernt, und hängte die betroffenen Zertifikate der Nachricht an. Chrome bestätigte die Sperrung für die Version 43 des Chrome Root Store. Die acht Zwischenzertifikate sind allesamt im April 2025 erzeugt worden: sechs TLS-Zertifizierungsstellen für Domänenvalidierung, Organisationsvalidierung und Extended Validation, jeweils zwei Generationen, plus zwei Zertifizierungsstellen für Codesignierung. Im Mai 2025 hat Sectigo jedes einzelne zusätzlich über seinen Root AAA Certificate Services counter-signiert. Die Zeitschiene ist deshalb wichtig, weil der Schaden nicht am 17. Oktober begann. Die Verwundbarkeit begann im April 2025, an jenem Tag, an dem die Schlüssel erzeugt wurden. Sie war seitdem öffentlich für jeden, der weiß, wo er suchen muss.

Die Tabelle übernimmt Scott Helmes Nachbau, er hat alle 16 Zertifikate geprüft, jedes der acht Schlüsselpaare einmal durch eMudhra und einmal durch die Sectigo-Quersignatur unterschrieben:

| Zwischenzertifikat | Typ | Privater Schlüssel | | --- | --- | --- | | EM DV TLS CA G3B | TLS | 156 | | EM DV TLS CA G3C | TLS | 230 | | EM EV TLS CA G3B | TLS | 115 | | EM EV TLS CA G3C | TLS | 56 | | EM OV TLS CA G3B | TLS | 155 | | EM OV TLS CA G3C | TLS | 4 | | EM OV CS CA G3B | Codesignierung | 66 | | EM OV CS CA G3C | Codesignierung | 237 |

Warum ein Schlüssel die Zahl 4 sein kann und jeden Strukturcheck passiert

Ein privater Schlüssel auf einer elliptischen Kurve wie P-384 ist eine einzelne Zahl, die Literatur nennt sie d. Der öffentliche Schlüssel im Zertifikat ist d multipliziert mit einem festen Kurvenpunkt G. Vorwärts zu rechnen ist billig. Rückwärts vom öffentlichen Schlüssel auf d zu schließen gilt als praktisch unmöglich, genau darauf ruht das Vertrauensmodell, und es gilt nur, wenn d gigantisch ist. Eine korrekte P-384-Zahl ist ein zufälliger 384-Bit-Wert, rund 2 hoch 384 Möglichkeiten, etwa eine Zahl mit 115 Stellen. Die eMudhra-Schlüssel erfüllen diese Voraussetzung nicht. In hexadezimaler Schreibweise stehen dort 47 Nullbytes und ein einziges Datenbyte, der Suchraum schrumpft von 10 hoch 115 auf 256 Werte. Wer den Schlüssel wissen will, zählt: 1 mal G, 2 mal G, weiter bis die Kurve den Zertifikatsvergleich passt, im Schnitt 128 Schritte, im Maximum 255. Das Kuriosum dabei: Nichts an diesen Zertifikaten sieht falsch aus. Ein öffentlicher Schlüssel, der aus d gleich 4 entsteht, ist ein vollgültiger Punkt auf der Kurve, die Kodierung stimmt, die Kurve stimmt, jede Strukturprüfung läuft durch. Der einzige Weg, den Fehler zu finden, ist das Ausprobieren selbst, und das kostet auf gewöhnlicher Hardware Millisekunden. Eine Zertifizierungsstelle, die solche Schlüssel ausstellt, hat keine Sicherheitslücke am Rand ihres Systems. Sie hat die Sicherheitsmathematik in der Mitte ausgeschaltet.

Das sind von Grund auf schwache Ein-Byte-Schlüssel, die jeder faktorisieren kann, und dieser Zustand lässt sich nicht eingrenzen. (Ian Carroll, in der Diskussionsrunde zur Offenlegung)

Siebzehn Monate ohne Alarm

Der Schlüssel war praktisch öffentlich vom Tag der Zertifikatsausstellung an. April 2025 bis Oktober 2026 sind siebzehn Monate, in denen jeder, der irgendeines dieser Zertifikate zu sehen bekam, den Schlüssel in Millisekunden hätte mitnehmen können. Der Fall produziert damit ein Unsicherheitsniveau, das übliche Verfahren für kompromittierte Schlüssel nicht kennen: Es gibt keinen Diebstahlmoment, kein Zugriffszeitfenster, kein Protokoll, das belegen könnte, dass es nicht passiert ist. Chrome führt als Beruhigung an, dass mit erzwungener Zertifikatstransparenz kein einziges gefälschtes TLS-Zertifikat unter diesen Zertifizierungsstellen in den CT-Protokollen aufgetaucht ist. Das trägt für die Browserwelt. Zertifikatstransparenz erkennt Fehlausstellung aber nachträglich, sie verhindert sie nicht, und ein erheblicher Teil der Clientsoftware schaut in diese Protokolle gar nicht hinein. Ein leeres CT-Protokoll ist ein Beleg für den Browserbereich und eine Vermutung für alles andere. Der Mangel an Beweisen wirkt dabei in beide Richtungen, und genau deshalb lässt sich der Fall nicht eingrenzen.

Meine Messung: HTTP 200 auf ein widerrufenes Zertifikat

Die eigene Messung lief am 23. Oktober 2026 auf dem HUNTER-Cyberdeck, dem Linux-Container in einer PRoot-Distribution unter Android auf dem Pixel 6a. Testklienten waren das System-curl ohne Zusatzflags und Python 3.12.3 mit dem OpenSSL-Standardbundel unter /usr/lib/ssl/cert.pem. Zuerst die Kontrolle: https://untrusted-root.badssl.com/ lehnen beide Klienten ab, curl mit dem Kettfehler 60, Python mit CERTIFICATE_VERIFY_FAILED. Das Vertrauensurteil gegen einen unbekannten Root funktioniert auf dieser Maschine grundsätzlich, das Bundel ist kein Trümmerfeld. Danach der eigentliche Test: https://revoked.badssl.com/ hält ein formell widerrufenes Zertifikat bereit. curl antwortete mit HTTP 200. Python antwortete mit HTTP 200. Kein Warnfenster, keine Meldung, einfach durch. Die Grenzen dieser Messung gehören dazu: BadSSL prüft generisch, nicht den konkreten eMudhra-Fall. Die Konfiguration, die hier durchläuft, ist aber exakt die, die den Fall ungreifbar macht. Nicht ein kaputter Root, den jeder Browser sofort bemerken würde, sondern Widerruf und Sperrung, die im Standardpfad der meisten Klienten schlicht nicht abgefragt werden. Meine Agentenautomation ist dafür ein Musterbeispiel: Radarabfragen, Updatejobs und Installer auf diesem Deck laufen über genau die Standardkonfiguration, die ich hier vermessen habe. Ein Angreifer hätte nichts manipulieren müssen, außer ein passendes Zertifikat unter den kompromittierten CAs auszustellen und auf dem Netzweg zu sitzen. Wer das mit höherem Einsatz durchspielen will, findet bei Scott Helme den passenden Test: ein lokaler Server mit einem Zertifikat auf den Namen api.stripe.com, ausgestellt unter einer der eMudhra-Stellen. Mit Standardeinstellungen erklärte curl SSL certificate verify ok, Python vollendete den TLS-Handshake, Node meldete authorized true, auf allen seinen Linux- und macOS-Testmaschinen. Unter Windows akzeptierte CryptoAPI die Kette, bis man die Widerrufsprüfung einschaltete, und selbst dann antwortete nur eine von zwei Prüfrouten mit widerrufen. Die Ebene, auf der dieser Fall hätte landen können, existiert in den meisten Stacks schlicht nicht.

Wer betroffen ist: alles, was kein Browser ist

Aktualisierte Hauptbrowser kommen vergleichsweise glimpflich davon. Chrome und Firefox blockieren die Zwischenzertifikate direkt und erzwingen Zertifikatstransparenz, Safari erzwingt ebenfalls CT. Der Rest der Welt ist das eigentliche Thema. Nicht-Browser-TLS-Klienten mit Standardeinstellungen teilen drei Gewohnheiten: Sie vertrauen einem CA-Bundel auf der Festplatte, sie prüfen Widerruf von Haus aus nicht, und sie prüfen CT nicht. Ob eMudhra und Sectigo die Zwischenzertifikate widerrufen haben, verändert ihr Verhalten nicht im Geringsten. Die betroffenen Klassen sind eine lange Liste. Installations- und Selbstupdate-Wege, die Skripte über HTTPS nachladen: rustup, nvm, der Homebrew-Installer, Dutzende install.sh-Seiten und IoT-Firmware-Updater landen ohne Signaturprüfung Code mit Rootrechten auf der Maschine. CI- und CD-Läufer auf veralteten Basisschichten, die Abhängigkeiten ziehen, Artefakte hochladen und nebenbei Cloud-Zugänge, Registry-Tokens und Signierungsschlüssel in ihren Umgebungen halten. Server-an-Server-Verbindungen wie Zahlungsanbieter, Webhooks, OAuth-Tokenaustausch und Cloud-SDKs mit eigenen Certifi-Bundels. Embedded- und OT-Geräte mit eingefrorenen Bundels, Kameras, Router, Autos, Medizingeräte, Zahlterminals und Industriecontroller. Helmes Rechnung reicht bis 2039, so lange viele dieser Bundels den eMudhra-Root weiter im Speicher halten. Und außerhalb von TLS hat dieselbe Schwäche auf die Windows-Codesignierung übergegriffen: Windows vertraut dem eMudhra-CS-Root direkt, Schadsoftware unter den EM OV CS CA-Schlüsseln sieht für alles, was Widerruf nicht prüft, aus wie ein Produkt eines echten Verlags.

Was ich konkret umsetze

Fünf Dinge lassen sich heute erledigen, ohne auf einen Hersteller zu warten. Erstens die Zertifikatsbundels aktualisieren, auf allen Maschinen, in Containern und in CI-Images. Mozilla hat den Root am 20. Oktober entfernt, auf Debian-artigen Systemen reist die Änderung mit den üblichen ca-certificates-Updates, sobald man sie einspielt. Zweitens CI-Umgebungen auffrischen, keine monatelangen Basisschichten für Jobs, die über das Netz sprechen. Drittens Widerrufs- und CT-Prüfung dort einschalten, wo der Aufruf kritisch ist, in curl-Skripten die passenden Flags, in Anwendungen die Bibliothekseinstellungen, bewusst konfiguriert statt voreingestellt. Viertens kein blindes curl-pipe-sh mehr auf Maschinen, die mir wichtig sind, releases mit festen Pins beziehen, Prüfsummen kontrollieren, Installer-Wege dokumentieren. Fünftens, und das ist die eigentliche Lektion für den Agentenalltag: Updates sind Teil der Sicherheitsarchitektur, nicht Hausmeisterarbeit. Ein Agent, der täglich Automationen über das Netz fährt, fährt auf denselben Standardpfaden wie jeder andere TLS-Klient, mit demselben Bundel und denselben Lücken. Auf dem Cyberdeck steht deshalb jetzt notiert: Was vertraut, muss wissen woran es vertraut, und wie oft es nachsieht.

Dieses System hat nichts versprochen, das es dann nicht gehalten hätte. Es hat nur nie versprochen, den Widerruf für dich zu prüfen. Wer Vertrauen an Maschinen delegiert, delegiert die Prüfungen gleich mit, oder er delegiert die Ausreden mit.

FAQ

Wer ist von dem eMudhra-Fall betroffen? Aktualisierte Browser weitgehend nicht, sie blockieren die acht Zwischenzertifikate direkt. Betroffen ist alles, was kein Browser ist: curl, Python, Java, Git, Paketmanager, CI-Läufer, Installations- und Selbstupdate-Wege, Server-zu-Server-Integrationen, Embedded-Geräte und die Windows-Codesignierung, solange Bundel und Widerrufslogik nicht aktualisiert sind. Kann man die Schlüssel reparieren, ohne alle Klienten zu aktualisieren? Nein. Die Schlüssel wurden nicht gestohlen, sie waren von der Konstruktion her öffentlich. Die einzige Korrektur ist, das Vertrauen zu entziehen, und das erfordert Updates auf der Klientenseite. Wie wurde der Fall entdeckt und eingedämmt? Ein Sicherheitsforscher meldete ihn am 17. Oktober 2026 an Apple, Google, Microsoft, Mozilla und eMudhra. Chrome verteilte noch am selben Abend ein CRLSet-Update, Firefox folgte mit OneCRL. Am 20. Oktober machte Mozilla die Sperrung öffentlich und entfernte den eMudhra-Root per NSS-Update. Warum hilft der Widerruf durch eMudhra und Sectigo nichts? Weil Widerruf nur Klienten schützt, die ihn auch abfragen. Die meisten Nicht-Browser-Klienten prüfen in ihrem Standardpfad überhaupt keinen Widerruf, sie vertrauen einfach ihrem lokalen Bundel. Was kann ich heute konkret tun? Bundel und CI-Images aktualisieren, Widerrufs- und CT-Prüfung für kritische Aufrufe einschalten und keine blinden Installer aus dem Netz mehr in die eigene Shell pipe-n.

Über den Autor

Ich bin Marcel, ich baue d4sn3st.dev und betreibe das HUNTER-Cyberdeck auf einem Pixel 6a. Dieser Beitrag stützt sich auf die eigene A/B-Messung vom 23. Oktober 2026 in meiner Linux-Umgebung auf dem Telefon sowie auf die im Quellenverzeichnis genannten Dokumente. Zuletzt fachlich geprüft am 23.10.2026. Details zum Setup: HUNTER-Cyberdeck

Quellen

• Scott Helme: Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds, https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/ (abgerufen 23.10.2026)
• Mozilla dev-security-policy: Ankündigung zur Sperrung, https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ (abgerufen 23.10.2026)
• Hacker-News-Diskussion mit 927 Punkten am 23.10.2026, https://news.ycombinator.com/item?id=50177916 (abgerufen 23.10.2026)
• Testobjekte der eigenen Messung: revoked.badssl.com und untrusted-root.badssl.com (Messung 23.10.2026, Cyberdeck)
• Eigene Messung: curl- und Python-A/B-Test auf dem Cyberdeck, Protokoll im Text (23.10.2026)