Acht kompromittierte CA-Schlüssel stellen so manchem von uns im Oktober 2026 vor eine ziemlich grundlegende Frage:
„Was nützt der Widerruf eines Zertifikats, wenn Anwendungen weiterhin darauf vertrauen?“
Zertifikat widerrufen. Trotzdem vertraut?
Am 30. Oktober informiert mich JetBrains Research am späten Freitagabend – wie viele andere auch – per eMail über die Auswirkungen des eMudhra Sicherheitsvorfalls auf seine Entwicklungswerkzeuge.
JetBrains informiert am 30.Oktober 2026 per eMail über ein Security update wegen kompromittierter eMudhra Zertifikate
Betroffen sind unter anderem die IDEs also die Entwicklerwerkzeuge für Software, Laufzeitumgebungen und weitere Produkte.
Wichtig ist: Die Ursache liegt nicht bei JetBrains. Vielmehr führt die Vertrauenskette, so wie auch schon bei PHP2Shell auch dorthin.
Am 17. Oktober wird bekannt, dass sich die privaten Schlüssel von acht eMudhra-Zwischenzertifizierungsstellen aufgrund unzureichender Zufallswerte von Cyberkriminellen rekonstruieren lassen.
Damit können Angreifer Zertifikate erzeugen, die auf nicht ausreichend geschützten Systemen als vertrauenswürdig erscheinen.
Halloween kam dieses Jahr pünktlich: Acht kompromittierte CA-Schlüssel und die Frage, ob Revocation in der Praxis wirklich greift…
eMudhra widerruft die betroffenen Intermediate-Zertifikate. Mozilla , Google und weitere Anbieter reagieren mit Revocation über Sperrlisten und Änderungen an ihren Vertrauensspeichern.
„Aber wer überprüft, ob diese Maßnahmen in einer konkreten Anwendung tatsächlich greifen?“
Widerrufen ist nicht gleich abgelehnt.
Eine digitale Signatur beweist, dass bestimmte Daten mit einem bestimmten kryptografischen Schlüssel signiert wurden.
Signaturen beweisen hingegen nicht, dass wir dem signierten Schlüssel weiterhin vertrauen dürfen.
Für eine wirksame Vertrauensentscheidung benötigen wir weitere Informationen:
- Wer stellt das Zertifikat aus?
- Welche Vertrauenskette akzeptiert die Anwendung?
- Ist ein Zertifikat widerrufen?
- Welche Regeln und Vertrauensanker gelten zum Zeitpunkt der Prüfung?
Die Antworten darauf fallen unterschiedlich aus. Browser, Betriebssysteme, Java-Laufzeitumgebungen und Anwendungen mit eigenen Zertifikatsspeichern nutzen andere Mechanismen.
🎧 Listen on Spotify: 👉 https://bit.ly/42fJQZS
🍎 Enjoy on Apple Podcasts: 👉 https://apple.co/42KMKWu
Mozilla sperrt die betroffenen Zertifikate über OneCRL. Chrome nutzt CRLSets. Wieder andere Anwendungen erhalten entsprechende Schutzmaßnahmen erst durch Aktualisierungen ihrer Bibliotheken oder Vertrauensspeicher.
Dass Browser kompromittierte Zertifikate sperren, bedeutet nicht, dass andere Anwendungen diese ebenfalls zurückweisen. Sie können eigene Vertrauensspeicher, andere Verfahren zur Validierung von Revocation oder Bibliotheken verwenden, weldche die betroffenen Zertifikate weiterhin akzeptieren.
Warum kann der Vorfall jede Website betreffen?
Das eigentlich Erschreckende am eMudhra-Vorfall: Keine einzige betroffene Website muss selbst kompromittiert sein.
Denn in diesem Fall wurden keine TLS-Schlüssel einzelner Websites gestohlen. Die privaten Schlüssel von acht übergeordneten Intermediate-Zertifizierungsstellen lassen sich aufgrund fehlerhafter Schlüsselerzeugung rekonstruieren.
Sechs dieser Schlüssel dürfen TLS-Zertifikate signieren.
Ein Angreifer kann damit Zertifikate für fremde Websites ausstellen – unabhängig davon, von welcher Zertifizierungsstelle deren Betreiber ihre echten Zertifikate beziehen.
Das gilt für Banking-Portale ebenso wie für Onlineshops, Git-Repositories und Identity Provider.
Wenn ein Angreifer zusätzlich den Netzwerkverkehr abfangen oder umleiten kann und die betroffene Anwendung der gefälschten Zertifikatskette vertraut, kann er sich als legitimer Server ausgeben.
Die echte Website bleibt dabei möglicherweise vollkommen unangetastet. Angegriffen wird die Vertrauensentscheidung des Clients.
Das ist der entscheidende Unterschied!
eMudhra – 8 kompromittierte Certificate Authorities (CAs)-Schluessel – Angriffsvektoren und Schadensszenarien
Ich habe zur Veranschaulichung der Angriffsvektoren und Schadendszenarien für Euch folgende Grafik aufbereitet:
eMudhra – 8 kompromittierte Certificate Authorities (CAs)-Schluessel – Angriffsvektoren und Schadensszenarien – Illustration Sascha Block – www.rock-the-prototype.com
Mozilla und Google reagierten bereits am 17. Oktober mit Sperrmaßnahmen. Moderne Browser setzen außerdem vielfach Certificate Transparency durch und können nicht protokollierte Zertifikate ablehnen.
Zwei andere kompromittierte Artefakte waren Signatur Schlüssel für Software. Doch Software nutzt andere Mechanismen innerhalb ihrer meist individuell ausgeprägten Vertrauenskette.
Deshalb war hier besonders brisant, dass etwa Kommandozeilenwerkzeuge, Serveranwendungen, Entwicklungsumgebungen und Anwendungen mit eigenen Zertifikatsspeichern wiederum diesen kompromittierten Schlüsseln weiterhin Vertrauen schenkte.
Selbst ein aktualisiertes Betriebssystem hat in diesem Fall keinen Schutz geboten, sofern dessen Komponenten also die damit installierten Anwendungen, soweit diese betroffen waren, geschützt sind.
Wer prüft also, welchen Zertifizierungsstellen unsere Anwendungen tatsächlich vertrauen – und ob sie kompromittierte Zertifikatsketten zuverlässig ablehnen?
Eine öffentlich zugängliche Website hat hier erste konkrete Test-Zertifikatsketten und Prüf-Endpunkte bereitgestellt:
https://emudhra.we-have-a-problem.com/
Diese Website lieferte auf für mich wertvolle Informationen und war der Ausgangspunkt für meine eigenen Tests am Rust-BFF.
Viel relevanter für mich bleibt die Frage, wie wir solche Sicherheitsentscheidungen künftig reproduzierbar nachweisen können.
Was bedeutet das für unsere Software?
Ich habe den Vorfall zum Anlass genommen, die Abhängigkeiten meines öffentlich entwickeltes Backend-for-Frontend (BFF) für Rock the Prototype zu prüfen.
Dieses Backend-for-Frontend (BFF) entwickle ich in Rust. Rust eignet sich dafür besonders, weil diese Programmiersprache viele Speicher- und Nebenläufigkeitsfehler bereits beim Kompilieren verhindert, einen ressourcenschonenden Betrieb ermöglicht und eine robuste Grundlage bietet, um den Prototyp später produktiv einzusetzen.
In meinem YouTube Video 🍪 Cookies, Session & Token ❇️ Token Flow in 10min verstehen erfährst du leicht verständlich aber präzise die technischen Grundlagen:
- Wie entsteht eine authentifizierte Identität, wer überprüft sie und welche Komponente darf ihr vertrauen?
- Warum ein Backend for Frontend, Tokens serverseitig sicher verwalten kann.
- Wie DPoP oder mTLS ein Token kryptografisch an einen legitimen Client binden können.
Das Backend-for-Frontend übernimmt den Anmeldeprozess über OpenID Connect und überprüft die Identität anhand des signierten ID-Tokens und der zugeordneter Daten eines Nutzers. Die authentifizierte Sitzung verwaltet das BFF serverseitig in Redis. Der Browser erhält ein geschütztes Session-Cookie.
Access- und Refresh-Tokens verbleiben auf dem Server und werden nicht an den Browser übertragen. Das Backend-for-Frontend-Pattern gilt gemäß RFC 10017 (BCP 212), „OAuth 2.0 for Browser-Based Applications“, als sicherste der dort verglichenen OAuth-Architekturen für browserbasierte Anwendungen. Die Internet Engineering Task Force (IETF) empfiehlt das BFF-Muster ausdrücklich für sicherheitssensible Webanwendungen.
Dabei nutzt mein Rust-BFF unter anderem zwei relevante Komponenten:
- webpki-roots, das vertrauenswürdige Stammzertifikate bereitstellt.
- rustls-webpki, das Zertifikatsketten prüft.
Natürlich in den jeweils aktuellen Versionen, denn die neue Version von rustls-webpki weist Zertifikatsketten mit bestimmten kompromittierten öffentlichen Intermediate-Schlüsseln ausdrücklich zurück.
Parallel müssen wir die Identitätsbindung in einer Anwendung wie meinem BFF selbst überprüfen. Dabei verbessern wir die Verwendung aktualisierter OIDC-Signaturschlüssel wenn wir einen negativen Test ergänzen: Stimmen die Identitäten aus ID-Token und UserInfo nicht überein, weist das BFF die Authentifizierung zurück.
Die Änderungen sind in meinem öffentlichen GitHub-Repository integriert und über Pull Requests und automatisierte Tests nachvollziehbar.
Doch zwei weitere RustSec-Befunde benötigen noch eine dokumentierte Risikobewertung. Denn auch der eigenständige Nachweis, dass unser konkreter TLS-Verifikationspfad die kompromittierten Zertifikatsketten ablehnt, steht noch aus.
Secure by Design – how should secure processes look like today?
Wie lässt sich Vertrauen nachweisbar prüfen?
Für mich ergibt sich daraus eine klare technische und organisatorische Anforderung.
Wir benötigen eine nachvollziehbare Verbindung zwischen den Komponenten unserer Software, den tatsächlich verwendeten kryptografischen Verfahren, den geltenden Vertrauensregeln und den Ergebnissen konkreter Prüfungen.
Der OWASP CycloneDX SBOM/xBOM Standard bietet dafür eine soldide Grundlage.
Eine Software Bill of Materials (SBOM) macht die verwendeten Softwarekomponenten und Abhängigkeiten sichtbar.
Eine Cryptography Bill of Materials (CBOM) kann kryptografische Assets wie Algorithmen, Schlüssel und Zertifikate mit diesen Komponenten verbinden.
Was damit noch fehlt, ist der eigentliche Wirksamkeitsnachweis.
Akzeptiert die Anwendung eine gültige Zertifikatskette – und lehnt sie eine kompromittierte Zertifikatskette nachweislich ab?
Ein solcher Test muss reproduzierbar sein. Er muss sich auf einen bestimmten Softwarestand und eine konkrete Vertrauenskonfiguration beziehen. Und sein Ergebnis muss nachvollziehbar bleiben.
Mit dem Agile Innovation Framework (AIF) möchte ich genau solche Zusammenhänge abbilden: von der Anforderung über das Prüfverfahren und die Beobachtung bis zum validierten Ergebnis und dem zugehörigen Nachweis.
Das ist noch kein fertiges Audit-System. Aber es ist ein überprüfbarer Weg, eines transparent und Schritt für Schritt zu entwickeln.
Warum das weit über TLS hinausgeht
Dieselbe Grundfrage begegnet uns bei digitalen Identitäten.
Mit der europäischen EUDI Wallet oder unserer d-you wie die digitale Brieftasche für Deutschland heisst, entstehen neue Vertrauensbeziehungen zwischen Wallets, Ausstellern digitaler Nachweise und prüfenden Organisationen.
Die dort verwendeten Vertrauenslisten, Zertifikate und Statusmechanismen unterscheiden sich von der Web-PKI. Die fachliche Herausforderung bleibt jedoch vergleichbar:
Eine gültige kryptografische Signatur allein reicht nicht. Entscheidend ist auch, ob der Aussteller für den jeweiligen Zweck vertrauenswürdig und der vorgelegte Nachweis zum Prüfzeitpunkt gültig ist.
Damit wird die Überprüfung digitaler Vertrauensentscheidungen zu einer Aufgabe des gesamten Softwarelebenszyklus.
Sicherheit erfordert weit mehr als laufende Updates.
Schon beim Sicherheitsvorfall PHP2Shell haben wir die Bedeutung gemeinsam genutzter Open-Source-Infrastruktur und ihrer langfristigen Pflege betrachtet.
Der eMudhra-Vorfall macht eine weitere Dimension sichtbar.
Selbst wenn Maintainer schnell reagieren und Sicherheitsupdates veröffentlichen, müssen Organisationen erkennen, welche ihrer Systeme betroffen sind, die Änderungen nachvollziehbar integrieren und ihre Wirksamkeit prüfen.
Das verlangt technische Fähigkeiten. Vor allem aber verlangt es Verantwortlichkeit, transparente Entscheidungen und überprüfbare Ergebnisse.
Mein Ziel ist deshalb nicht nur, vertrauenswürdige Software zu entwickeln. Ich möchte nachvollziehbar machen, warum wir ihr vertrauen dürfen – und wie wir neue Erkenntnisse in wirksame Änderungen übersetzen.
IT Sicherheit und effektive Collaboration erfordern Transparenz.
Genau deshalb gibt es Rock the Prototype.
Euer Sascha Block
Quellen und technische Referenzen
JetBrains – eMudhra Certificate Authority Incident:
Mozilla – Reaktion auf die kompromittierten Intermediate-Zertifikate:
Google – Chrome und Android:
RustSec – webpki-roots:
https://rustsec.org/advisories/RUSTSEC-2026-0381
RustSec – rustls-webpki:
https://rustsec.org/advisories/RUSTSEC-2026-0382
CycloneDX – Cryptography Bill of Materials:
https://cyclonedx.org/capabilities/cbom/
EUDI Wallet – Vertrauensprüfung:
https://eudi-wallet.gov.de/faq
Mein öffentlicher BFF-Prototyp:
Über den Autor:
Sascha Block
Ich bin Sascha Block – IT-Architekt in Hamburg und der Initiator von Rock the Prototype. Ich möchte Prototyping erlernbar und erfahrbar machen. Mit der Motivation Ideen prototypisch zu verwirklichen und Wissen rund um Software-Prototyping, Softwarearchitektur und Programmierung zu teilen, habe ich das Format und die Open-Source Initiative Rock the Prototype geschaffen.
