Intermediate-CA-Kompromittierung: Wenn Ketten reißen

Hier ist eine Behauptung, die verkehrt klingt: Die schlimmsten Vorfälle bei Zertifizierungsstellen sind nicht die, bei denen ein Angreifer einbricht. Der aktuelle Kompromittierungsfall bei der eMudhra-Intermediate-CA beweist das. Acht Intermediate-CA-Schlüssel ließen sich allein aus den Zertifikaten rekonstruieren, ganz ohne Einbruch, weil die Schlüsselerzeugungszeremonie der CA selbst Private Keys hervorbrachte, die so schwach waren, dass einer davon buchstäblich die Zahl 4 war. Niemand hat diese Schlüssel gestohlen. Sie waren von Geburt an kompromittiert. Und das ist ein beunruhigenderer Fehlermodus als jeder Einbruch, denn man kann ihn nicht mit einer Credential-Rotation und dem Stopfen eines Lochs beheben. Das Vertrauen selbst war vom ersten Tag an fehlerhaft.

Wenn Sie irgendetwas betreiben, das TLS-Verbindungen außerhalb eines Browsers aufbaut, und das tun Sie, lohnt sich dieser Fall Ihre Aufmerksamkeit. Browser waren innerhalb weniger Tage geschützt. Der Rest des Ökosystems holt noch auf: die curl-Aufrufe in Ihren Cron-Jobs, die Python-Dienste mit gepinntem certifi, die Go-Binaries mit eingebauten Root-Stores. Ich gehe durch, was tatsächlich passiert ist, warum eine Intermediate-Kompromittierung grundsätzlich schlimmer ist als eine Leaf-Kompromittierung und was die ungleichmäßige Behebung über den Zustand der Sperrmechanismen im modernen Internet verrät.

Was bei eMudhra tatsächlich schiefging

Laut der eigenen vorläufigen Bewertung der CA im Mozilla-Incident-Tracker ist die Geschichte fast schmerzhaft banal. Ein Skript für die Schlüsselerzeugungszeremonie, also der kontrollierte, auditierte Prozess, mit dem eine CA ihre sensibelsten Schlüssel erzeugt, wurde mit einer genehmigten Abweichung geändert, um einen Key-Wrap/Unwrap-Vorgang für den Export zu testen. Ein Fehler in diesem geänderten Code führte dazu, dass ein zweiter Satz ECC-Schlüssel auf dem HSM erzeugt wurde, und diese Schlüssel waren schwach. Nicht „verminderte Entropie“-schwach, sondern trivial aus dem öffentlichen Zertifikat rekonstruierbar.

Denken Sie darüber nach, was das bedeutet. Ein ECC-Private-Key soll eine zufällige 256-Bit-Zahl sein. Die Sicherheit des gesamten Verfahrens beruht auf dem Problem des diskreten Logarithmus: Gegeben den öffentlichen Schlüssel, sollte das Finden des privaten Skalars rechnerisch unmöglich sein. Wenn Ihr „Zufallswert“ aber ein einzelnes Byte ist, ist der öffentliche Schlüssel nur der Generatorpunkt, multipliziert mit diesem Byte, und jeder kann alle 256 Möglichkeiten in Mikrosekunden auf einem Laptop durchprobieren. Einer der acht Schlüssel war angeblich die ganze Zahl 4. Das ist im traditionellen Sinne keine Kompromittierung, sondern ein Zertifikat, das nie wirklich sicher war, ausgestellt unter einer Root, der Mozilla, Microsoft, Apple und Chrome vertrauen.

Der Forscher, der es meldete, mit Namen Wayne, bewies den Besitz, indem er eine Nachricht mit jedem der acht privaten Schlüssel signierte und die Signaturen an die Root-Programme schickte. Jeder konnte den Beweis mit ein paar OpenSSL-Befehlen prüfen: den öffentlichen Schlüssel aus jedem Intermediate-Zertifikat extrahieren und dann kontrollieren, ob die Signatur der Nachricht damit verifiziert. Das ist das Elegante und zugleich Erschreckende am kryptografischen Besitznachweis. Es gibt keine Mehrdeutigkeit und keinen Nebel aus „Wir nehmen Sicherheit ernst“-PR. Die Mathematik geht auf oder nicht. Sie ging auf.

Warum eine Intermediate-CA-Kompromittierung schlimmer ist als eine Leaf-Kompromittierung

Wenn der private Schlüssel eines Leaf-Zertifikats leakt, etwa weil Ihr Schlüssel für api.example.com in einem öffentlichen GitHub-Repo landet, umfasst der Schaden einen Hostnamen, vielleicht ein paar, wenn es ein Wildcard-Zertifikat ist. Sie sperren das Zertifikat, stellen ein neues aus und machen weiter. Lästig, aber nicht existenziell.

Ein Intermediate-CA-Schlüssel ist ein völlig anderes Tier. Die Web-PKI funktioniert als Kette von Signaturen: Eine Root-CA, offline gehalten und bewacht wie nukleares Material, signiert Intermediates, und Intermediates signieren die Leaf-Zertifikate, die Server tatsächlich vorlegen. Wer den privaten Schlüssel einer Intermediate besitzt, ist für alle kryptografischen Zwecke diese CA. Er kann ein gültiges Zertifikat für google.com ausstellen, für Ihre Bank, für Ihre interne SSO-Domain, und jeder Client, der der Kette vertraut, akzeptiert es ohne Murren. Es gibt kein Rate-Limit, keine zentrale Instanz, die man anrufen könnte, und keine Möglichkeit, eine betrügerische, aber gültige Signatur von einer legitimen zu unterscheiden.

Der eMudhra-Vorfall vervielfachte das mit acht Intermediates, von denen einige über Sectigo-Roots quersigniert waren und in Trust-Stores münden, die auf Milliarden Geräten ausgeliefert werden. Etwa eineinhalb Jahre, von der Erstellung der fehlerhaften Zertifikate bis zur Offenlegung, hätte jeder Client, der diesen Intermediates vertraute und Certificate Transparency nicht erzwang, von jedem imitiert werden können, der die Schlüssel rekonstruieren wollte. Das ist das Zeitfenster. Wir wissen schlicht nicht, ob es jemand ausgenutzt hat, und ohne einen glücklichen Treffer im CT-Log oder einen beobachteten Angriff werden wir es vielleicht nie erfahren.

Deshalb behandeln Root-Programme Intermediate-Vorfälle mit einem Schweregrad, den Leaf-Vorfälle nie bekommen. Einer Intermediate das Vertrauen zu entziehen bedeutet, dass jedes Zertifikat, das sie je ausgestellt hat, ungültig wird, und tausende Websites brechen gleichzeitig. Der Symantec-Distrust, der sich über Jahre hinzog, ist das klassische Beispiel dafür, wie schmerzhaft die vollständige Behebung wird, wenn die Abläufe einer CA als nicht vertrauenswürdig gelten. Das System funktioniert, aber es funktioniert wie eine Amputation, nicht wie eine Operation.

Certificate Transparency als unbeabsichtigter Held

Der Teil der Geschichte, der mehr Aufmerksamkeit verdient: Chrome, Safari, Firefox und Edge waren wohl bereits geschützt, bevor jemand wusste, dass es ein Problem gibt. Nicht wegen der Sperrung, sondern wegen Certificate Transparency.

CT-erzwingende Browser verlangen, dass jedes öffentlich vertrauenswürdige Zertifikat, das sie akzeptieren, in öffentlichen, nur anhängbaren CT-Logs protokolliert ist. Den kompromittierten eMudhra-Intermediates fehlen CT-Log-Einträge für den fraglichen Zeitraum. Das bedeutet, dass jedes Leaf-Zertifikat, das ein Angreifer mit diesen Schlüsseln erzeugt hätte, von CT-erzwingenden Clients ohnehin abgelehnt worden wäre, weil es ohne gültige signierte Certificate Timestamps angekommen wäre. Der Betrug hätte veröffentlicht werden müssen, um geglaubt zu werden, und die Veröffentlichung hätte ihn sofort aufgedeckt.

CT wurde entwickelt, um Fehlausstellungen nachträglich zu erkennen und betrügerische Zertifikate auffindbar zu machen. In diesem Vorfall wirkte es als präventive Kontrolle: Es machte die kompromittierten Schlüssel gegenüber der Browserpopulation nahezu nutzlos, also dem wertvollsten Ziel für massenhafte Abfangangriffe. Das ist eine wirklich gute Nachricht für ein Infrastrukturelement, an das die meisten Ingenieure nie denken.

Aber, und hier muss ich meinen Optimismus einschränken: CT-Durchsetzung ist im Grunde ein Luxus der Browser. Die große Mehrheit der TLS-Clients im Internet prüft keine SCTs. Ihr curl-Aufruf tut es nicht. Ihr Python-requests-Aufruf tut es nicht. Die IoT-Flotte, die bei einer Vendor-Cloud nach Hause telefoniert, tut es nicht. Für all diese war der einzige Schutz, dass Sperrdaten rechtzeitig den Trust-Store erreichen, und genau dort wird die Geschichte hässlich.

Die Sperrlücke: Browser versus alles andere

Die Browser-Hersteller haben das gut gehandhabt, und sie verdienen Anerkennung für Infrastruktur, die vor einem Jahrzehnt aufgebaut wurde. Mozilla liefert seit über zehn Jahren OneCRL aus, einen Push-Mechanismus, um Intermediate- und Root-Zertifikaten das Vertrauen zu entziehen, und hat diesen Vorfall für Firefox-Nutzer innerhalb von Stunden behoben, ganz ohne Browser-Update. CRLSets von Chrome und die entsprechenden Mechanismen von Apple taten dasselbe auf ihren Plattformen innerhalb weniger Tage. Die CA hat die Intermediates gesperrt. Aus Sicht eines Browser-Nutzers war dieser Vorfall vorbei, bevor er richtig begonnen hatte.

Die Nicht-Browser-Welt sieht anders aus. Die Liste der Behebungen liest sich wie ein Inventar der Software-Lieferkette: aktualisierte ca-certificates-Pakete für Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; ein neues NSS-Release; ein neues curl-CA-Bundle; certifi für Python; rustls-webpki und webpki-roots für Rust; Go-Point-Releases; Electron-Patchversionen über drei Release-Linien; Composers ca-bundle; Elixirs castore. Jedes davon ist ein eigenes Artefakt, auf einem eigenen Release-Rhythmus, konsumiert von einem eigenen Update-Mechanismus. Manche waren noch Tage nach der Offenlegung ausstehend.

Und dann gibt es die Kategorie, die mich nachts wachhält: Software, die ihren eigenen CA-Store im Binary mitliefert. Ein statisch gelinkter Go-Dienst, der letztes Jahr gebaut wurde, trägt seine Roots im kompilierten Artefakt. Neu bauen und neu deployen ist die einzige Lösung, denn es gibt kein Systempaket, das man patchen könnte. Multiplizieren Sie das mit jedem Container-Image in Ihrer Registry mit einer eingebauten /etc/ssl/certs-Schicht, jeder Electron-App auf jedem Desktop und jedem Firmware-Image auf jedem verbundenen Gerät, und Sie sehen die Form des Problems. Der System-Trust-Store ist der einfache Teil. Wir haben bereits geschrieben, wie eingebettete und OT-Geräte Sicherheitsvorfälle in mehrjährige Dauerbaustellen verwandeln; eine kompromittierte CA ist genau die Art Ereignis, bei dem diese Geräte schlicht nie gepatcht werden.

Das lange Ende der Trust-Stores, die niemand besitzt

Dieser Vorfall hat einen Sonderfall, der einen eigenen Absatz verdient, weil er so anschaulich ist: macOS. Apples Plattform blockierte die kompromittierten Intermediates auf OS-Ebene rasch. Aber das eingebaute /usr/bin/curl prüft gegen /etc/ssl/cert.pem, eine Datei, die nicht aktualisiert wurde, und prüft keine Sperrungen. Man kann also einen vollständig gepatchten Mac haben, auf dem Safari ein gefälschtes Zertifikat ablehnt, während dasselbe curl auf demselben Rechner es fröhlich akzeptiert. Zwei Vertrauensentscheidungen, eine Maschine, gegensätzliche Antworten.

Diese Fragmentierung ist die eigentliche Lehre. Wir reden oft über „die Web-PKI“, als wäre es ein einziges System. Tatsächlich sind es Dutzende Systeme mit sehr unterschiedlichen Eigenschaften:

• Browser: Push-basierte Sperrung (OneCRL, CRLSets), CT-Durchsetzung, automatische Updates. Behebung in Stunden bis Tagen.
• OS-Trust-Stores: paketverwaltete Updates (ca-certificates, ca_root_nss). Die Behebung hängt vom Release-Rhythmus der Distribution ab und davon, ob die Maschine je gepatcht wird.
• Sprach-Ökosysteme: certifi, webpki-roots, die eingebetteten Roots von Go, das gebündelte Mozilla-Set von Node. Die Behebung heißt: ein Release schneiden und auf Abhängigkeits-Updates in tausenden Projekten warten.
• Kompilierte Artefakte und Images: Binaries, Container, Firmware. Behebung heißt neu bauen und neu deployen, was in der Praxis einen langen verwundbaren Schwanz bedeutet, der sich über Jahre zieht.
• IoT und Embedded: oft gar kein Update-Pfad. Faktisch dauerhafte Exposition.

Die Browser haben ein Jahrzehnt in genau dieses Szenario investiert. Fast niemand sonst hat das getan. Ein Kommentar von der Mozilla-Seite brachte es unverblümt auf den Punkt: Außerhalb des Browser-Ökosystems gab es kaum bis gar keine Investitionen in Sperrmechanismen, und für diese Clients ist diese Art von Vorfall ein massives Problem. Das deckt sich mit allem, was ich beim Betrieb von Infrastruktur gesehen habe. Wenn Sie sich schon mit den blinden Flecken beim Logging von Cloud-Authentifizierungsereignissen befasst haben, kennen Sie das Muster: Der kritische Pfad ist gut instrumentiert, und der lange Schwanz ist ein dunkler Raum.

So prüfen Sie, ob Ihre Clients noch verwundbar sind

Theorie beiseite: Sie sollten Ihren Bestand tatsächlich testen, und das Schöne an TLS ist, dass man es empirisch prüfen kann. Community-Mitglieder haben Hosts aufgesetzt, die Zertifikate ausliefern, die von den kompromittierten Intermediates signiert wurden. Wenn Ihr Client ohne Zertifikatsfehler verbindet, vertraut er ihnen noch. Das allgemeine Muster zum Testen von curl oder jedem anderen Kommandozeilenwerkzeug sieht so aus:

# A certificate error here means you're protected.
# A successful response means this client still trusts a compromised intermediate.
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/
# You can also test whether a client will accept a forged cert for an
# arbitrary hostname by pointing it at a test server:
curl -v https://example.org --connect-to example.org::2.29.126.86:

Führen Sie das in jedem relevanten Kontext aus: auf Ihren Entwickler-Laptops, Ihren CI-Runnern, Ihren Container-Base-Images und Ihren Serverflotten. Die Antworten werden sich unterscheiden, und genau diese Unterschiede sind der Punkt. Für ein schnelles Inventar dessen, was aktualisiert werden muss:

• Go-Dienste: mit Go 1.27.3 oder 1.26.10 oder neuer neu bauen, denn die Roots sind einkompiliert.
• Python: certifi 2026.10.19 oder neuer (prüfen Sie auch die Versionen von pip und uv, die ihr eigenes Bundle mitbringen).
• Rust: rustls-webpki 0.103.16 und webpki-roots / webpki-root-certs 1.0.10.
• Node.js und Electron: ausstehende oder Patch-Releases je Release-Linie; prüfen Sie jedes ausgelieferte Artefakt.
• System-Stores: aktualisierte ca-certificates-Pakete sind verfügbar für Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; FreeBSDs ca_root_nss war zum Zeitpunkt des Schreibens noch ausstehend.

Wenn Sie nicht auf ein Paket warten können, erlauben die meisten Linux-Distributionen, die betroffenen Roots manuell zu entziehen. Auf Debian/Ubuntu markieren Sie die Zertifikate in /etc/ca-certificates.conf mit einem !-Präfix und führen update-ca-certificates aus; in der Fedora/RHEL-Familie extrahieren Sie die Roots nach /etc/pki/ca-trust/source/blocklist/ und führen update-ca-trust aus. NixOS bietet eine saubere deklarative Option:

security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];

Beachten Sie, was Sie bei diesen Workarounds tatsächlich entziehen: die Roots, an die diese Intermediates gebunden sind. Das ist die grobe Realität der PKI-Behebung. In den meisten Trust-Store-Werkzeugen gibt es kein Primitiv, mit dem man nur eine einzelne Intermediate entzieht. Also setzen Sie einen Root auf die Blockliste und akzeptieren den Kollateralschaden an unbeteiligten Zertifikaten. Im Notfall ist das die richtige Abwägung, aber eben eine Abwägung.

Wo meine kontroverse These zerbricht

Ich habe damit begonnen, dass selbst verschuldete Fehler bei der Schlüsselerzeugung schlimmer sind als Einbrüche. Lassen Sie mich ehrlich sein, wo das bricht. Ein klassischer Einbruch, denken Sie an DigiNotar, impliziert zumindest, dass die CA kompetent arbeitete, bis ein Angreifer sie überlistete, und kompetente CAs sind genau das, worauf das ganze System setzt. Eine Schlüsselzeremonie, die den privaten Schlüssel „4“ ausgibt, impliziert dagegen, dass die geprüften Kontrollen, die HSM-Verfahren und die Compliance-Häkchen nichts von einem katastrophalen Defekt in der sensibelsten Operation bemerkt haben, die eine CA überhaupt ausführt. Das ist kein Gegnerproblem, sondern ein Assurance-Problem, und Assurance ist das gesamte Produkt, das eine CA verkauft.

Wo die Behauptung tatsächlich scheitert: Einbrüche sind schwerer abzuwehren und können länger unbemerkt bleiben. Ein Angreifer, der einen Intermediate-Schlüssel behutsam stiehlt, könnte ihn sparsam für gezielte Abfangangriffe nutzen und nie einen CT-erzwingenden Client berühren. Schwache Schlüssel hingegen sind für jeden auffindbar, der öffentliche Zertifikate scannt, und genau so kam dieser hier ans Licht. Man könnte argumentieren, dass katastrophal-aber-offensichtlich schlimmer ist als subtil-aber-gezielt. Ich kaufe das nicht ganz, aber ich kann es auch nicht wegwischen. Die Wahrheit ist: Beide Fehlermodi landen am selben Ort, bei einer Intermediate, der das Vertrauen entzogen werden muss, und einem langen Schwanz von Clients, die die Nachricht erst in Monaten erhalten.

Was Sie tatsächlich dagegen tun sollten

Die Web-PKI können Sie nicht reparieren. Sie können aber Ihre Angriffsfläche für den nächsten Ausfall verkleinern:

• Testen statt annehmen. Prüfen Sie Ihre Clients gegen Hosts, die die kompromittierten Ketten ausliefern. Das dauert einen Nachmittag und wird Sie überraschen.
• Kompilierte Artefakte neu bauen. Go-Binaries und Container-Images tragen ihre Trust-Stores mit sich. „Wir haben das Base-Image gepatcht“ bedeutet nichts, bis Sie neu deployt haben.
• Trust-Stores inventarisieren. Sie können nichts beheben, was Sie nicht aufgelistet haben. Zählen Sie certifi-Kopien, eingebettete Bundles und Electron-Apps, als ob sie wichtig wären, denn das sind sie.
• Wo möglich System-Trust-Stores bevorzugen. Jedes eingebettete Bundle ist ein Patch, den Sie vergessen werden auszuliefern. Die Zentralisierung auf den OS-Store löst das Problem nicht vollständig, gibt Ihnen aber einen zentralen Ansprechpartner.
• CT- und Sperr-Ökosystem im Blick behalten. Projekte, die browsertaugliche Sperrmechanismen für Nicht-Browser-Clients bringen wollen, existieren und verdienen Unterstützung. Dieser Vorfall ist das beste Argument, das sie je für Finanzierung bekommen werden.
• CA-Vorfälle als Sicherheitsvorfälle behandeln. Sie sollten jemanden alarmieren, eine Inventur auslösen und ein schriftliches Protokoll erstellen, genau wie bei einem geleakten Credential. Denn genau das sind sie.

Das unbequeme Fazit: Die Notbremse der Web-PKI funktioniert wunderbar in genau den Clients, die sie am wenigsten brauchten, weil CT sie bereits abgedeckt hatte. Die Clients, die die Bremse gebraucht hätten, also headless, eingebettet, gebündelt und vergessen, haben meist keine. Die nächste Kompromittierung einer Intermediate-CA ist eine Frage des Wann, nicht des Ob. Die einzige Variable in Ihrer Hand ist, ob Ihr eigener Bestand es bemerkt.