eMudhra-CA-Kompromittierung (CVE-2026-111943): Acht Zwischenzertifikate mit Schlüsseln, die man abzählen kann

TL;DR — 90 Sekunden

• Was: Acht ECDSA-P-384-Intermediates von eMudhra, sechs für TLS und zwei für Code-Signing, wurden bei einer Schlüsselzeremonie am 30. April 2025 mit privaten Schlüsseln kleiner als 256 erzeugt. Aus dem öffentlichen Schlüssel ließ sich der private ohne nennenswerten Aufwand bestimmen.
• Schwere: Für den CA-Vorfall selbst gibt es weder CVE noch CVSS. Go führt seinen Fix als CVE-2026-111943, Firefox als CVE-2026-113470. Ich stufe den Vorfall als kritisch ein, weil die Schlüssel Serverzertifikate für jede Domain signieren konnten, denen viele Nicht-Browser-Clients bis zum Update vertrauen.
• Wen es trifft: Dienste, die TLS ohne Certificate-Transparency-Prüfung validieren und einen Trust-Store von vor dem 20. Oktober 2026 nutzen, also die meisten Container-Images, Go- und Java-Dienste, Python- und Node-Anwendungen und Kubernetes-Controller. Ausnutzen kann das nur, wer sich in die Verbindung setzen kann. Chrome und Firefox sind seit dem 17. Oktober geschützt, Apple, Android und Microsoft folgten bis zum 20. Oktober.
• Was zu tun ist: ca-certificates und sprachspezifische Bundles wie certifi, Composer ca-bundle und Java cacerts aktualisieren, Images neu bauen, Go-Dienste mit Go 1.27.3 oder 1.26.10 neu kompilieren und Node auf 22.23.4, 24.22.1 oder 26.12.1 heben.
• Was vorher geschützt hätte: eine eigene CA für interne Verbindungen, zentral verwaltete und versionierte Trust-Bundles im Cluster und regelmäßige Rebuilds aller Images. CAA-Records und Revocation-Prüfungen helfen gegen diesen Mechanismus nicht.

Acht Schlüssel aus einem winzigen Zahlenraum

Bei elliptischen Kurven besteht der private Schlüssel aus einer einzigen großen Zahl d. Der öffentliche Schlüssel ist der Punkt Q, den man erhält, wenn man einen festen, allgemein bekannten Basispunkt G der Kurve d-mal mit sich selbst verknüpft, kurz Q = d·G. In diese Richtung ist die Rechnung schnell erledigt. Aus Q auf d zurückzuschließen, gilt dagegen als praktisch unmöglich, allerdings nur unter einer Voraussetzung: d muss zufällig aus dem gesamten Zahlenraum der Kurve stammen, der bei P-384 rund 2³⁸⁴ Werte umfasst. Die ganze Sicherheit beruht darauf, dass niemand diesen Raum durchsuchen kann.

Genau hier lag der Fehler. Bei den acht betroffenen Intermediates bestand d laut der Analyse von Scott Helme aus 47 Null-Bytes und einem einzigen Byte mit Inhalt. Im Bugzilla-Eintrag heißt es, alle acht Schlüssel seien ganze Zahlen kleiner als 256 gewesen, und beim Intermediate EM OV TLS CA - G3C war es laut Helme schlicht die 4. Statt 2³⁸⁴ Kandidaten gab es also höchstens 255, und für jeden genügt eine einzige Rechnung, um ihn mit dem veröffentlichten Schlüssel abzugleichen. Wie stark eine Kurve mathematisch ist, spielt keine Rolle mehr, wenn der Schlüssel aus einem so kleinen Ausschnitt stammt.

Tückisch ist, dass solche Schlüssel jede formale Prüfung bestehen. Der Punkt Q liegt korrekt auf der Kurve und ist im Zertifikat sauber kodiert. Was eine CA, ein Browser oder ein Zertifikats-Linter an einem öffentlichen Schlüssel prüft, betrifft seine Form und nicht die Herkunft des geheimen Werts dahinter. Gefunden hat die Schwäche ein Community-Mitglied, das nur als „Wayne“ auftritt. Er signierte mit jedem der acht Schlüssel den Satz „We have a problem here - Wayne“ und belegte so den Besitz, ohne ein einziges Zertifikat auszustellen.

Wie die Schlüssel entstanden sind

Laut der vorläufigen Ursachenanalyse, die eMudhra im Bugzilla-Eintrag veröffentlicht hat, geht der Fehler auf die Zeremonie vom 30. April 2025 zurück. Für einen Test des Wrap- und Unwrap-Vorgangs gab es eine genehmigte Abweichung vom Ablauf, und ein Fehler im Code erzeugte auf den Utimaco-HSMs ein zweites, schwaches Schlüsselpaar. Weil die Labels der Schlüssel einander ähnelten, landete dieses Paar in den Zertifikatsanträgen. eMudhra spricht von menschlichen Fehlern in mehreren Schritten. Ob die Schlüssel tatsächlich im HSM erzeugt oder von außen eingespielt wurden, ist in der Diskussion noch offen, mehrere Beteiligte haben genau das nachgefragt. Was ich daraus ableite: Ein HSM schützt einen Schlüssel vor dem Auslesen, es schützt aber nicht davor, dass ein Skript es mit falschen Parametern arbeiten lässt.

Ein Warnsignal aus dem Jahr 2025

Ein frühes Signal gab es durchaus. Ende Mai 2025 veröffentlichte eMudhra für die sechs TLS-Intermediates Sperrlisten mit ungültigen Signaturen, was Rob Stradling auf Basis von crt.sh in Bugzilla meldete. eMudhra führte das auf eine nicht passende Schlüsselkonfiguration zurück und veröffentlichte am 6. Juni neu signierte Sperrlisten. Nach heutiger Darstellung geschah das mit den schwachen Schlüsseln aus den Zertifikaten, woraufhin die Signaturen stimmten und der eigentliche Fehler verdeckt war. Die Abweichung zwischen dem Schlüssel, der signierte, und dem, der im Zertifikat stand, war also sichtbar. Sie wurde nur als Betriebsproblem gedeutet und nicht als Hinweis auf einen falschen Schlüssel.

Was die Fixes ändern

Mozilla, Go und Node setzen an unterschiedlichen Stellen an, und der Vergleich verrät viel über die Natur des Problems. Mozilla sperrt die Intermediates per OneCRL und entfernt mit NSS 3.131.1 die Root emSign ECC Root CA - G3, über die sie in den gängigen Trust-Stores verankert waren. Go geht mit Commit 7f86f957 einen anderen Weg. In crypto/x509 gleicht Certificate.Verify jede Kette jetzt mit einer fest einkompilierten Denylist ab, die die SHA-256-Hashes der acht öffentlichen Schlüssel enthält, und verwirft Ketten mit einem Treffer, auch wenn die Prüfung über die Plattform-Verifier auf macOS und Windows läuft. Node folgt mit PR #66871 demselben Prinzip und weist seit 22.23.4, 24.22.1 und 26.12.1 jede verifizierte Kette mit einem gesperrten Schlüssel als CERT_REVOKED zurück. Chrome sperrt per CRLSet ebenfalls über den Schlüssel-Hash.

Besonders aufschlussreich ist der Unterschied zwischen Zertifikat und Schlüssel. Kompromittiert waren acht Schlüssel, ausgestellt waren aber sechzehn Zertifikate, denn jedes Intermediate existierte zweimal. Einmal hängt es unter eMudhras eigener G3-Hierarchie, die über emSign ECC Root CA - G3 cross-signiert ist. Einmal ist es ein Cross-Sign von Sectigo unter der alten Root AAA Certificate Services, die laut Disclosure-Seite bei Apple und Microsoft noch vertraut wird. Entfernst du nur die emSign-Root, schließt du den ersten Pfad und lässt den zweiten offen. Eine Sperre auf den öffentlichen Schlüssel trifft beide Pfade auf einmal, weil sie das sperrt, was tatsächlich verloren ist. Vertrauen hängt in der Web-PKI am Schlüssel, und ein Schlüssel kann unter mehreren Zertifikaten und Roots auftauchen.

Gefälschte Zertifikate und wer sie akzeptiert hätte

Für einen Angriff braucht es zwei Dinge. Das erste ist einer der sechs TLS-Schlüssel, und den kann sich seit der Veröffentlichung jeder ausrechnen. Das zweite ist eine Position im Netz, aus der heraus sich der Angreifer zwischen Client und Server setzen kann, etwa über ein fremdes WLAN, manipuliertes DNS oder einen kompromittierten Zwischenhop. Erst dann kann er dem Client ein selbst ausgestelltes Zertifikat für die Zieldomain vorlegen, das zu einer vertrauenswürdigen Root führt. Mit den beiden Code-Signing-Schlüsseln lassen sich außerdem Windows-Programme signieren, weil Microsoft emSign Root CS CA - G3 direkt im Store führt.

Browser hatten eine zusätzliche Schutzschicht. Chrome, Firefox und Safari verlangen für Serverzertifikate Nachweise aus Certificate-Transparency-Logs, sogenannte SCTs, ein heimlich ausgestelltes Zertifikat müsste also öffentlich geloggt werden. Laut Google war vor der Sperre kein TLS-Zertifikat unter den sechs Intermediates geloggt. CT macht eine Fälschung allerdings nur sichtbar und verhindert sie nicht, und es greift nur dort, wo ein Client SCTs auch verlangt. Code-Signing-Zertifikate werden gar nicht in CT geloggt, was dort signiert wurde, lässt sich öffentlich nicht nachvollziehen.

Für deine Infrastruktur zählt ein anderer Punkt. curl, die TLS-Stacks von Go, Java, Python und Node und damit auch Kubernetes-Clients, Operatoren und CI-Werkzeuge prüfen standardmäßig weder SCTs noch den Sperrstatus. Sie vertrauen jeder Kette, die bei einer Root aus ihrem Trust-Store endet. Scott Helme hat das vor den Updates praktisch gezeigt, denn curl, Python und Node verbanden sich unter Linux und macOS ohne Warnung mit einem Server, der ein gefälschtes Zertifikat vorlegte. Für solche Clients war die Sperre in den Browsern bedeutungslos. Geschützt sind sie erst, wenn ihr Trust-Store aktualisiert ist oder ihre Laufzeit die Schlüssel selbst sperrt.

Wirklich betroffen ist damit jeder Dienst, der ausgehende TLS-Verbindungen zu öffentlichen Zielen aufbaut und noch einen alten Trust-Store nutzt, sofern jemand die Verbindung abfangen kann. Das betrifft API-Aufrufe und Webhooks aus Anwendungen, Paket- und Image-Downloads in CI-Pipelines und Controller, die externe Dienste ansprechen. Wer sich dort einklinkt, liest Tokens und Zugangsdaten mit oder liefert manipulierte Artefakte aus. Wenig Risiko besteht für Browser und für Verbindungen, die ausschließlich einer eigenen, privaten CA vertrauen. Falls du dich in Sicherheit wähnst, weil du nie ein eMudhra-Zertifikat gekauft hast, täuschst du dich, denn es kommt nicht darauf an, wessen Zertifikate du nutzt, sondern welchen Roots deine Clients vertrauen.

Einen klassischen Exploit braucht es hier nicht, denn jeder kann die Schlüssel ausrechnen. Bestätigten Missbrauch gegen echte Ziele gibt es bislang nicht. CERT-In fand am 21. Oktober in den Veröffentlichungen keinen Beleg für böswillige Nutzung, Google sah vor der Sperre keine weiteren Zertifikate in den CT-Logs, und eMudhra gibt an, nur EM DV TLS CA - G3C sei produktiv gewesen und keines der acht Intermediates habe Endzertifikate ausgestellt. Gegen Clients ohne CT-Prüfung lässt sich Missbrauch aber grundsätzlich nicht ausschließen, weil er keine öffentliche Spur hinterlassen muss. Im CISA-KEV-Katalog steht keine der genannten CVEs, EPSS schätzt CVE-2026-111943 am 21. Oktober auf 0,15 Prozent und CVE-2026-113470 auf 0,20 Prozent, was bei einem Fix ohne klassischen Exploit-Pfad wenig aussagt.

Trust-Store-Updates und wo sie ankommen

Einen Patch im üblichen Sinn gibt es nicht, weil der Fehler bei der CA liegt. Was du aktualisierst, ist die Liste dessen, dem deine Systeme vertrauen, und diese Liste liegt an mehr Stellen, als man zunächst denkt. Die folgenden Stände nennen die Disclosure-Seite, die Hersteller und Endor Labs übereinstimmend, soweit nicht anders markiert:

• Debian ca-certificates: 20250419~deb12u2 (Bookworm), 20250419+deb13u1 (Trixie)
• Alpine ca-certificates: 20261020-r0
• Wolfi/Chainguard ca-certificates: 20260909-r3, laut Paketdefinition in wolfi-dev/os mit NSS 3.131.1 abgeglichen
• Amazon Linux 2023: noch kein ALAS, Issue #1147 ist offen. Das am 20. Oktober geprüfte Image enthielt ca-certificates-2025.2.76-1.0.amzn2023.0.3 ohne Fix.
• Amazon Linux 2: keine Aussage von Amazon zu ca-certificates. Für die Go-Lücke CVE-2026-111943 führt das Amazon Linux Security Center unter AL2 und AL2023 unter anderem golang, docker, runc und cri-tools als „Pending Fix“.
• RHEL und UBI: Red Hat führt den Vorfall als RHSB-2026-012, nennt noch keine Fix-Versionen und beschreibt einen Workaround über die Blocklist.
• Go: 1.27.3 und 1.26.10, kein Backport für 1.25 und älter
• Node.js: 22.23.4, 24.22.1, 26.12.1 mit aktualisierten Roots und Schlüssel-Blockliste
• Python certifi: 2026.10.19
• Composer ca-bundle: 1.4.16 und 1.6.0
• Rust: rustls-webpki 0.103.16, webpki-roots 1.0.10
• Java: OpenJDK 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2 und 8u511 laut Disclosure-Seite. Endor Labs führt Java dagegen nicht als gefixt, prüf deshalb den Stand deiner JDK-Distribution direkt in cacerts.

Die größte Stolperfalle ist die Annahme, ein Update auf dem Host reiche aus. Der Trust-Store ist eine Datei im Image, und ein Container sieht die Version, die beim Build hineinkopiert wurde. Bei Go-Images auf Basis von scratch oder distroless wird ca-certificates.crt oft in einem Build-Schritt kopiert, ein aktualisierter Host ändert daran nichts. Laut Go-Advisory nutzt Go auf den meisten Plattformen die System-Roots. Im Container stammen diese aus dem Image, und ein aktualisierter Trust-Store wirkt deshalb erst, wenn er dort angekommen ist. Die Denylist für die acht Schlüssel steckt dagegen im Binary und greift erst nach einem Neukompilieren mit der neuen Toolchain, das gilt für eigene Dienste ebenso wie für kubectl, Operatoren und Controller.

Zwei weitere Punkte verdienen Aufmerksamkeit. Weil der Sectigo-Pfad über AAA Certificate Services denselben Schlüssel trägt, sperren der Workaround von Red Hat und die macOS-Anleitung der Disclosure-Seite auch diese Root. Das kann legitime Verbindungen zu Diensten brechen, deren Ketten noch über AAA laufen, und gehört deshalb vor dem Rollout getestet. Ob die gefixten Debian-Pakete AAA selbst entfernen, geht aus den Quellen nicht hervor, die Prüfung per Fingerprint im Image aus dem Abschnitt zur Erkennung klärt das für deinen Fall schneller. Und emSign Root CA - G1 bleibt vorerst vertraut, Chrome prüft die übrigen eMudhra-CAs noch. Bei Node kommt hinzu, dass wiederaufgenommene Sessions aus der Zeit vor dem Update nicht neu geprüft werden. Laut PR endet dieses Risiko erst, wenn der Session-Timeout abgelaufen ist.

Härtung über das Update hinaus

Bevor es um einzelne Maßnahmen geht, hilft eine Einordnung. Der Angriff findet nicht in deinem Container statt, sondern auf dem Weg zwischen deinem Client und seinem Ziel. Kein fremder Code läuft, kein ungewöhnlicher Syscall fällt an, der Client tut genau das, wofür er gebaut ist. Wirksam ist deshalb nur, was verändert, welchen Ausstellern ein Client vertraut, wie schnell sich diese Liste ändern lässt und ob ein Client eine Fälschung überhaupt bemerken kann.

Images regelmäßig neu bauen

Weil der Trust-Store im Image liegt, ist der regelmäßige Rebuild die wichtigste Maßnahme. Ein Image, das jede Woche oder bei jeder neuen Version des Base-Images neu gebaut wird, hat den aktualisierten Trust-Store wenige Tage nach dem Distributions-Update, ohne dass jemand an den Vorfall denken muss. Für Go-Dienste gehört die Toolchain in denselben Prozess, denn die Denylist aus crypto/x509 kommt nur über einen Rebuild ins Binary. Die Grenze ist offensichtlich: Ein Rebuild hilft nur, wenn die Distribution den Fix schon ausliefert. Auf Amazon Linux 2023 brauchst du bis dahin eine eigene Sperre.

Trust-Bundles im Cluster zentral verwalten

trust-manager aus dem cert-manager-Projekt verteilt ein CA-Bundle als ConfigMap oder Secret in die Namespaces. Das Default-Paket stammt aus Debian, und laut Doku vertrauen ältere Tags der kompromittierten CA weiter, nötig sind mindestens trust-pkg-debian-trixie:20250419-deb13u1.0 oder trust-pkg-debian-bookworm:20250419-deb12u2.0. Pinne den Tag und lass Renovate ihn aktualisieren, dann ist der Stand des Bundles eine Versionsangabe in Git und keine Vermutung. Eine Option, einzelne Zertifikate aus dem Default-Paket auszuschließen, beschreibt die Doku nicht, für eine engere Auswahl pflegst du deshalb ein eigenes Bundle.

Ein zentrales Bundle wirkt allerdings nur, wenn die Laufzeit es auch liest. Go und OpenSSL lassen sich unter Linux über SSL_CERT_FILE auf eine Datei lenken. Python mit requests nutzt certifi, solange du nichts anderes einstellst. Node bringt einen eigenen Store mit, und NODE_EXTRA_CA_CERTS ergänzt ihn nur, statt ihn zu ersetzen. Soll Node den System-Store nutzen, startest du es mit --use-system-ca. Genau diese parallelen Stores meint Endor Labs mit den Trust-Stores, von denen man nichts wusste.

Eigene CA für interne Verbindungen

Verbindungen zwischen deinen eigenen Diensten, etwa zur Datenbank, zu Valkey oder zu internen APIs, brauchen das öffentliche Web-PKI-Bundle nicht. Vertraut ein Client dort ausschließlich einer privaten CA, die cert-manager als CA-Issuer betreibt, kann eine kompromittierte öffentliche CA diese Verbindungen nicht fälschen. Name Constraints auf der privaten CA begrenzen zusätzlich, für welche Namen sie ausstellen darf. Das ist ein allgemeiner Grundsatz und keine Empfehlung aus den Quellen zum Vorfall, er nimmt einen großen Teil der Angriffsfläche aber vollständig heraus. Für externe APIs und Paketquellen bleibt das öffentliche Bundle nötig.

Sperren auf den Schlüssel statt auf das Zertifikat

Wo die Plattform es zulässt, ist eine Sperre auf den öffentlichen Schlüssel präziser als das Entfernen einer Root, wie der Sectigo-Pfad gezeigt hat. Go und Node bringen diese Sperre jetzt selbst mit. Für RHEL ab Version 7 und UBI beschreibt Red Hat in RHSB-2026-012 einen Workaround über die Blocklist von update-ca-trust, der emSign ECC Root CA - G3 und die Comodo-Root AAA sperrt. Für Amazon Linux 2023, das ebenfalls update-ca-trust nutzt, beschreibt der Melder in Issue #1147 denselben Weg und hat ihn gegen den Testhost erfolgreich geprüft, allerdings nur für die emSign-Root, sodass der Pfad über AAA offen bleibt. Eine offizielle Aussage von Amazon gibt es dazu nicht. Die Sperre auf dem Host erreicht deine Container nicht, sie gehört deshalb in den Image-Build.

Certificate-Transparency-Monitoring für eigene Domains

Ein CT-Monitor meldet dir jedes geloggte Zertifikat für deine Domains, egal welche CA es ausgestellt hat. Hätte jemand unter einem der kompromittierten Schlüssel ein Zertifikat für eine deiner Domains ausgestellt und geloggt, wäre es dir auf diesem Weg schnell aufgefallen. Die Grenze kennst du aus dem Abschnitt oben: Gegen Clients ohne CT-Prüfung muss eine Fälschung nie geloggt werden. CT-Monitoring ist also ein Frühwarnsystem für Fehlausstellungen und kein Schutz.

Was hier nicht hilft

CAA-Records schützen nicht, auch wenn sie oft so verstanden werden. RFC 8659 legt fest, dass nur die ausstellende CA sie prüft, und schreibt ausdrücklich: „Relying Parties MUST NOT use CAA records as part of certificate validation.“ Wer einen CA-Schlüssel besitzt, lässt die Prüfung einfach aus. Auch Revocation hilft wenig. eMudhra und Sectigo haben die sechzehn Zertifikate widerrufen, aber die meisten Nicht-Browser-Clients prüfen den Sperrstatus standardmäßig nicht, und laut Helme meldete unter Windows nur einer von zwei Prüfwegen die Kette als widerrufen. Mozilla hält im Bugzilla-Eintrag selbst fest, dass viele Endpunkte keinen wirksamen Weg haben, an Sperrinformationen zu kommen.

Pinning hilft nur bedingt. Pinnst du für eine einzelne Verbindung den Schlüssel des Servers, bist du gegen fremde CAs geschützt, bezahlst das aber mit hohem Aufwand bei jeder Schlüsselrotation. Ein Pin auf eine CA hilft nicht, wenn genau diese CA betroffen ist. seccomp, entzogene Capabilities, readOnlyRootFilesystem und der Pod Security Standard „restricted“ bleiben richtig, wirken gegen eine abgefangene Verbindung aber nicht. Ein HSM bei der CA hat den Vorfall ebenfalls nicht verhindert. Und ein CVE-Gate in der Pipeline schlägt nur dort an, wo ein Paket eine CVE trägt, etwa die Go-Standardbibliothek. Ein veraltetes ca-certificates im Image meldet es nicht zuverlässig, weil der CA-Vorfall selbst keine CVE hat.

Mehr zu Egress, Zertifikatsverwaltung mit cert-manager und Image-Pipelines findest du in der Serie TYPO3 auf Kubernetes unter IT-Grundschutz.

Erkennung und Prüfung

Ob ein Client noch vertraut, prüfst du am besten mit genau diesem Client. Die Disclosure-Seite betreibt Testhosts, deren Zertifikate mit einem der kompromittierten Schlüssel signiert sind: dv-g3b-emudhra.we-have-a-problem.com führt über die emSign-Root, dv-g3b-aaa-emudhra.we-have-a-problem.com über AAA Certificate Services. Rufe beide aus dem Image oder Pod heraus auf. Ein Zertifikatsfehler bedeutet, dass der Client geschützt ist, eine erfolgreiche Verbindung, dass er weiter vertraut. Ein Test mit curl prüft allerdings nur curl, Go-, Java- und Node-Dienste im selben Image können sich anders verhalten.

Für Bundles im Image genügt die Suche nach „emSign“ nicht, weil emSign Root CA - G1 vorerst vertraut bleibt. Suche gezielt nach emSign ECC Root CA - G3 mit dem SHA-256-Fingerprint 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B und nach AAA Certificate Services mit D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4. Für Java listet keytool -list die Einträge in cacerts, für Go-Binaries zeigt go version -m, mit welcher Toolchain sie gebaut wurden. Bei PHP-Projekten lohnt ein Blick auf die Version von composer/ca-bundle, das Composer und viele HTTP-Clients mitbringen.

Ob du angegriffen wurdest, ist schwerer zu beantworten, weil ein Man-in-the-Middle nur beim Client Spuren hinterlässt. Prüfe in crt.sh, ob für deine Domains Zertifikate unter einem der acht Intermediates geloggt sind, und nutze die SPKI-Hashes aus Go-Commit und Disclosure-Seite als Suchkriterium in TLS-Logs, falls dein Egress-Proxy die Aussteller der Gegenstellen protokolliert. Veröffentlichte IoCs gibt es nicht. Bei Code-Signing raten SOCRadar und andere Analysen, Signaturen mit diesen Intermediates seit dem 30. April 2025 zu suchen und betroffene Artefakte mit neuem Zertifikat und RFC-3161-Zeitstempel neu zu signieren. Hast du einen konkreten Verdacht auf eine abgefangene Verbindung, rotierst du alle Zugangsdaten, die darüber liefen.

Betreiberempfehlung

Akut handeln solltest du, wenn Dienste aus Containern mit Trust-Stores von vor dem 20. Oktober 2026 TLS-Verbindungen zu öffentlichen Zielen aufbauen, besonders aus Netzen, die du nicht selbst kontrollierst, oder wenn CI-Runner darüber Pakete und Images laden. Bau die Images mit aktualisiertem ca-certificates neu, kompiliere Go-Dienste mit 1.27.3 oder 1.26.10, hebe Node an und setze auf Amazon-Linux-2023-Hosts eine eigene Sperre, bis Amazon ein Update liefert.

Beobachten genügt, wenn deine Clients ausschließlich Browser sind oder deine Dienste nur intern über eine private CA sprechen. Das nächste reguläre Image-Update bringt den neuen Trust-Store dann ohnehin mit, und Chrome entfernt die Root voraussichtlich am 27. Oktober aus seinem Root Store.

Unabhängig vom Einzelfall gilt, was ich bei jeder Lücke sage: Patches und Updates gehören automatisiert, und der Trust-Store ist hier ebenso eine Abhängigkeit wie jedes Paket. Wenn Renovate oder Dependabot neue Base-Images, die Go-Toolchain und die Tags des trust-manager-Pakets selbstständig als Merge Request vorschlagen und die Pipeline gegen Staging testet, steckt ein Vorfall wie dieser nach Stunden in allen Images statt nach Wochen. Eine Karenzzeit für Routine-Updates schützt dabei vor kompromittierten Releases, Sicherheitsupdates nimmst du davon aus. Gerade die Sperre von AAA Certificate Services kann legitime Verbindungen brechen, und das fällt im Test auf statt in Produktion. Aktualisierst du von Hand, trägst du einen Trust-Store vom Sommer schnell bis in den Winter mit dir und baust dann ein Sammel-Update, bei dem alles auf einmal kippt.

Fazit

Der eMudhra-Fall zeigt, dass ein Schlüssel jede formale Prüfung bestehen und trotzdem wertlos sein kann, und dass ein frühes Warnsignal wie eine falsch signierte Sperrliste eine Ursachenanalyse verdient und keine schnelle Neusignatur. Für Betreiber liegt die übertragbare Lehre an anderer Stelle. Browser haben ihre Nutzer in Stunden geschützt, weil sie CT durchsetzen und Sperrlisten zentral verteilen. Deine Dienste haben dafür nur den Trust-Store, den du ihnen beim letzten Build mitgegeben hast. Behandle ihn wie jede andere Abhängigkeit, mit Version, automatischem Update und Rebuild, und gib internen Verbindungen eine eigene CA. Dann ist der nächste Vorfall dieser Art ein Merge Request und kein Wochenprojekt.

Quellen

• Mozilla Bugzilla 2083449: eMudhra Intermediate CA Key Compromise
• Mozilla Bugzilla 1970728: ungültige CRL-Signaturen 2025
• Mozilla Bugzilla 2084101: Entfernung emSign ECC Root CA - G3
• Mozilla dev-security-policy: Diskussion zum Vorfall
• Mozilla dev-tech-crypto: NSS 3.131.1
• Google: Protecting Chrome and Android users
• Go Vulnerability Database: GO-2026-6809 (CVE-2026-111943)
• Go Fix-Commit 7f86f957 (crypto/x509 Denylist)
• Node.js PR #66871: reject chains containing blocked public keys
• Disclosure-Seite mit Testhosts und Fingerprints
• Scott Helme: Eight bits of trust
• eMudhra: Certificate Security Incident
• Red Hat RHSB-2026-012
• Amazon Linux 2023 Issue #1147
• Endor Labs: The trust stores you didn't know you had
• cert-manager Docs: trust-manager
• RFC 8659: DNS Certification Authority Authorization (CAA)
• Cloudflare: eMudhra certificate compromise
• SOCRadar: eMudhra CA Key Compromise
• The Register: eMudhra private keys compromised