eMudhra CA-Sicherheitslücke: Erkennen und beheben Sie Ihre Sicherheitsrisiken mit Tanium

Was ist geschehen?

Auf 17. Oktober 2026 berichtete ein Forscher, dass acht von eMudhra betriebene Zwischenzertifizierungsstellen (CAs) über private Schlüssel verfügen, die jeder anhand der öffentlichen Zertifikate berechnen kann. Sechs der Zertifikatsaussteller stellen TLS-Zertifikate (für Websites) aus, zwei dienen der Codesignierung. Sectigo hat dieselben acht Schlüssel kreuzsigniert, sodass insgesamt 16 Zertifikate betroffen sind

Mit diesen Schlüsseln kann jeder ein Zertifikat für eine beliebige Website ausstellen oder Software signieren, und es lässt sich auf Stammzertifizierungsstellen zurückführen, denen viele Systeme vertrauen. eMudhra hat seine acht Zertifikate am 18. Oktober widerrufen, und Sectigo hat seine acht am nächsten Tag widerrufen; der Widerruf schützt jedoch nur Software, die dies überprüft, und viele Nicht-Browser-Programme führen keine Überprüfung des Widerrufs durch.

Der primäre Eintrag ist Mozillas Fehlermeldung zu diesem Vorfall, Bugzilla 2083449 (wird in einem neuen Tab geöffnet).

Was ist gefährdet?

Browser sind geschützt, sobald ihre eigene Sperrliste auf dem neuesten Stand ist: Starten Sie die Browser neu und blockieren Sie den Datenverkehr für Browser-Updates nicht. Die meisten anderen Programme sind erst dann geschützt, wenn ihr eigener Vertrauensspeicher aktualisiert wurde.

Der Schutz ist gewährleistet, sobald die Sperrlisten auf dem neuesten Stand sind

• Chrome und Android: Google hat die Zwischenzertifikate in Chrome durch ein CRLSet-Update am 17. Oktober und auf Android über die Google Play-Dienste am 19. Oktober gesperrt. Google hat die Zertifizierungsstelle „emSign ECC Root CA – G3 “ aus dem Chrome-Root-Store (Version 43) entfernt; die Änderung ist bereits in den Versionen „Canary“ und „Beta“ enthalten und wird voraussichtlich am Dienstag, 27. Oktober, in die stabile Version von Chrome übernommen. (Google (wird in einem neuen Tab geöffnet))
• Firefox: über OneCRL auf 17. Oktober blockiert. Firefox 158,0,1, ESR 153,5,1 und ESR 115,43,1 enthalten die Sperre für Installationen, bei denen „Remote Settings“ aufgrund einer Richtlinie deaktiviert oder nicht verfügbar ist. Für Firefox für Android ist Version 158,0,2 erforderlich, die das Problem behebt, dass bei bestimmten Profilen die Sperre nicht angewendet wurde (Bugzilla 2083449, Kommentar 29). Mozilla hat zudem „emSign ECC Root CA – G3 “ aus seinem Stammzertifikatsspeicher (NSS 3,131,1) entfernt. (MFSA 2026-111 (wird in einem neuen Tab geöffnet), MFSA 2026-112 (wird in einem neuen Tab geöffnet), MFSA 2026-113 (wird in einem neuen Tab geöffnet))
• Edge: Seit Edge 112 (auf nicht verwalteten Geräten ab Edge 109 bis 111 im Rahmen einer schrittweisen Einführung) verwendet Edge unter Windows und macOS einen eigenen Zertifikatsprüfer sowie die mit dem Browser ausgelieferte Microsoft-Stammzertifikatsliste anstelle derjenigen des Betriebssystems (Microsoft (öffnet in einem neuen Tab)). Microsoft macht keine Angaben dazu, ob dieser Prüfer die Windows-Sperrliste berücksichtigt. Edge liefert eine eigene Sperrkomponente mit (aufgeführt unter edge://components); aktualisieren Sie diese daher anhand der folgenden Schritte, anstatt sich auf die Windows-Liste zu verlassen.
• Safari und andere Apple-Plattformen: Apple hat die Zwischenzertifikate Berichten zufolge seit 22. Oktober über sein eigenes Sperrsystem blockiert. Wir haben keinen Hinweis von Apple gefunden, und die macOS-Befehlszeilentools werden nicht behandelt (nächster Abschnitt).
• Windows: Microsoft blockiert die Zwischenzertifikate über seine Liste unzulässiger Zertifikate. Wir haben keinen Hinweis von Microsoft gefunden, doch in der von Microsoft selbst geführten Sperrliste mit dem Datum 19. Oktober sind alle acht kompromittierten Schlüssel aufgeführt, wodurch alle 16 Zertifikate abgedeckt sind. Die Sperre gilt nur für Geräte, die die Liste herunterladen (nächster Abschnitt).

Aktualisieren Sie die Sperrliste jedes Browsers. Öffnen Sie chrome://components (edge://components in Edge), suchen Sie die Komponente „CRLSet“ (so lautet die Bezeichnung in Chromium; die Bezeichnung in Edge haben wir noch nicht überprüft), klicken Sie auf „Nach Updates suchen“ und starten Sie den Browser neu. In einem internen Tanium-Labor wurden diese Versionen als geschützt angezeigt: Chrome mit CRLSet 10856, Edge mit CRLSet 6498,2026,10,20 und Firefox in den oben aufgeführten Versionen.

Zu sehen bis zur Aktualisierung

Es reicht nicht aus, nach den 16 Zertifikaten zu suchen. Server senden während des TLS-Handshakes Zwischendaten, sodass diese nur selten auf Endgeräten gespeichert werden. Eine erfolglose Suche nach deren Fingerabdrücken bedeutet nicht, dass ein Gerät sicher ist. Prüfen Sie, ob das Gerät den übergeordneten Zertifikaten vertraut und ob seine Software eine feste Version aufweist.

Zu suchende Wurzeln

Die Zertifizierungsstellen „emSign Root TLS CA – G3 “ und „emSign Root CS CA – G3 “ haben die Zwischenzertifikate direkt ausgestellt. Beide sind ihrerseits von der emSign ECC Root CA – G3 kreuzsigniert; auf diese Weise gelangen die TLS-Zwischenzertifikate zu Systemen, die ausschließlich ECC G3 vertrauen, wie beispielsweise die Datei „/etc/ssl/cert.pem“ auf dem oben genannten Mac. Mozilla und Chrome haben das Vertrauen in die emSign Root CA – G1 – nicht aufgehoben, und eMudhra stellt seine Abonnenten auf diese um; der Vorfall-Fehler wirft weiterhin offene Fragen hinsichtlich einer mit dem falschen Schlüssel signierten CRL G1 auf (Bugzilla 2083449, Kommentare 7 und 34).

Das Entfernen der emSign ECC Root CA – G3 führt auch zur Ungültigkeit legitimer Zertifikate: Etwa 30 800 noch gültige Zertifikate (gezählt anhand der Pre-Zertifikate aus Certificate Transparency), die mit ihr verkettet sind, wobei October 21, 99,9 % davon von den InCommon-Zwischenzertifikaten von Internet2 ausgestellt wurden (Bugzilla 2083449, Kommentar 30). Ziehen Sie das Paket-Update des Anbieters dem manuellen Entfernen der Root-Dateien vor.

Warum „AAA Certificate Services“ und „emSign ECC Root CA – G3 “ angezeigt werden und warum wir davon abraten, diese zu entfernen

Warum sie auftauchen. Diese beiden Wurzeln befinden sich oberhalb der kompromittierten Zwischenknoten, sodass sie bei jeder Suche nach einer Exposition gefunden werden. Beides sind tief verwurzelte Traditionen. Microsoft und Apple vertrauen nach wie vor auf AAA Certificate Services, und „emSign ECC Root CA – G3 “ ist in den Stammzertifikatsspeichern von Microsoft und Apple enthalten (beide Stammzertifikate erscheinen in der Liste der vertrauenswürdigen Stammzertifikate von Microsoft sowie im System-Schlüsselbund von macOS 26,7,1 , Stand: Oktober 23) sowie – bis zu den jüngsten Entfernungen – auch in denen von Mozilla und Chrome. Sie finden diese in den Zertifikatsspeichern von Windows, in nicht aktualisierten CA-Paketen unter Linux, in Java-cacerts- Dateien sowie unter /etc/ssl/cert.pem unter macOS. Der Zertifikatsmanager und der eMudhra-Root-CA-Bericht listen diese in Windows-Zertifikatsspeichern, Linux-Zertifikatsdateien und Java-Keystores im JKS- oder JCEKS-Format auf, sodass eine Übereinstimmung als Anzeichen für eine Kompromittierung gewertet werden kann. Alle standardmäßigen „cacerts“-Dateien ab JDK 18 sind PKCS #12 -Dateien, die vom Certificate Manager nicht überprüft werden; daher sind eigenständige JDK 18 - und spätere Laufzeitumgebungen nicht kompatibel (getestet mit einer Temurin 21,0,13 -Laufzeitumgebung). Unter macOS liest der Zertifikatsmanager ausschließlich Java-Keystores im Verzeichnis „/Library/Java/JavaVirtualMachines“ aus, nicht jedoch den Keychain oder die Datei „/etc/ssl/cert.pem“. Daher erscheint ein Mac in diesen Ergebnissen nur dann, wenn sich dort ein JDK-Keystore im JKS-Format befindet (JDK 17 oder älter).

Warum ein Spiel an sich kein Problem darstellt. Es liegen keine Hinweise darauf vor, dass der private Schlüssel einer der beiden Root-Zertifikate kompromittiert wurde. Die schwachen Schlüssel gehören zu den 16 Zwischenzertifikaten (Bugzilla 2083449 (wird in einem neuen Tab geöffnet)). In der Stellungnahme von eMudhra selbst ist von acht Zwischenzertifikaten die Rede, ohne dass diese oder die von Sectigo signierten Zertifikate namentlich genannt werden. Die Korrekturen zielen auf die Zwischenzertifikate ab oder stammen vom Anbieter: Browser, Microsoft und Apple blockieren die Zwischenzertifikate, und die Aktualisierungen der ca-Zertifikate unter Linux entfernen emSign ECC Root CA – G3 sowie unter Red Hat, CentOS Stream, Oracle Linux 8 bis 10 (die 23. Oktober „“-Updates), Debian und Ubuntu 14,04 bis 20,04 auch die AAA Certificate Services. Oracle Linux 7 blockiert stattdessen beide „roots“. Unter Windows gelten sowohl „AAA Certificate Services“ als auch „emSign ECC Root CA – G3 “ weiterhin als vertrauenswürdig, und die Sperrung erfolgt über die Liste der unzulässigen Zertifikate. Das Gleiche gilt für „emSign Root TLS CA – G3 “ und „emSign Root CS CA – G3“, die ebenfalls in der Liste der vertrauenswürdigen Stammzertifikate von Microsoft aufgeführt sind.

Warum wir davon abraten, sie von Hand zu entfernen.

• Beide Stammzertifikate dienen als Basis für gültige Zertifikate. Etwa 30 800 noch gültige Zertifikate (gezählt anhand der Pre-Zertifikate von Certificate Transparency), die mit der emSign ECC Root CA verknüpft sind – G3 bei October 21, 99,9 % davon wurden von den InCommon-Zwischenzertifikaten von Internet2 ausgestellt (Bugzilla 2083449, Kommentar 30). AAA Certificate Services dient als Stammzertifikat für andere Sectigo-Zertifikate. Das Entfernen eines der beiden Elemente kann dazu führen, dass Verbindungen zu Websites und Diensten unterbrochen werden, die nichts mit eMudhra zu tun haben. Die Hersteller-Updates, die diese Stammzertifikate entfernen, führen ebenfalls zu einer Ungültigkeit dieser Zertifikate; der Grund, stattdessen das Hersteller-Update zu installieren, besteht darin, dass der Hersteller die Änderung testet und den Vertrauensspeicher pflegt.
• Abhängigkeiten lassen sich nur schwer vorhersagen. Man kann im Voraus nicht ohne Weiteres erkennen, welche Anwendungen auf diese Stammzertifikate angewiesen sind, und die Fehler werden in allen Anwendungen, die diese Zertifikatsketten verwenden, als TLS-Fehler angezeigt.
• Die Hersteller-Updates nehmen diese Änderung bereits vor. Dies geschieht auf bewährte Weise, und durch die Installation wird derselbe Schutz gewährleistet, ohne dass ein manuell gepflegter Vertrauensspeicher erforderlich ist.

In dieser Anleitung geht es um die manuelle Bearbeitung von Zertifikatsspeichern. Mozilla, Chrome und mehrere Linux-Distributionen entfernen die emSign ECC Root CA – G3, und es wird empfohlen, diese Entfernung über das Update des Anbieters vorzunehmen. Installieren Sie die in den folgenden Tabellen aufgeführten Updates und stellen Sie unter Windows sicher, dass die Sperrliste auf dem neuesten Stand ist.

Falls Sie sich dennoch entschließen, zu handeln. Einige Systeme können nicht auf einen Hersteller-Patch warten: solche, für die noch kein Update verfügbar ist (CentOS Stream 10, Solaris, AIX), die Befehlszeilentools von macOS sowie Windows-Netzwerke, die keinen Zugriff auf Windows Update haben. Falls Sie das Vertrauen selbst aufheben:

1. Nehmen Sie die geringstmögliche Änderung vor. Unter Windows sollten Sie die 16 Zwischenprodukte blockieren, anstatt einen Stammordner zu entfernen. Importieren Sie diese in den Speicher „Disallowed“ (in der Zertifikatskonsole als „Untrusted Certificates“ angezeigt) mit dem Befehl „certutil -addstore Disallowed <Datei> “ (Microsoft (öffnet in einem neuen Tab)), oder stellen Sie in Netzwerken, die keinen Zugriff auf Windows Update haben, die CTL-Dateien intern bereit und verweisen Sie mit „RootDirUrl“ auf diese (Microsoft (öffnet in einem neuen Tab)). Auf anderen Plattformen sollten Sie zunächst der „emSign ECC Root CA – G3 “ misstrauen und die „AAA Certificate Services“ erst entfernen, nachdem Sie überprüft haben, welche Zertifikatsketten zu den Sectigo-Zertifikaten führen (die Updates für RHEL, CentOS Stream, Debian und Ubuntu 14,04 bis 20,04 entfernen diese ebenfalls).
2. Prüfen Sie zunächst, was von „root“ abhängt. Suchen Sie im Zertifikatsmanager im Zertifikatsbestand nach Zertifikaten, die von InCommon und Sectigo ausgestellt wurden, und überprüfen Sie, ob Dienste, auf die Sie angewiesen sind, eine Zertifikatskette zu dem Stammzertifikat aufweisen, das Sie entfernen möchten.
3. Nutzen Sie den plattforminternen Mechanismus zur Kennzeichnung als nicht vertrauenswürdig und nicht das Löschen von Dateien.
   • RHEL-Familie: Der Red Hat-KB-Artikel 7149312, auf den in Artikel RHSB-2026-012 verwiesen wird (wird in einem neuen Tab geöffnet), behandelt das Hinzufügen der Stammzertifikate von „Comodo AAA Services“ und „AAA Certificate Services“ zur Sperrliste. Bitte überprüfen Sie, ob auch die emSign ECC Root CA – G3 abgedeckt ist; sollte dies nicht der Fall sein, tragen Sie diese Root-Zertifizierungsstelle mit demselben Tool in die Sperrliste ein. Für OpenShift ist der entsprechende Artikel KB 7149347.
   • Debian und Ubuntu: Fügen Sie in der Datei /etc/ca-certificates.conf vor der Zeile des Zertifikats ein „!“ ein, um dessen Auswahl aufzuheben, und führen Sie anschließend den Befehl „update-ca-certificates“ aus (Ubuntu (wird in einem neuen Tab geöffnet)). Erstellen Sie anschließend die „cacerts“-Datei von Java neu, wie unter „Vertrauensspeicher unter Linux mit dem Patch aktualisieren“ in Schritt 2 beschrieben.
   • Java: Die von OpenJDK selbst empfohlene Vorgehensweise besteht darin, die Aliase emsigneccrootcag3 [jdk] und comodoaaaca [jdk] (das Suffix ist Teil des Alias) aus den cacerts der eigenständigen Laufzeitumgebungen zu löschen, auch nach einer Aktualisierung, beispielsweise mit dem Befehl „keytool -delete -cacerts -alias ‚emsigneccrootcag3 [jdk]‘“ unter JDK 11 und höher (OpenJDK (öffnet in einem neuen Tab)). Dies ist die einzige Ausnahme zu Schritt 1, da dabei auch die AAA-Zertifikatsdienste entfernt werden. Die Schritte finden Sie unter „Laufzeitumgebungen und Anwendungen mit Deploy aktualisieren“ in Schritt 2.
   • macOS-Befehlszeilentools: Verweisen Sie diese auf ein aktualisiertes CA-Bundle, wie beispielsweise „ca-certificates“ von Homebrew, anstatt die Datei „/etc/ssl/cert.pem“ zu bearbeiten.
4. Führen Sie die Einführung mit Tanium schrittweise durch. Erstellen Sie die Änderung als Tanium-Paket und stellen Sie sie zunächst einer kleinen Testgruppe bereit. Überprüfen Sie zunächst Ihre kritischen internen Endpunkte und die Ihrer Partner und weiten Sie die Einführung anschließend aus. Halten Sie ein Paket bereit, mit dem sich die Änderung rückgängig machen lässt. Stellen Sie anschließend die in Schritt 3 genannten Scan-Pakete bereit und führen Sie den eMudhra-Root-CA-Bericht erneut aus, um zu überprüfen, ob die Root-Zertifizierungsstelle nicht mehr an einem vertrauenswürdigen Speicherort aufgeführt ist.
5. Kehren Sie zum Trust-Store des Anbieters zurück, sobald es Ihnen möglich ist. Sobald das Hersteller-Update verfügbar ist, installieren Sie es und entfernen Sie alle manuellen Übersteuerungen, die Sie nicht mehr benötigen.

Die 16 kompromittierten Zwischenzertifikate (SHA-256)

Ausgestellt von eMudhra (widerrufen 18. Oktober, 2026):

Von Sectigo im Rahmen der AAA-Zertifikatsdienste (gesperrt 19. Oktober, 2026) mitunterzeichnet:

Quelle: Bugzilla 2083449, die Fehlerbeschreibung und der Kommentar 2.

SHA-1- und MD5 -Fingerabdrücke für die Stammzertifikate und die 16 Zwischenzertifikate

So wurden diese überprüft: Jedes Zertifikat wurde von crt.sh (wird in einem neuen Tab geöffnet) heruntergeladen und sein SHA-256-Hash vor der Hash-Berechnung in Bugzilla 2083449 abgeglichen; die Zwischenzertifikate 16 und SHA-1s stimmen ebenfalls mit einem Export aus dem Windows-Labor überein; die SHA-1s von emSign ECC Root CA – G3 sowie die AAA Certificate Services stimmen mit dem macOS-Root-Bundle überein; die anderen selbstsignierten Root-Zertifikate SHA-1s stimmen mit der Liste der vertrauenswürdigen Root-Zertifikate von Microsoft überein, und die beiden kreuzsignierten Einträge stammen von crt.sh (öffnet in einem neuen Tab).

Wurzeln:

Zwischenprodukte. Der öffentliche Schlüssel MD5 entspricht dem Wert MD5 des rohen EC-Schlüsselpunkts (der 97-Byte-Wert innerhalb des „SubjectPublicKeyInfo“-Eintrags, einschließlich des Präfixes 0x04 ); er ist daher für jedes eMudhra-Zertifikat und dessen Sectigo-Cross-Sign identisch, da diese einen gemeinsamen Schlüssel verwenden. Die Liste der unzulässigen Zertifikate von Microsoft identifiziert die kompromittierten Schlüssel anhand genau dieser Werte; daher sind es diese Werte, auf die der Befehl „certutil -verifyCTL Disallowed“ abgleicht. The MD5 of the whole SubjectPublicKeyInfo, which openssl pkey -pubin -outform DER | openssl md5 produces, is a different value.

Behobene Versionen ab 23. Oktober 2026

Vertrauensspeicher des Betriebssystems:

Software mit eigenem Vertrauensspeicher:

So nutzen Sie Tanium, um das Problem zu finden und zu beheben

Schritt 1: Fragen Sie Tanium Atlas

Fügen Sie diese Eingabeaufforderung in eine neue Atlas-Seite ein. Es enthält die Fingerabdrücke und die festgelegten Versionen, sodass Atlas diese nicht nachschlagen muss. Wenn Atlas eine Aktion vorschlägt, beispielsweise die Bereitstellung eines Pakets, werden Ihnen die Details angezeigt, und das System wartet auf Ihre Genehmigung, bevor die Aktion ausgeführt wird (weitere Informationen finden Sie im Tanium Resource Center (wird in einem neuen Tab geöffnet)).

Bitte ermitteln Sie, welche meiner Endpunkte von der Kompromittierung des Schlüssels der eMudhra-Zwischenzertifizierungsstelle (Oktober 2026) betroffen sind, und helfen Sie mir anschließend, diese Probleme zu beheben. Bitte nutzen Sie die nachstehenden Referenzdaten, anstatt im Internet zu suchen. 

1. Geben Sie auf Windows-Endgeräten an, ob die automatische Aktualisierung der Liste der unzulässigen Zertifikate deaktiviert ist: Der Registrierungswert „EnableDisallowedCertAutoUpdate“ unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot (0 bedeutet „deaktiviert“; „DisableRootAutoUpdate“ im selben Schlüssel steuert die Liste der vertrauenswürdigen Stammzertifikate, nicht die Liste der unzulässigen Zertifikate) sowie „RootDirUrl“ unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate (ein Wert bedeutet einen internen Spiegel). Eine kürzlich erfolgte Synchronisierung allein ist kein Hinweis darauf, dass das Gerät geschützt ist. Prüfen Sie, sofern möglich, mit dem Befehl „certutil -verifyCTL Disallowed <CertDir> <CertFile>“, ob die zwischengespeicherte Sperrliste des Geräts die kompromittierten Zwischenzertifikate enthält. Dazu müssen die Dateien der Zwischenzertifikate auf dem Endpunkt vorhanden sein.
2. Listen Sie anhand der Daten aus dem Zertifikatsmanager (Zertifikatsdetails) auf, wo ein Zertifikat mit einem der unten aufgeführten SHA-256-Fingerabdrücke gespeichert ist, aufgeschlüsselt nach Endpunkt und Speicherort. In den Zertifikatsdetails werden die Fingerabdrücke in Kleinbuchstaben angezeigt; vergleichen Sie diese daher ohne Berücksichtigung der Groß-/Kleinschreibung. Verwenden Sie den Speicherort, um festzulegen, was eine Übereinstimmung bedeutet: ein Zertifikat im Windows-Root- oder AuthRoot-Speicher oder in einer Linux-TLS-Vertrauensdatei (/etc/ssl/certs/ca-certificates.crt unter Debian und Ubuntu, /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem auf Systemen der RHEL-Familie oder eine Java-cacerts-Datei) als vertrauenswürdig für TLS gilt; dasselbe Zertifikat in den E-Mail- oder Codesignatur-Bundles, in „ca-bundle.trust.crt“ (das auch nicht vertrauenswürdige Einträge enthält), im Windows-Speicher „Disallowed“, in einem Blocklistenverzeichnis oder unter `/usr/share/ca-certificates` gilt nicht zwangsläufig als vertrauenswürdig. Unter Windows stellt eine Übereinstimmung mit einer der vier Stammzertifikate allein noch keine Sicherheitslücke dar, da alle vier in der Liste der vertrauenswürdigen Stammzertifikate von Microsoft enthalten sind und Microsoft die kompromittierten Zwischenzertifikate über seine Sperrliste blockiert. Keine Übereinstimmung bedeutet nicht, dass das Gerät sicher ist: Unter macOS liest der Zertifikatsmanager nur Java-Keystores; er überprüft keine PKCS #12 -Keystores, das Format aller standardmäßigen Java-cacerts ab JDK 18 ; geben Sie daher eigenständige JDK 18 - und spätere Laufzeitumgebungen nach Version an; und unter „Zertifikatsdetails“ werden Zertifikate auf der Ausschlussliste nicht angezeigt.
3. Geben Sie auf Linux-Endgeräten die Version des installierten Pakets „ca-certificates“ (bei SUSE „ca-certificates-mozilla“) an und vergleichen Sie diese mit den unten aufgeführten korrigierten Versionen. Für CentOS Stream 10 liegt noch keine endgültige Version vor, und für Solaris und AIX gibt es keine Herstellerempfehlungen: Melden Sie diese Endpunkte als exponiert, wenn ihr Vertrauensspeicher die emSign ECC Root CA – G3 enthält. Bei Distributionen, die unten nicht aufgeführt sind, wie beispielsweise Oracle Linux 7 und Ubuntu 14,04 bis 20,04, geben Sie bitte die Version an und kennzeichnen Sie den Endpunkt zur Überprüfung anhand der Sicherheitsempfehlung des Anbieters.
4. Ermitteln Sie die installierten Versionen von Node.js, Python und Firefox und vergleichen Sie diese mit den unten aufgeführten Versionen. Verlassen Sie sich bei Java nicht auf die Versionsangabe: Melden Sie eine eigenständige Laufzeitumgebung so, wie sie angezeigt wird, solange deren „cacerts“-Datei noch den Alias „emsigneccrootcag3 [jdk]“ oder „comodoaaaca [jdk]“ enthält (überprüfen Sie dies mit dem Befehl „keytool -list -cacerts -alias <alias>“ unter JDK 11 und höher), es sei denn, die Sperrprüfung ist mit „-Dcom.sun.net.ssl.checkRevocation=true“ -Dcom.sun.security.enableCRLDP=true aktiviert ist; beurteilen Sie das im Betriebssystem integrierte OpenJDK anhand der Überprüfung der ca-Zertifikate in Schritt 3. Für Go listen Sie bitte die gefundenen Go-Programme auf; anhand der installierten Go-Toolchain-Version lässt sich nicht erkennen, ob diese neu kompiliert wurden.
5. Fassen Sie die exponierten Endpunkte nach Plattform und Grund zusammen. Schlagen Sie dann die Aktualisierungen vor (Patch für Linux-Pakete, Bereitstellung von Software-Updates sowie die Entfernung der beiden Java-Aliase) und warten Sie auf meine Genehmigung, bevor Sie irgendetwas bereitstellen.

Stammzertifikate (SHA-256):
- emSign ECC Root CA – G3: 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B
- AAA Certificate Services: D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4
- emSign Root TLS CA – G3: 7DD78D5F4F13459A83DFF9ABBBA62EDBAF6F2D102BF257FD712F4D9F2746ED8D
- emSign Root TLS CA – G3, kreuzsigniert durch emSign ECC Root CA – G3: 3094025792039A68AF6E553686410BDAB7C0D4A36B9084CBA64202E35D6EBBDD
- emSign Root CS CA – G3: F2EDAAFF3D9B701FB4D14C9F285F8C0BAD90FC3BCC1FA07D47F4718EDABA34A5
- emSign Root CS CA – G3, kreuzsigniert durch emSign ECC Root CA – G3: 7137FA71AD46BA686F746D1014AC57E8E6C6E9AF4AA2F73C0C44A5CF27DEBB59

Compromised Zwischenzertifikate (SHA-256): 
42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD

Fixed Versionen:
- RHEL 10: ca-certificates-2026,2,92_v9,0,319-100,3.el10_2
- RHEL 9: ca-certificates-2026,2,92_v9,0,319-90,3.el9_8
- RHEL 8: ca-certificates-2026,2,92_v9,0,319-81,3.el8_10
- CentOS Stream 9: ca-certificates-2026,2,92_v9,0,319-91,3.el9
- Ubuntu 22,04 / 24,04 / 26,04 / 26,10: ca-certificates 20260816ubuntu0,22,04,1 / 20260816ubuntu0.24,04,1 / 20260816ubuntu0.26,04,1 / 20260816ubuntu0.26,10,1
- Debian 13: ca-certificates 20250419+deb13u1
- Debian 12: ca-certificates 20250419–deb12u2
- RHEL 7 ELS: ca-certificates-2026,2,92_v9,0,319-70,3.el7_9
- Oracle Linux 10: ca-certificates-2026,2,92_v9,0,319-100,3.el10_2 (ELSA-2026-88455)
- Oracle Linux 9: ca-certificates-2026,2,92_v9,0,319-90,3.el9_8 (ELSA-2026-88459)
- Oracle Linux 8: ca-certificates-2026,2,92_v9,0,319-81,3.el8_10 (ELSA-2026-88550)
- SUSE Linux Enterprise Server 15  SP7: ca-certificates-mozilla 2,92-150200,50,2 oder höher
- Java, aktuelle Versionen (stellen für eigenständige Laufzeitumgebungen keine eigenständige Lösung dar): 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, 8u511  b32. Eine eigenständige Laufzeitumgebung wird erst dann korrigiert, wenn beide Aliase aus ihren CACERTs entfernt wurden oder die Sperrprüfung aktiviert ist.
- Node.js: 26,12,1, 24,22,1, 22,23,4
- ; Go: 1,27,3, 1,26,10 (Programme müssen neu kompiliert werden)
- Python: 3,15,1, 3,14,9, 3,13,17; certifi 2026,10,19; pip 26,2,2
- ; Firefox: 158,0,1 (158,0,2 unter Android), ESR 153,5,1, ESR 115,43,1

Schritt 2: Oder führen Sie die Überprüfungen selbst durch

Erfahren Sie mit dem Zertifikatsmanager, wo die Zertifikate gespeichert sind. Das „Certificate Manager“-Audit liest die Windows-Zertifikatsspeicher sowie die Zertifikatsdateien in den Verzeichnissen /etc/pki, /etc/ssl, /usr/share/ca-certificates und den JVM-Verzeichnissen unter Linux aus (weitere Informationen finden Sie im Tanium Resource Center (wird in einem neuen Tab geöffnet)). Es liest jedes Zertifikat in einer .crt-, .cer- oder .pem -Datei ein, einschließlich Zertifikatsbündeln wie beispielsweise /etc/ssl/certs/ca-certificates.crt. Stellen Sie die untenstehende Frage, um einen Fingerabdruck zu erhalten. Der Sensor „Zertifikatsdetails“ gibt Fingerabdrücke in Kleinbuchstaben aus.

Rufen Sie den Computernamen und die Zertifikatsdetails ab, wobei die Zertifikatsdetails lauten: SHA256 Fingerabdrücke enthalten 86a1ecba089c4a8d3bbe2734c612ba341d813e043cf9e8a862cd5c57a36bbe6b von allen Rechnern

Um alle Stamm- und Zwischenmerkmale auf einmal zu überprüfen, importieren Sie bitte die beiden unten aufgeführten eMudhra-Berichte, anstatt die Abfrage für jeden Fingerabdruck einzeln zu wiederholen.

Sehen Sie in der Spalte „Standort“ nach, was eine Übereinstimmung bedeutet. Ein Zertifikat, das sich im Windows-Root- oder AuthRoot-Speicher oder in einer Linux-TLS-Vertrauensdatei befindet, gilt für TLS als vertrauenswürdig. Die TLS-Vertrauensdateien lauten unter Debian und Ubuntu „/etc/ssl/certs/ca-certificates.crt“ , auf Systemen der RHEL-Familie „/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem“ und für Java „cacerts“ aus dem JDK. Dieselbe Root-Zertifizierung taucht auch in Dateien mit anderem Verwendungszweck auf, wie beispielsweise „email-ca-bundle.pem“ und „objsign-ca-bundle.pem“ im selben „pem“-Verzeichnis sowie in der Datei „/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt“, die zudem nicht vertrauenswürdige Einträge enthält; eine Übereinstimmung an dieser Stelle bedeutet nicht, dass TLS-Vertrauen besteht. Dasselbe Zertifikat, das sich im Windows-Speicher „Disallowed“, in einem Blocklistenverzeichnis oder in einem Quellverzeichnis wie beispielsweise /usr/share/ca-certificates befindet, gilt nicht zwangsläufig als vertrauenswürdig; daher sollten Sie unter Linux die Version des Pakets „ca-certificates“ als entscheidendes Kriterium heranziehen.

Unter Windows deutet eine Übereinstimmung mit nur einer der vier Wurzeln allein nicht auf eine Exposition hin. Alle vier sind in der Liste der vertrauenswürdigen Zertifikatsstellen von Microsoft enthalten, sodass der Zertifikatsmanager sie auf einem geschützten Gerät finden kann. Die Sperre von Microsoft gilt für die kompromittierten Zwischenzertifikate über die Sperrliste; überprüfen Sie daher bitte stattdessen diese Liste (nächster Schritt).

Es gelten vier Einschränkungen: Unter macOS liest der Zertifikatsmanager nur Java-Keystores, nicht jedoch den Keychain oder die Datei „/etc/ssl/cert.pem“; er überprüft keine Java-Keystores im PKCS #12 -Format – dem Format aller Standard-cacerts ab JDK 18 –, sodass ein eigenständiges JDK 18 oder höher nicht berücksichtigt wird; er erkennt Benutzerzertifikatsspeicher nur für Benutzer, die während des Audits angemeldet sind; und unter „Zertifikatsdetails“ werden ruhende Zertifikate auf der Ausschlussliste nicht berücksichtigt. Keine Übereinstimmung bedeutet nicht, dass ein Gerät sicher ist. Um eigenständige JDK-Laufzeitumgebungen ab Version 18 zu überprüfen, suchen Sie diese anhand der Versionsnummer und überprüfen Sie anschließend die jeweiligen „cacerts“-Dateien mit „keytool“, beispielsweise mit dem Befehl „keytool -list -cacerts -alias ‚emsigneccrootcag3 [jdk]‘“.

Bitte überprüfen Sie, ob Windows-Geräte die Sperre von Microsoft erhalten. Fragen Sie:

Rufen Sie die Daten zu Computernamen und Registrierungswerten [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot, EnableDisallowedCertAutoUpdate] von allen Computern ab, bei denen „Is Windows“ den Wert „true“ hat.

Der Wert 0 bedeutet, dass die automatischen Aktualisierungen der Sperrliste deaktiviert sind. Die meisten Geräte geben die Meldung „Schlüssel/Wert nicht gefunden“ zurück, was bedeutet, dass der Richtlinienwert nicht festgelegt ist; daher sind automatische Updates aktiviert – dies entspricht der Microsoft-Standardeinstellung. „DisableRootAutoUpdate“ im selben Schlüssel steuert die Liste der vertrauenswürdigen Root-Zertifikate und nicht die Liste der unzulässigen Zertifikate; daher hat dieser Eintrag keinen Einfluss darauf, ob die Sperre von Microsoft wirksam wird. Ein „RootDirUrl“-Wert unter „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate“ bedeutet, dass das Gerät seine Listen von einem internen Spiegel (Microsoft (wird in einem neuen Tab geöffnet)) herunterlädt. Um diese Geräte zu finden, fragen Sie:

Rufen Sie den Computernamen und die Registrierungswertdaten [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate, RootDirUrl] von allen Computern ab, bei denen „Is Windows“ den Wert „true“ hat

Geräte, die einen Wert zurückgeben, verwenden einen internen Spiegel.

Eine kürzlich durchgeführte Synchronisierung zeigt lediglich, dass das Gerät eine Liste abgerufen hat, nicht jedoch, dass diese Liste die kompromittierten Zwischenwerte enthält; überprüfen Sie daher den Inhalt. Microsoft dokumentiert den Befehl „certutil -verifyCTL Disallowed <CertDir> <CertFile>“, der eine Zertifikatsdatei mit der im Cache des Geräts gespeicherten Liste unzulässiger Zertifikate abgleicht (Microsoft (öffnet in einem neuen Tab)). Die Liste ist nach öffentlichen Schlüsseln sortiert, und jedes eMudhra-Zertifikat teilt sich seinen Schlüssel mit dem entsprechenden Sectigo-Cross-Sign-Zertifikat, sodass die acht von eMudhra ausgestellten Zertifikatsdateien ausreichen. Führen Sie sie über ein Tanium-Paket (PEM oder DER) aus, wobei jede Datei als Zertifikatsdatei verwendet wird. Ein gelistetes Zertifikat gibt die Meldung „Zertifikatsübereinstimmung gefunden“ aus und beendet den Vorgang mit dem Code 0. Bei einem nicht aufgeführten Zertifikat wird die Meldung „Zertifikatsübereinstimmung NICHT gefunden“ ausgegeben, und das Programm wird mit dem Code 0x80094005 (CERTSRV_E_INVALID_CA_CERTIFICATE) beendet; dies sieht zwar wie ein Fehler aus, bedeutet jedoch lediglich, dass das Zertifikat nicht in der Liste enthalten ist.

Aktualisieren Sie die Linux-Vertrauensspeicher mit „Patch“. Tanium Patch überprüft Linux-Endgeräte anhand der von Ihnen konfigurierten Repositorys. Stellen Sie sicher, dass diese Repositorys die korrigierte Version von „ca-certificates“ enthalten, und stellen Sie diese anschließend auf den oben genannten Endpunkten bereit. Unter Debian und Ubuntu reicht es für Java nicht aus, die Pakete „ca-certificates“ und „ca-certificates-java“ zu aktualisieren. Notieren Sie sich zunächst alle Zertifizierungsstellen, die Sie selbst zum Java-Speicher hinzugefügt haben, da der Neuaufbau vom Systemspeicher ausgeht und Sie diese erneut hinzufügen müssen (Ubuntu (wird in einem neuen Tab geöffnet)). Löschen Sie anschließend als Root den Ordner /etc/ssl/certs/java/cacerts und führen Sie den Befehl „update-ca-certificates --fresh“ aus (OpenJDK (wird in einem neuen Tab geöffnet)).

Aktualisieren Sie Laufzeitumgebungen und Anwendungen mit „Deploy“. Verwenden Sie den Sensor „Installierte Anwendungen“, um installierte Produkte und deren Versionen zu ermitteln, beispielsweise Java, Node.js, Python und Firefox, und aktualisieren Sie diese anschließend mit Tanium Deploy. Der Sensor zeigt nicht an, auf welchem Framework eine Anwendung basiert, und listet keine aus einem Archiv extrahierte Laufzeitumgebung auf: Bei Electron-basierten Anwendungen überprüfen Sie bitte die Hinweise des jeweiligen Anbieters oder verwenden Sie das unten aufgeführte SBOM-Add-in und durchsuchen Sie die Endpunkte nach Dateien, um nicht verpackte Laufzeitumgebungen zu finden. Atlas kann die Bereitstellung für Sie entwerfen (Weitere Informationen finden Sie im Tanium Resource Center (wird in einem neuen Tab geöffnet)). Sofern Sie über eine Tanium-SBOM-Lizenz verfügen, zeigt das SBOM-Add-in für Asset auch die in Anwendungen gebündelten Bibliotheken an. Bei eigenständigen Java-Laufzeitumgebungen reicht eine Aktualisierung nicht aus: Laut OpenJDK sollten Sie auch bei den aktuellen Versionen entsprechende Maßnahmen ergreifen. Erstellen Sie eine Sicherungskopie von „cacerts“, löschen Sie die Aliase „emsigneccrootcag3 [jdk]“ und „comodoaaaca [jdk]“ mit „keytool“ (ignorieren Sie dabei einen Fehlermeldung für einen nicht vorhandenen Alias) und starten Sie die Java-Prozesse neu oder aktivieren Sie die Sperrprüfung mit „-Dcom.sun.net.ssl.checkRevocation=true“ -Dcom.sun.security.enableCRLDP=true (OpenJDK (wird in einem neuen Tab geöffnet)). Behandeln Sie eine eigenständige Laufzeitumgebung so lange als offen, bis eine dieser Maßnahmen abgeschlossen ist. Da durch das Löschen der Aliase die AAA-Zertifikatsdienste entfernt werden, prüfen Sie bitte zunächst, welche Java-Anwendungen auf Sectigo-Zertifikate angewiesen sind.

Falls noch keine Lösung vorliegt, befolgen Sie bitte die Schritte unter „Falls Sie sich dennoch zum Handeln entschließen“ weiter oben. Beschränken Sie sich ausschließlich auf die Endpunkte, die bei den oben genannten Überprüfungen ermittelt wurden, und führen Sie die Tests zunächst an einigen wenigen Endpunkten durch.

eMudhra-Bericht

Die Datei „eMudhra_Intermediate_CA_Report.json“ enthält einen Bericht des Zertifikatsmanagers, der alle 16 kompromittierten Zwischenzertifizierungsstellen in der Umgebung ermittelt. Dies sind die Zertifikate mit kompromittierten Schlüsseln. Alle in diesem Bericht festgestellten Ergebnisse erfordern weitere Untersuchungen und Abhilfemaßnahmen.

Die Datei „eMudhra_Root_CA_Report.json“ enthält einen Bericht des Zertifikatsmanagers, der nach den 6 Stammzertifizierungsstellen sucht, die die kompromittierten Zwischenzertifizierungsstellen signiert haben. Diese Wurzeln sind nicht beeinträchtigt. Es ist zu erwarten, dass auch auf aktuellen Windows-Geräten, die nach wie vor allen vier Root-Zertifikaten vertrauen, Übereinstimmungen auftreten. Macs werden nur über einen JDK-Keystore im JKS-Format (JDK 17 oder älter) unter /Library/Java/JavaVirtualMachines angezeigt, da der Zertifikatsmanager unter macOS ausschließlich Java-Keystores liest. Unter Linux bedeutet der Eintrag „emSign ECC Root CA – G3 “ in der TLS-Vertrauensdatei (/etc/ssl/certs/ca-certificates.crt oder tls-ca-bundle.pem), dass die Aktualisierung der Zertifikate der Zertifizierungsstelle fehlt; unter RHEL, CentOS Stream, Debian und Ubuntu 14,04 bis 20,04 gilt dasselbe für AAA Certificate Services. Entfernen Sie die Wurzeln nicht aufgrund dieses Berichts. Der Bericht wird den Kunden der Vollständigkeit halber zur Verfügung gestellt.

In jedem Bericht wird angezeigt, auf welchen Endgeräten das Zertifikat vorhanden ist und wo es auf dem jeweiligen Endgerät gespeichert ist. Lesen Sie die Spalte „Standort“ wie in Schritt 2 beschrieben aus. Für den Bericht muss der Zertifikatsmanager auf jedem Endgerät installiert und die Zertifikatsprüfung abgeschlossen sein.

Schritt 3: Bestätigen

Der Zertifikatsmanager erfasst Änderungen an Dateien erst, wenn sein regelmäßiger Hintergrundscan ausgeführt wird (in einem internen Labor im Abstand von etwa 20 Stunden), und führt den Scan des Windows-Speichers sowie der Abhörports nach einem eigenen Zeitplan durch; daher können die Ergebnisse unmittelbar nach einem Update noch die alten Stammzertifikate anzeigen. Stellen Sie zunächst das Paket „Index bereitstellen – Scans erzwingen“ (dateibasierte Zertifikate) und das Paket „Zertifikatsmanager – Überwachung des Listening-Dienstes erzwingen“ (Windows-Speicher und Listening-Dienste) bereit. Stellen Sie anschließend dieselben Fragen erneut, führen Sie die beiden eMudhra-Berichte erneut aus und speichern Sie die Fragen, damit Sie sie erneut ausführen können, sobald weitere Anbieter Korrekturen bereitstellen. Verlassen Sie sich bei dieser Überprüfung nicht auf den integrierten Bericht „Zertifikatsmanager – Details zu Stammzertifikaten“: Er berücksichtigt lediglich Einträge aus dem Windows-Speicher an Stamm- oder vertrauenswürdigen Speicherorten sowie Dateien unter /etc/pki oder /etc/ssl , deren Pfad das Wort „trust“ enthält. Daher werden Debian- und Ubuntu-Pakete wie /etc/ssl/certs/ca-certificates.crt, die meisten Java -cacerts -Dateien sowie Macs nicht angezeigt.

Quellen

• Mozilla Bugzilla 2083449 (wird in einem neuen Tab geöffnet), der Vorfallseintrag mit der Zertifikatsliste und den Fingerabdrücken
• Google: Schutz für Chrome- und Android-Nutzer (wird in einem neuen Tab geöffnet)
• Red Hat RHSB-2026-012 (wird in einem neuen Tab geöffnet)
• Ubuntu USN-8944-1 (wird in einem neuen Tab geöffnet) und USN-8944-2 (wird in einem neuen Tab geöffnet)
• OpenJDK-Leitfaden (wird in einem neuen Tab geöffnet)
• Microsoft: Vertrauenswürdige Zertifikatsstämme und unzulässige Zertifikate konfigurieren (wird in einem neuen Tab geöffnet)
• Debian LTS DLA-4845-1 (wird in einem neuen Tab geöffnet) für Debian 12
• Chrome Root Store, root_store.textproto Version 43 (wird in einem neuen Tab geöffnet)