eMudhra Zwischenprodukt CA Kompromiss: Auswirkungen und Sanierungsleitfaden

Quellen überprüft am 22. Oktober 2026, Pekinger Zeit. Zielgruppe: einzelne Benutzer, Website-Betreiber, Entwickler und Systemadministratoren.

Schwerwiegende Schwachstellen führten dazu, dass eine Gruppe privater Zwischenschlüssel eMudhra/emSign CA wiederherstellbar war. Dies betrifft Clients, die das öffentliche Zertifikatsystem zur Authentifizierung von Websites, APIs und Software verwenden. Das öffentliche Vertrauen erstreckt sich auf die wichtigsten Betriebssysteme, aber die Menge der kompromittierten Schlüssel und die potenziellen Auswirkungen auf den Client sind unterschiedlich. 15

Der Haupttext verwendet eckige Klammern, um die entsprechenden Quellen zu nummerieren, und alle externen Referenzlinks sind im Anhang aufgeführt. Bei der aufgeführten Version handelt es sich um die Basisversion, von der bestätigt wurde, dass sie zum Überprüfungsdatum den Fix für diesen Vorfall enthält. Bei der Bereitstellung wird der aktualisierten stabilen Version im selben unterstützten Zweig Vorrang eingeräumt.

TL;DR

Es wurde bestätigt, dass die privaten Zwischenschlüssel Eight CA kompromittiert wurden. Aktuelle Berichte belegen nicht, dass private Root-Schlüssel oder die HTTPS-Kryptografie im Allgemeinen beschädigt wurden. Updates erstrecken sich über einen Großteil des öffentlichen Vertrauensökosystems. Das Restrisiko hängt von der tatsächlichen Anwendung ab.15

1. Einzelne Benutzer: aktualisieren Browser, Betriebssysteme und Sicherheitskomponenten. Aktualisieren Sie auf Android auch die Google Play-Dienste. Verwenden Sie Firefox Android 158.0.2 oder höher. 12
2. Server: aktualisieren die ca-certificates/NSS-Pakete der Distribution und überprüfen die anwendungsgebündelten Trust Stores. Es reicht nicht aus, nur den Host zu aktualisieren. 7810
3. Entwicklungsumgebungen: Aktualisieren Sie Node 24 auf 24.22.1 oder eine neuere Version in diesem Zweig, sofern zutreffend. Aktualisieren Sie in Python-Umgebungen mindestens auf pip 26.2.2, certifi 2026.10.19 und uv 0.13.4. Erhalten Sie feste Go-Binärdateien oder erstellen Sie sie neu. Aktualisieren Sie Java gemäß der Empfehlung des Anbieters. 12–15
4. Aktivieren Sie die Updates: Starten Sie die betroffenen Dienste neu und erstellen Sie Container neu und stellen Sie sie erneut bereit. Aktualisieren Sie für Cloudflare Tunnel cloudflared auf 2026.10.2 oder höher. 7
5. Website-Zertifikate: ersetzen eine betroffene Kette, wenn sie ein widerrufenes oder blockiertes Zwischenprodukt CA enthält oder auf einem vertrauenswürdigen Stamm basiert. Das erneute Ausstellen eines Zertifikats ersetzt nicht die Aktualisierung von Client-Truststores. 158
6. Verification: Testen Sie den tatsächlichen TLS-Pfad jeder Anwendung. Unterscheiden Sie die Ablehnung von Zertifikaten von Zeitüberschreitungen und DNS-Fehlern. Lassen Sie die Zertifikatsüberprüfung aktiviert. Verwenden Sie weder -k noch überspringen Sie die Überprüfung, um Fehler zu unterdrücken. 7

1 Fakten und Ursachen des Vorfalls

bestätigte Tatsachen

Mozilla und Google haben Mängel in acht privaten eMudhra-Zwischenschlüsseln CA bestätigt. Der Forscher lieferte einen Nachweis über die Kontrolle des privaten Schlüssels; Mozilla hat die Schlüssel unabhängig wiederhergestellt und das Problem reproduziert. Sechs Zwischenzertifizierungsstellen dienen TLS und zwei dienen der Codesignatur. 25

Der Fehler liegt in den generierten Schlüsseln: Diese Zwischenzertifizierungsstellen verwenden die P-384-Kurve, aber ihre privaten Schlüssel sind ganze Zahlen unter 256. Dies ist weit davon entfernt, Schlüssel zufällig aus dem vorgesehenen großen Bereich sicher auszuwählen. Die Wiederherstellung dieser schwachen Schlüssel zeigt nicht, dass ordnungsgemäß generierte P-384-Schlüssel beschädigt werden können. 2

Das „Zertifikat ist geknackt“ sollte hier genau als „der entsprechende private Schlüssel kann wiederhergestellt werden“ verstanden werden. Das Zertifikat und der darin enthaltene öffentliche Schlüssel sind grundsätzlich öffentlich; Was wirklich geheim gehalten werden muss, ist der private Schlüssel, der eine gültige Signatur erzeugen kann.

Probleme mit dem Schlüsselgenerierungsprozess werden noch untersucht

Eine erste Beschreibung von eMudhra führt das Problem auf eine Schlüsselgenerierungszeremonie im April 2025 zurück. Die Erklärung umfasst einen Schlüsselkapselungs- und -entkapselungsschritt: Zusätzlich zum ursprünglichen starken Schlüssel erscheint ein weiterer Satz schwacher Schlüssel, und die schwachen Schlüssel werden anschließend für die Beantragung und Ausstellung von Zertifikaten verwendet. Das Unternehmen sagte immer noch, die genaue Ursache sei noch nicht abschließend geklärt. 6

Daher kann festgestellt werden, dass diese Schlüssel ernsthaft schwach sind und kompromittiert wurden. Der Fehler kann nicht weiter beschrieben werden, da sich herausstellte, dass eine bestimmte Hardware-Zufallszahlenquelle von HSM defekt ist, und er kann auch nicht als allgemeiner kryptografischer Durchbruch von RSA, ECC oder TLS beschrieben werden.

Was bedeutet Misstrauen gegenüber Stammzertifikaten?

Der Browser oder das Betriebssystem kann das Zertifikat oder den öffentlichen Schlüssel des betroffenen Zwischenprodukts CA direkt blockieren oder die zu ihnen führende Root-Vertrauensstellung entfernen. Durch die letztgenannte Maßnahme werden auch einige legitime Zertifikate unter demselben Stamm abgelehnt.

Google hat die Entfernung von emSign ECC Root CA - G3 geplant, um Benutzer des Chrome-Root-Stores zu schützen, die keine Updates von CRLSet erhalten. Die Entfernung des Root-Stores wird voraussichtlich im entsprechenden Zeitraum vom 27. bis 28. Oktober (Pekinger Zeit) vorangetrieben. Die ursprüngliche Zeit von Google ist der Morgen des 27. Oktober, US Pacific Daylight Time. Dieser Plan ist unabhängig von der zuvor eingesetzten Notblockierung öffentlicher Schlüssel. 1

Das Misstrauen gegenüber einem Root ist eine Reaktionsmaßnahme; es selbst beweist nicht, dass der private Root-Schlüssel kompromittiert wurde.

2 Warum sich die potenziellen Auswirkungen auf das Ökosystem des öffentlichen Vertrauens erstrecken

Kompromittierte Schlüssel und betroffene Vertrauenspfade

Urteilsobjekt	Das Ausmaß dieses Vorfalls
Problematischer Schlüssel identifiziert	8 private Zwischenschlüssel CA für eMudhra
Plattformen, die möglicherweise Maßnahmen erfordern	Öffentlicher Root-Store, Browser, Betriebssystem, Sprachlaufzeit, Softwarepaket und Container-Ökosystem
Möglicherweise imitierte Identität TLS	Von Kunden besuchte Websites oder Dienste, die die zugehörige gefälschte Zertifikatskette noch akzeptieren
Bedeutet das, dass alle Geräte kompromittiert wurden?	Nein; Vertrauensbedingungen, Netzwerkstandort des Angreifers und andere Überprüfungsstrategien bestimmen die Ausnutzbarkeit
Bedeutet das, dass alle gesetzlichen Zertifikate ungültig sind?	Nein; Die damit verbundene Ungültigmachung hängt davon ab, welche Roots oder Zertifikatsketten der Client als nicht vertrauenswürdig eingestuft hat.

Red Hat beschränkt die Ausnutzung ausdrücklich auf Bedingungen, unter denen der Client die entsprechende Kette weiterhin akzeptiert, der Angreifer über den kompromittierten privaten Schlüssel verfügt und in der Lage ist, die Verbindung im Netzwerk abzufangen. Die Risikoabdeckung ist nicht mit der Anzahl der erfolgten Angriffe zu verwechseln. 10

Websites, die andere CA verwenden, können ebenfalls imitiert werden

Angenommen, eine Website verwendet tatsächlich das Zertifikat Let’s Encrypt und der Client des Besuchers vertraut mehreren öffentlichen CA gleichzeitig. Ein Angreifer könnte versuchen, das kompromittierte Zwischenzertifikat CA zu verwenden, um ein weiteres Zertifikat für denselben Domänennamen zu erstellen. Kunden verlangen in der Regel nicht im Voraus, dass der Domänenname nur Let’s Encrypt verwenden darf; Wenn die Fake-Kette dennoch akzeptiert wird, welche CA die Website tatsächlich nutzt, reicht das nicht aus, um solche Angriffe auszuschließen. 8

Dieser Mechanismus erklärt: Durch das Ersetzen eines anderen CA-Zertifikats, das ursprünglich normal war, wird das Vertrauen des Clients in das gefährdete CA nicht automatisch wiederhergestellt. Was wirklich abgeschnitten werden muss, ist der Weg für Kunden, gefälschte Identitäten zu akzeptieren.

Die drei Effekte müssen separat behandelt werden

Identitätsbetrugsrisiko: Clients, die die entsprechende Kette nicht blockiert haben, akzeptieren möglicherweise die vom Angreifer gefälschte Identität, was dazu führt, dass vertrauliche Anfragen an gefälschte Dienste gesendet werden.

Legitimes Risiko der Dienstverfügbarkeit: Das Entfernen der Root-Vertrauensstellung kann zu Zertifikatsfehlern für ansonsten legitime Websites führen, die möglicherweise auf eine andere akzeptierte Kette migriert werden müssen.

Bereitstellungsabdeckungsrisiko: Das Betriebssystem wird möglicherweise repariert, während ein anwendungsgebündelter Trust Store, eine virtuelle Umgebung, ein altes Container-Image oder ein kompiliertes Programm das alte Validierungsverhalten beibehält.

Diese drei Bereiche sind nicht identisch. Die Antwort von Cloudflare befasst sich mit der Remote-Identitätsvalidierung, gemeinsamen Vertrauensspeichern, Basis-Images und einzelnen Anwendungen und veranschaulicht, warum die beiden letztgenannten Aufgaben separat behandelt werden müssen. 7

3 Betroffene CA und Zertifikatsanbieter

Anbieter und Auswirkungstyp

Anbieter oder System	Rolle bei diesem Vorfall	Grenzen, die unterschieden werden müssen
eMudhra／emSign	Der private Zwischenschlüssel CA ist direkt kompromittiert.	Sie können nicht alle eMudhra-Roots und alle Zertifikate als geknackt schreiben
Sectigo-bezogene Cross-Signatur-Kette	Für denselben Stapel betroffener öffentlicher Schlüssel wurde das Gegenzertifikat A ausgestellt, das einen weiteren Vertrauenspfad bildet.	Das entsprechende Gegenzertifikat oder der öffentliche Schlüssel muss gesperrt werden; Es wurde nicht nachgewiesen, dass der private Root-Schlüssel Sectigo kompromittiert wurde.
Relevante Zertifikatsstufen für Internet2/InCommon	Einige legitime Zertifikate erfordern die Entfernung des Stammverzeichnisses emSign ECC, was eine Migration mit sich bringt	Es ist eine Nebenwirkung des Root-Misstrauens und kann nicht zu den acht schwachen Schlüsseln CA gezählt werden
Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign usw.	In diesem Bericht nicht als die Partei aufgeführt, deren privater Schlüssel kompromittiert wurde	Berechtigte Zertifikate werden nicht einheitlich für ungültig erklärt; Anfällige Clients akzeptieren möglicherweise weiterhin gefälschte Zertifikate, die sich als die von ihnen bedienten Websites ausgeben
CDN, Cloud-Plattform, Zertifikatshändler	Stellen Sie möglicherweise relevante Zertifikate bereit oder verwenden Sie einen öffentlichen Truststore, wenn Sie eine Verbindung zum Ursprung und API herstellen	Um die tatsächliche Zertifikatskette und den Validator zu überprüfen, schauen Sie sich nicht nur die Plattform oder den Produktnamen an

Die Mitteilung von Mozilla dokumentiert die kompromittierten Schlüssel und Sectigo-Kreuzsignaturen. Die öffentliche Vorfalldiskussion von Google befasst sich mit der Migration legitimer Internet2/InCommon-Hierarchien. 25 Cloudflares Fixes beheben Service und Client-Vertrauen; Sie weisen nicht auf eine Kompromittierung der privaten Schlüssel von Cloudflare CA hin. 7

TLS-Zertifikatkette und Kreuzsignatur

Die folgende Beziehung beschreibt dieses Mal nur die TLS-bezogenen Pfade. Codesignaturpfade sind darin nicht enthalten und es bedeutet auch nicht, dass diese Pfade weiterhin auf allen Plattformen vertrauenswürdig sind. 17

emSign Root TLS CA - G3 ist ein direkter Aussteller der betroffenen TLS-Zwischenprodukte und kann in einigen Geschäften selbst als Vertrauensanker fungieren. emSign ECC Root CA - G3 bietet eine weitere Cross-Signing-Ebene. AAA Certificate Services von Sectigo erstellt einen zusätzlichen Pfad zu denselben öffentlichen Zwischenschlüsseln CA. 17

Daher gibt es bei der Reparatur zwei unterschiedliche Granularitäten:

• Blockieren Sie den genauen Zwischenschlüssel CA oder den öffentlichen Schlüssel:. Dadurch können andere legitime Hierarchien unter demselben Stamm erhalten bleiben, wenn der Validator diesen Mechanismus unterstützt.
• Root-Vertrauensstellung entfernen: Dies kann Clients ohne zwischengeschaltete CA-Blockierungsfunktionen schützen, kann jedoch die Kompatibilität beeinträchtigen. Alle anderen Wege, die der Kunde akzeptiert, müssen ebenfalls abgedeckt werden. 5

„Alle Sectigo/eMudhra-Roots löschen“ sollte nicht als wahlloser allgemeiner Schritt verstanden werden, noch sollte das bloße Löschen eines Zertifikats mit einem ähnlichen Namen bedeuten, dass alle Pfade geschlossen werden.

4 Betriebssystem- und Browserabdeckung

Hauptplattform

Plattform	Bekannte Disposition	Umfang, der bei der Verwendung überprüft werden sollte
Windows und Windows Server	Microsoft-Verteilung durch automatische Aktualisierung der Zertifikatsvertrauensliste blockiert	Ob das Gerät das Update erhalten hat; Standalone CA bundle verwendet nicht unbedingt den Verifizierungspfad von Windows
macOS, iOS, iPadOS usw. Apple-Plattform	Der Vorfallkoordinator bestätigte, dass Apple die entsprechende Blockade eingesetzt hat	Es kann nicht garantiert werden, dass jede ältere Version und jede Drittanbieter-App die gleiche Abdeckung erhält
Android	Google verteilt äquivalente Blöcke über den Google Play-Dienst	ROM ohne Google Play-Dienst sollte laut Herstellerankündigung verifiziert werden; Verwenden Sie den integrierten Verifizierer für eine zusätzliche Überprüfung
Ubuntu	Es wurden Korrekturen für Systemzertifikatpakete bereitgestellt, darunter mehrere aktuelle und alte Versionszweige	Die alte Version von ESM unterstützt Bedingungen, Container-interne Zertifikatspakete und integrierte Anwendungsbibliotheken
Debian und Devuan	Debian aufgezeichnet ca-certificates behoben	Sie müssen den tatsächlich verwendeten Zweig und das installierte Paket überprüfen und können die Versionsnummer eines anderen Zweigs nicht kopieren.
RHEL und Derivate	Die offizielle Liste lautet RHEL 6, 7, 8, 9, 10 und deckt verwandte Produkte und Bilder ab, die möglicherweise betroffen sind	Zum Zeitpunkt dieser Überprüfung enthielt die Ankündigung noch keine vollständige Liste der Fehlerbehebungen und Errat; „Update nicht gefunden“ kann nicht als unberührt betrachtet werden
Fedora, Arch, Gentoo, Alpine usw.	Der Veranstalter hat entsprechende Reparaturprotokolle erstellt	Unabhängig bestätigt durch Release, Versionszweig und Image
FreeBSD	Listet offiziell alle unterstützten Versionen auf und bietet Reparaturen im System Trust Store	Starten Sie nach dem Update den entsprechenden Daemon-Prozess gemäß der Ankündigung neu; Überprüfen Sie den Vertrauensspeicher der unabhängigen Anwendung separat.

Eine Zusammenfassung von Windows, Apple und Releases finden Sie unter 4; für Android siehe 1; für Ubuntu, Debian, RHEL und FreeBSD. Die Ausstellerdatensätze werden jeweils in 8–11 angezeigt.

Systeme, die nicht mehr unterstützt werden, Offline-Geräte, NAS, Router und andere eingebettete Umgebungen müssen bestätigen, ob sie der relevanten Kette noch vertrauen und ob sie Kanäle für den Empfang von Sperrungen oder Software-Updates haben. Der Plattformname selbst ist kein Ersatz für die Überprüfung des tatsächlichen Verifizierungsverhaltens.

Der Browserschutz unterscheidet sich vom Betriebssystemschutz

Chrome verwendet CRLSet, um Notfallblöcke zu verteilen; Firefox verwendet Mechanismen wie OneCRL. Firefox wurde außerdem mit Blockierungsinformationen veröffentlicht, um zusätzlichen Schutz für Konfigurationen zu bieten, die Remote-Einstellungen nicht ordnungsgemäß empfangen. 13

Einige Konfigurationen von Firefox Android hatten die aktualisierte Liste beim Start nicht korrekt angewendet, was laut Mozilla durch 158.0.2. behoben wurde. Daher kann der Status der frühen 158.0.1 nicht erweitert werden, um alle geschützten Android Firefox-Konfigurationen einzuschließen. 2

Es wurden Maßnahmen zur Systemüberprüfung von Apple und Windows ergriffen. Dies bedeutet jedoch nicht, dass alle Befehlszeilenprogramme auf demselben Computer einer Systemüberprüfung unterzogen werden. Der Event-Betreuer erinnerte ausdrücklich daran, dass einige integrierte macOS-Tools unabhängige Zertifikatsdateien verwenden; Bei der Überprüfung sollten das tatsächliche TLS-Backend und die CA-Quelle aufgezeichnet werden. 4

Schutzgrenzen für die Zertifikatstransparenz

Google bestätigte, dass die sechs TLS-Zwischenprodukte CA vor der Implementierung des Blocks nicht das TLS-Zertifikat ausgestellt haben, das in das CT-Protokoll eingetragen wurde. Daher verfügen Chrome-Clients, die CT erzwingen, über zusätzlichen Schutz. Diese Tatsache schließt die Möglichkeit nicht aus, dass andere Clients, die CT nicht ausführen, undokumentierte Zertifikate akzeptiert haben. 15

„Es stellt sich heraus, dass es mit der vertrauenswürdigen Wurzel verknüpft werden kann“, „Potenzielle Ausnutzungsbedingungen liegen vor“ und „Es hat ein Angriff stattgefunden“ sind drei verschiedene Urteile und sollten nicht durch einander ersetzt werden.

5 Entwicklungsumgebung und Laufzeitreparatur-Baseline

Das Folgende ist eine Basisliste bestätigter Korrekturen und stellt keine Voraussetzung für die langfristige Fixierung dieser Versionen dar. Distributionen reparieren möglicherweise ältere Versionsnummern, indem sie Patches zurückschieben, und ihre Sicherheitshinweise sollten ebenfalls überprüft werden.

Komponenten	Bestätigte Version oder Aktualisierungsmethode	Überlegungen zur Bereitstellung
Node.js 24	24.22.1 oder aktualisieren Sie die stabile Version desselben Zweigs	Enthält Root-Repository-Updates und die Ablehnung blockierter öffentlicher Schlüsselbunde; Überprüfen Sie den tatsächlich vom Dienst verwendeten Node-Pfad und starten Sie neu
Python certifi	2026.10.19 oder neuere Version	Überprüfen Sie jede tatsächlich ausgeführte Umgebung. Sie können nicht nur ein Paket unter dem globalen Python aktualisieren
pip	26.2.2 oder neuere Version	Aktualisieren Sie pip separat in der alten virtuellen Umgebung und überprüfen Sie die Version, nachdem die neue Umgebung erstellt wurde
uv	0.13.4 oder neuere Version	Aktualisieren Sie eine Kopie des Tools so, wie es tatsächlich installiert wurde
Go	1.27.3 oder 1.26.10, die aktualisierte Version des entsprechenden Zweigs ist ebenfalls verfügbar	Erstellen Sie die relevanten Programme neu und stellen Sie sie bereit, nachdem Sie die Toolkette aktualisiert haben, oder besorgen Sie sich die Reparaturbinärdatei des Anbieters
Oracle JDK	Critical-Patches für die entsprechenden unterstützten Versionslinien	Verschiedene JDK-Herausgeber folgen ihren eigenen Ankündigungen; Es gibt keine einheitliche Versionsnummer, die für alle Java-Versionen gilt
Cloudflare Tunnel	cloudflared 2026.10.2 oder neuere Version	Laufende Dienste aktualisieren; Für die Containerbereitstellung ist das Ersetzen des Images und eine erneute Bereitstellung erforderlich
Cloudflare One／WARP	Die der Plattform entsprechende feste Clientversion oder die aktualisierte stabile Version	Clientseitige und serverseitige Maßnahmen werden separat bestätigt. Informationen zu bestimmten Plattformversionen finden Sie im Anhang 7

Die Originalanweisungen für Node, Python, Go, Oracle und Cloudflare sind jeweils in 13, 12, 14, 15, 7 verfügbar.

Problem mit der unabhängigen Zertifikatsdatenbank Python

Beamte von Python wiesen darauf hin, dass der alte pip eine Kombination aus Systemvertrauen und integriertem certifi verwenden wird. Durch einfaches Ändern des Systemzertifikatspeichers oder Hinzufügen einer CA-Datei zu pip kann die integrierte alte Vertrauensstellung nicht zuverlässig ausgeschlossen werden. Daher können PIP_CERT, REQUESTS_CA_BUNDLE oder --cert nicht als universeller Reparaturersatz für das ältere pip verwendet werden. 12

Überprüfen Sie nach dem Update vorhandene virtuelle Umgebungen. Überprüfen Sie außerdem die tatsächlich installierte pip-Version in neu erstellten Umgebungen, damit ältere Bootstrap-Komponenten nicht erneut anfällige Tools einführen. Befolgen Sie für das erste Upgrade die Download-Quellen und die Schritte zur Überprüfung von SHA-256 im Ratgeber von Python, bevor Sie andere Pakete aktualisieren. 12

Go und andere kompilierte Programme

Der Fix für Go hat die Validierungslogik für crypto/x509 geändert. 14 Aus Sicht des Bereitstellungsmechanismus führt die Aktualisierung des Compilers auf dem Entwicklungscomputer nicht dazu, dass die bereits bereitgestellte Binärdatei neu geschrieben wird. Um die neue Codeschichtblockierung zu erhalten, sollte die Anwendung neu erstellt und ersetzt werden oder eine vom Anbieter bereitgestellte aktualisierte Version verwendet werden. Ob ein älteres Programm auch von System-Root-Updates profitieren kann, hängt vom tatsächlichen Verifizierungspfad ab, den es verwendet.

Container und verpackte Anwendungen

Das Systemzertifikatpaket, die Anwendungsabhängigkeiten und die Laufzeit im Container werden normalerweise durch den Bildinhalt bestimmt. Host-Update ist nicht gleichbedeutend mit Bildinhalts-Update; Das Basis-Image und die Abhängigkeiten müssen aktualisiert werden und die tatsächlich ausgeführte Instanz muss neu erstellt, bereitgestellt und überprüft werden. Gepackte Anwendungen und Desktop-Programme, die über eine eigene Laufzeit verfügen, sollten ebenfalls entsprechend den Veröffentlichungskanälen der Anbieter aktualisiert werden. 710

6 Anleitung zur Reparaturdurchführung

Bestimmen Sie zunächst das Prüfobjekt

Es wird empfohlen, die folgenden Informationen für die zu schützenden Dienste zu erfassen und anschließend den entsprechenden Reparaturpfad auszuwählen. Dies ist eine Checkliste für die Bereitstellung und erfordert nicht, dass alle Komponenten auf jedem System vorhanden sind.

Projekt	Was muss aufgezeichnet werden
Anwendungen und Verwendungen	Browser, Zahlungs-API-Client, E-Mail-Versanddienst, Download-Tool, Reverse-Proxy usw.
Betriebsposition	Host, Container, virtuelle Maschine, Desktop-Anwendung oder mobiles Gerät
Überprüfen Sie die Implementierung	Betriebssystemvalidator, OpenSSL-, Node-, Python-Bibliothek, Java oder benutzerdefinierte Anwendungsimplementierung
vertrauenswürdige Quelle	System CA-Paket, certifi, JDK Trust Store, integrierte CA bundle oder Unternehmenskonfiguration
Reparaturstatus	Installierte Version, Patch-Quelle, ob neu gestartet oder erneut bereitgestellt werden soll
Abnahmeergebnisse	Ob die betroffene Kette abgelehnt wird, ob die normale Geschäftsverbindung erfolgreich ist und die Prüfzeit

Im Entwicklerhandbuch für Cloudflare heißt es ausdrücklich, dass SDK die Überprüfung an andere Komponenten delegieren kann; Nur das Aktualisieren der obersten Ebene SDK ändert nicht unbedingt die tatsächliche Vertrauensrichtlinie. 7

Betriebssysteme und Browser

Windows: aktiviert und überprüft die automatische Aktualisierung der Zertifikatsvertrauensliste. Verteilen Sie Updates über etablierte Verwaltungsrichtlinien. Bei Offline-Geräten oder Geräten mit deaktivierten automatischen Updates muss die Sperre durch einen geeigneten Verwaltungsprozess angewendet werden. Überprüfen Sie Programme, die die Windows-Systemvalidierung nicht verwenden, separat. 4

Apple Plattform: Komplette System-, Sicherheitskomponenten- und Anwendungsaktualisierungen. Informationen zu den Entwicklungstools auf macOS finden Sie auch im TLS-Backend, in den Zertifikatsdateien und in den Installationsquellen. Es kann nicht davon ausgegangen werden, dass die gesamte Maschine repariert wurde, nur weil Safari die Testkette abgelehnt hat. 4

Android: aktualisiert die Google Play-Dienste auf Geräten, auf denen es installiert ist. Google besagt, dass ein Neustart eines Geräts ein sofortiges Update auslösen kann. Befolgen Sie bei Geräten ohne diese Dienste die Hersteller- oder ROM-Beratung. Die Abdeckungserklärung von Google gilt nicht automatisch für jedes Android-Gerät. 1

Ubuntu/Debian: Aktualisieren Sie Zertifikatpakete aus unterstützten Repositorys und überprüfen Sie die Empfehlung für die installierte Distribution. Ein APT-basiertes System kann beispielsweise Folgendes verwenden:

sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates

Relevante Updates für Ubuntu 22.04, 24.04, 26.04 und 26.10 sind Standardunterstützung; Frühere Versionen sollten den ESM-Support und den Warehouse-Status überprüfen. Nachdem der Befehl erfolgreich beendet wurde, sollten Sie dennoch die Fixpack-Version im Bulletin vergleichen. 89

RHEL und verwandte Produkte: Überprüfen Sie das Zertifikatpaket und die Sicherheitsfehler nach Produktkanal. Die Versionsprüfung kann durchgeführt werden mit:

rpm -q ca-certificates

Verwenden Sie den unterstützten Aktualisierungsmechanismus DNF/YUM, um Hersteller-Patches zu erhalten. Wenn der Kanal noch keinen Fix bereitgestellt hat, betrachten Sie „kein aktualisierbares Paket“ nicht als sicher. Wenn es notwendig ist, die Root-Vertrauensstellung vorübergehend zu entfernen, ergreifen Sie die vom Hersteller klar aufgeführten Maßnahmen und bewerten Sie die Kompatibilität legitimer Unternehmenszertifikate. 10

FreeBSD: Aktualisieren Sie den relevanten Systemzweig gemäß den Anweisungen in der offiziellen Empfehlung und starten Sie dann die Daemons mit der betroffenen OpenSSL-Vertrauenskonfiguration neu oder starten Sie das System neu. 11

Anwendungen und Bilder

Überprüfen Sie nach Abschluss der entsprechenden Laufzeit- und Zertifikatabhängigkeitsaktualisierungen den Pfad der ausführbaren Datei, in der der Dienst tatsächlich ausgeführt wird, um zu vermeiden, dass das Terminal auf eine neue Version umgestiegen ist und der Daemon weiterhin das alte Installationsverzeichnis verwendet. Für Multi-Umgebungen Python, Service-Container und Anwendungen, die über eine eigene Laufzeit verfügen, sollten diese separat geprüft werden.

Speichern Sie für Komponenten, die neu erstellt werden müssen, die Build-Version, die Abhängigkeitsversion und die Bereitstellungs-Image-ID. Das Akzeptanzobjekt ist die tatsächlich laufende Instanz und kann nicht einfach das neue Tag in der Build-Maschine oder der Image-Registrierung überprüfen. 71214

Migration von Website-Zertifikaten

Wenn die Kette einer Website ein widerrufenes oder blockiertes Zwischenprodukt CA enthält oder letztendlich auf einem vertrauenswürdigen Stamm basiert, besorgen Sie sich eine andere Kette, die von den Clients weiterhin akzeptiert wird. Installieren Sie die vollständige Serverzertifikatskette und überprüfen Sie jeden Eingang, einschließlich Load Balancer, Reverse-Proxys, CDN-Endpunkte und direkt zugängliche Ursprünge. 15

Ob eine Migration erforderlich ist, hängt von der tatsächlichen Kette ab. Wenn Sie nur nach der Vertriebsmarke des Zertifikats filtern, werden möglicherweise Weiterverkaufs- oder Cross-Signing-Beziehungen übersehen. Wenn Sie nur auf die Erneuerung nach Ablauf des regulären Ablaufs warten, ist die Migration möglicherweise nicht unbedingt abgeschlossen, bevor der Root-Store aktualisiert wird.

Für andere normale Website-Zertifikate, die von CA ausgestellt wurden und nicht auf dem betroffenen Root basieren, besteht aufgrund dieses Vorfalls keine Notwendigkeit, sie erneut zu signieren. Gleichzeitig sollte der Website-Server selbst beim Aufruf externer Dienste weiterhin clientseitige Reparaturprüfungen durchführen.

7 Stellen Sie sicher, dass der Fix tatsächlich wirksam wird

Versionsprüfung und Verhaltensprüfung werden separat durchgeführt

Mithilfe von Versionsprüfungen wird bestätigt, dass Patches oder feste Komponenten bereitgestellt wurden. Mithilfe von Verhaltensprüfungen wird bestätigt, dass die Anwendung tatsächlich den erwarteten Verifizierungspfad verwendet. Die beiden Prüfungen lösen unterschiedliche Probleme und keine von beiden kann durch „Update-Befehl erfolgreich ausgeführt“ ersetzt werden.

Der Veranstaltungsverwalter stellt Materialien zur Testseite und Zertifikatskette bereit, und der Zugang ist im Anhang 4 konzentriert. Es sollte in der tatsächlichen Betriebsumgebung der Zielanwendung überprüft werden, wobei die normale Zertifikatsüberprüfungskonfiguration beibehalten werden sollte. 47

Überprüfen Sie die Ergebnisse	Schlussfolgerungen, die gezogen werden können
Ausdrücklich ablehnen, da die betroffene Kette nicht vertrauenswürdig ist	Zeigt an, dass der getestete Verifizierungspfad die Kette abgelehnt hat
Akzeptieren Sie die betroffene Kette normal	Zeigt an, dass dieser Pfad weiterhin repariert oder die Konfiguration überprüft werden muss.
DNS-Fehler, Verbindungszeitüberschreitung, Proxy-Ablehnung oder Dienst nicht erreichbar	Auf eine Beseitigung des Zertifikatsrisikos kann hieraus nicht geschlossen werden.
Browser lehnt ab, App-Aufruf wird jedoch nicht geprüft	Es kann nur der Browser, nicht das Hintergrundprogramm, bestätigt werden.
Die A-Kette wurde abgelehnt	Es muss noch überlegt werden, ob der Client einen anderen Cross-Signing-Pfad akzeptiert

Der Test sollte auch normale Geschäftsverbindungen abdecken, um zu vermeiden, dass alle fehlgeschlagenen Anfragen mit erfolgreichen Reparaturen nach Geschäftsausfällen verwechselt werden, die durch den Verlust von zu viel Vertrauen verursacht werden.

Vorgeschlagene Abschlussbedingungen

• Die Update-Quelle und die Version der betroffenen Komponenten werden dokumentiert.
• Die entsprechende laufende Instanz wurde neu gestartet, neu erstellt oder erneut bereitgestellt.
• Die eigentliche Anwendung lehnt die betroffene Kette ab und die TLS-Verifizierung für den normalen Geschäftsbetrieb funktioniert weiterhin.
• Es gibt keine Konfiguration zum vorübergehenden Deaktivieren der Zertifikatsüberprüfung, um die Verbindung wiederherzustellen.
• Wenn es um die Migration von Website-Zertifikaten geht, wurden alle externen Eingänge umgestellt und überprüft.

Die oben genannten Abschlussbedingungen sind Vorschläge für die Betriebs- und Wartungsabnahme dieser Entsorgung; Dies ist nicht gleichbedeutend mit dem Nachweis, dass das Gerät keine anderen Sicherheitsprobleme aufweist.

8 Historische HTTPS Verkehrs- und Risikogrenzen

Drei Arten von Schlüsseln haben unterschiedliche Verwendungszwecke

Schlüssel	Hauptzweck
CA privater Schlüssel	Signieren Sie die Identität und die Bindung des öffentlichen Schlüssels im Zertifikat
Privater Schlüssel der Website	Beweisen Sie die Serveridentität im zertifikatauthentifizierten TLS-Handshake
Sitzungsschlüssel	Schützen Sie die tatsächlich auf einer Verbindung übertragenen Daten

Das Erhalten des privaten Schlüssels CA ist nicht gleichbedeutend mit dem Erhalten des privaten Schlüssels der Website oder aller Sitzungsschlüssel. Bei einer normalen A-Verbindung mit Vorwärtsgeheimnis und temporärem Schlüsselaustausch werden historische Sitzungen nicht automatisch offengelegt, nur weil der langfristige Signaturschlüssel später kompromittiert wird. Die relevanten Sicherheitsattribute von TLS 1.3 finden Sie unter RFC 8446. 16

Das Hauptrisiko besteht dieses Mal in der Authentifizierungsphase: Akzeptiert der Client das Zertifikat des gefälschten Servers, baut er möglicherweise eine noch verschlüsselte Verbindung zum Angreifer auf. TLS 1.3 erfordert außerdem eine vertrauenswürdige Authentifizierung; Ein einfaches Upgrade der Protokollversion ist kein Ersatz für die Blockierung von CA.

Urteile, die derzeit gefällt werden können und die nicht

Bestätigt: Die spezifischen privaten Zwischenschlüssel CA sind kompromittiert. die betroffenen öffentlichen Vertrauenspfade haben eine große Reichweite; Große Plattformen und mehrere Software-Ökosysteme haben Maßnahmen ergriffen. 145

Durch diesen Vorfall wurde nicht nachgewiesen: dass alle Benutzer Man-in-the-Middle-Angriffe erlebt haben, dass andere private Schlüssel von CA kompromittiert sind, dass der gesamte historische HTTPS-Verkehr entschlüsselbar ist oder dass die Aktualisierung eines Browsers jede Anwendung auf dem Gerät schützt.

Die endgültige Beurteilung eines bestimmten Dienstes sollte auf seiner Zertifikatskette, der Überprüfungsrichtlinie, den tatsächlich ausgeführten Komponenten und dem Aktualisierungsstatus basieren und nicht nur darauf, ob in der Adressleiste HTTPS steht.

Anhang A Betroffener Zwischenname CA

Die folgenden Namen helfen bei der Vermögensprüfung. Namen ersetzen keine Zertifikatsfingerabdrücke oder Public-Key-Identifikatoren. Beim automatisierten Abgleich sollten die genauen Kennungen verwendet werden, die von den Betreuern oder Anbietern des Vorfalls veröffentlicht wurden, einschließlich gegensignierter Zertifikate. 5

Mitte CA	Zweck	Assoziierte Organisationen
EM EV TLS CA - G3B	TLS	eMudhra BV
EM OV TLS CA - G3B	TLS	eMudhra BV
EM DV TLS CA - G3B	TLS	eMudhra BV
EM EV TLS CA - G3C	TLS	eMudhra Inc
EM OV TLS CA - G3C	TLS	eMudhra Inc
EM DV TLS CA - G3C	TLS	eMudhra Inc
EM OV CS CA - G3B	Codesignatur	eMudhra BV
EM OV CS CA - G3C	Codesignatur	eMudhra Inc

TLS ist nicht genau derselbe Validierungs- und Widerrufsmechanismus wie die Code-Signierung. Der Schwerpunkt dieses Artikels liegt auf HTTPS/TLS; Die Codesignaturumgebung sollte für diesen Überprüfungszweck Microsoft, JDK oder verwandte Softwareanbieter übernehmen, und die Ergebnisse des Browsertests sollten nicht als Akzeptanz der Codesignatur angesehen werden. 515

Anhang B Referenzlink

Die folgenden Quellen wurden am 22. Oktober 2026 überprüft. Die fortlaufende Ankündigung kann weiterhin aktualisiert werden, und der Status und die Version im Text sollten anhand des Datums dieses Dokuments verstanden werden.

Fakten zu Vorfällen und Umgang mit der Plattform

[1] Google Chrome und Android Offizielle Ankündigung Beschreibt Schwachstellen im privaten Schlüssel, SPKI-Blockierung, Google Play-Dienstverteilung, CT-Schutz und Chrome-Root-Repository-Entfernungspläne. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates

[2] Mozilla Bugzilla 2083449 Ereignisdatensatz Enthält Originalberichte, unabhängige Überprüfung, Untersuchung des Generierungsprozesses, nachfolgende Korrekturen für Firefox Android und Diskussionen über die Migration von rechtlichen Zertifikaten; Konzentrieren Sie sich auf die Kommentare 5, 11, 29 und 30. eMudhra Private key compromise of Intermediate Certificates

[3] Mozilla Firefox Sicherheitshinweis Beschreibung der Notfallverteilung OneCRL und der anschließenden Entsorgung Firefox/NSS. Protecting Firefox users following the compromise of eMudhra intermediate certificates

[4] Ereigniskoordinator Dennis Jackson Wartungszusammenfassungs- und Erkennungsportal Bietet ergänzende Anweisungen zum Plattform- und Software-Reparaturstatus, zum Testeingang, zu Materialien der öffentlichen Zertifikatskette und zu Umgebungen wie Windows/macOS. Die Testergebnisse stellen lediglich die tatsächlich getesteten Verifizierungspfade dar. eMudhra Intermediate CA Compromise

[5] Mozilla Hinweis für Vertriebs- und Truststore-Betreuer Beschreibt 6 TLS und 2 Codesignatur-Zwischenprodukte CA, Sectigo Cross-Signing, Widerruf und Root-Trust-Verarbeitungsgrenzen und listet die genaue Zertifikat- und öffentliche Schlüsselidentifikation auf. oss-security eMudhra Intermediates Compromise

[6] eMudhra Offizielle Veranstaltungserklärung Geben Sie eine vorläufige Erklärung des Herstellers zum Schlüsselgenerierungsprozess an. Die genaue Ursache hängt noch vom Abschluss der abgeschlossenen Untersuchung ab. eMudhra Statement on Recent Certificate Security Incident

[7] Cloudflare Offizielle Unfall- und Reparaturanleitung Behandelt WARP, Cloudflare Tunnel, Überprüfung der Ursprungsseite, Laufzeitabhängigkeiten, Bildaktualisierungen und Überprüfungsmethoden. 8 eMudhra certificates are compromised Here is what you need to know

Betriebssysteme und Distributionen

[8] Ubuntu Offizielle Reparaturankündigung Listet die ca-certificates-Fixpakete, Supportkanäle und gezielten Aktualisierungsschritte für jede Version auf. eMudhra CA compromise fixes available

[9] Debian Offizielles Problem- und Reparaturprotokoll Der Fix-Datensatz des Betreuers und das entsprechende Release-Paket sollten als Standard verwendet werden, und frühe temporäre Vorschläge in der Problemdiskussion sollten nicht als endgültige Lösung angesehen werden. Debian bug 1151413 eMudhra Intermediate CA key compromise

[10] Red Hat Offizielles Sicherheitsbulletin RHSB 2026 012 Listet RHEL 6 bis 10, die damit verbundenen Produkt- und Containerauswirkungen sowie Fixfreigabe- und vorläufige Entsorgungseinträge auf. Certificate compromise eMudhra

[11] FreeBSD Offizielles Sicherheitsbulletin Stellen Sie betroffene Systemzweige, Reparaturversionen und Dienstneustartanforderungen bereit. FreeBSD SA 26 73 caroot

Laufzeit und Protokolle

[12] Python Offizielle Veranstaltungsbeschreibung Bietet Reparaturbasislinien für pip, certifi, uv usw., erklärt das Problem des alten unabhängigen Vertrauensspeichers pip und stellt die erste Upgrade-Methode mit SHA-256-Überprüfung bereit. Information for Python users regarding eMudhra emSign CA certificate security incident

[13] Node.js 24.22.1 Offizielle Veröffentlichung Enthält NSS-Root-Store-Updates und lehnt Änderungen ab, die blockierte Public-Key-Zertifikatketten enthalten. Node.js 24.22.1 security release

[14] Go Offizielle Sicherheitsversion Beschreibung crypto/x509-Zertifikatkettenfilterungs-Update für Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released

[15] Oracle JDK Offizielle Entsorgungsanweisungen Erläutern Sie den kritischen Patch JDK und die damit verbundenen Konfigurationsmaßnahmen, wenn ein sofortiges Upgrade nicht möglich ist. Distrusting eMudhra Intermediate Certificates in Oracle JDK

[16] TLS 1.3 Protokollstandard RFC 8446 Anweisungen zur Identitätsauthentifizierung, zum temporären Schlüsselaustausch und zur Weiterleitungsgeheimhaltung finden Sie im Anhang E.1. The Transport Layer Security Protocol Version 1.3

[17] Ereignisbezogene Stammzertifikat- und Ausstellungsbeziehungsdaten Wird verwendet, um die direkte Emittenten- und Cross-Signing-Beziehung zu verstehen. Der Root-Store-Einschlussstatus kann den letzten Widerrufs- oder Blockierungsstatus des Clients nicht ersetzen. Root certificate relationships JSON