Chrome soll das Root-Zertifikat emSign ECC Root CA–G3 am 27. Okt. aus seinem Truststore entfernen. Dadurch könnten Websites beeinträchtigt werden, deren TLS-Zertifikate weiterhin auf dieses Root zurückführen. Google hat gewarnt, dass einige legitime Zertifikate in Chrome nicht mehr funktionieren werden, darunter auch solche, die nie von den acht kompromittierten eMudhra-Intermediates ausgestellt wurden.
Die Entfernung des Roots folgt auf die Offenlegung vom 17. Okt., dass die privaten Schlüssel von acht eMudhra-Zwischenzertifizierungsstellen (CAs) mit unzureichender Zufälligkeit erzeugt worden waren und aus ihren öffentlichen Zertifikaten rekonstruiert werden konnten. Chrome blockierte diese Intermediates kurz nach Eingang der Meldung. Die Entfernung des übergeordneten Roots führt jedoch zu einem umfassenderen Bedarf an Zertifikatserneuerungen.
Öffentliche Websites, deren Zertifikatsketten weiterhin beim emSign ECC Root CA–G3 enden, benötigen Ersatz-Zertifikate aus einer anderen vertrauenswürdigen Hierarchie. Unternehmen müssen außerdem ausgehende Integrationen, Container, VPNs und Anwendungen prüfen, die das Zertifikatsvertrauen unabhängig verwalten.
Priorität hat es, betroffene Zertifikatsketten zu identifizieren, sie zu ersetzen und zu überprüfen, ob abhängige Dienste weiterhin funktionieren.
So ersetzen Sie von Chrome betroffene eMudhra-TLS-Zertifikate
Laut Google müssen Websitebetreiber, die emSign ECC Root CA–G3 verwenden, unverzüglich neue TLS-Zertifikate aus einer anderen, im Chrome Root Store enthaltenen Hierarchie beschaffen und installieren.
Administratoren sollten folgende Schritte durchführen:
- Inventar erstellen. Identifizieren Sie Websites, APIs, Load Balancer, Reverse-Proxys und andere internetseitig erreichbare Dienste, die TLS-Zertifikate präsentieren. Beziehen Sie interne Dienste, Entwicklungswerkzeuge, Container und Anwendungen ein, die möglicherweise von eMudhra-Zertifikaten abhängen.
- Die tatsächliche Zertifikatskette prüfen. Führen Sie den Befehl aus
openssl s_client -showcerts -connect example.com:443 -servername example.com, wobei Sieexample.comdurch den zu prüfenden Hostnamen ersetzen. Der Befehl zeigt die vom Server präsentierten Zertifikate an, die das Root-Zertifikat üblicherweise nicht enthalten. - Den Vertrauensanker bestätigen. Ermitteln Sie das ausstellende Intermediate und prüfen Sie, ob die Zertifikatskette auf emSign ECC Root CA–G3 zurückführt. Dass das Root-Zertifikat in der OpenSSL-Ausgabe fehlt, beweist nicht, dass der Dienst nicht betroffen ist.
- Ein Ersatz-Zertifikat beschaffen. Stellen Sie betroffene Zertifikate über eine andere vertrauenswürdige öffentliche CA-Hierarchie neu aus. Die Installation eines anderen Intermediates reicht nicht aus, wenn die resultierende Kette weiterhin vom entfernten Root abhängt.
- Das Ersatz-Zertifikat überall bereitstellen. Aktualisieren Sie redundante Server, Gateways, Load Balancer und andere TLS-Terminierungspunkte. Vergewissern Sie sich, dass die korrekten Intermediate-Zertifikate zusammen mit dem Ersatz-Zertifikat installiert sind.
- Abhängige Verbindungen testen. Überprüfen Sie den Browserzugriff, API-Aufrufe und Integrationen, die eine Verbindung zu betroffenen Endpunkten herstellen. Diese Systeme können die Zertifikatsvalidierung unterschiedlich durchsetzen.
- Nach der Bereitstellung überwachen. Achten Sie auf Fehler bei der TLS-Validierung, unerwartete Zertifikatswarnungen und Änderungen an den Zertifikatsketten.
Der Zertifikatsaustausch sollte außerdem eine Prüfung der TLS-Konfiguration des Dienstes umfassen. Aktuelle NGINX-Schwachstellen verdeutlichen, warum Administratoren TLS-bezogene Einstellungen und betroffene Serverversionen überprüfen müssen, statt anzunehmen, ein gültiges Zertifikat bedeute, dass die gesamte Verbindung sicher ist.
Warum ein funktionierendes Zertifikat trotzdem Probleme verursachen kann
Die beiden Maßnahmen rund um eMudhra lassen sich leicht verwechseln, sind aber nicht identisch.
Die am 17. Okt. erfolgte Notfallblockierung richtete sich gegen acht bestimmte Zwischenzertifizierungsstellen, deren private Schlüssel rekonstruiert werden konnten. Sechs davon waren für TLS-Zertifikate vorgesehen, zwei wurden für das Signieren von Code verwendet.
Cisco Talos berichtete, dass einige der privaten Schlüssel Werte im ein- oder zweistelligen Bereich aufwiesen, statt die erwartete Zufälligkeit zu besitzen. Dadurch wurde die Rekonstruktion der Schlüssel praktikabel und es entstand das Risiko von Zertifikatsfälschungen.
Der Fehler entstand während einer Zeremonie zur Schlüsselerzeugung am 30. Apr. 2025. eMudhra widerrief daraufhin die kompromittierten Intermediates und stellte die Ausstellung neuer Zertifikate unter seinem G3-Root ein.
Chromes Maßnahme vom 27. Okt. geht weiter: emSign ECC Root CA–G3 selbst wird aus dem Chrome Root Store entfernt.
Das bedeutet, dass ein Zertifikat legitim und noch nicht abgelaufen sein kann und keinen Bezug zu den acht kompromittierten Intermediates haben muss – und trotzdem in Chrome die Validierung nicht besteht, wenn seine Vertrauenskette vom entfernten Root abhängt.
Diese Unterscheidung ist wichtig, weil die Gültigkeitsdauer eines Zertifikats die Vertrauensentscheidung eines Browsers nicht außer Kraft setzt. Betreiber, die zuvor bestätigt haben, dass ihre Zertifikate nicht von den acht kompromittierten Intermediates ausgestellt wurden, müssen weiterhin das übergeordnete Root prüfen.
Chrome, Android und andere Plattformen reagieren
Google blockierte die acht kompromittierten Intermediates am 17. Okt. über Chromes CRLSet-Mechanismus. Der Schutz wurde verteilt, ohne ein vollständiges Browserupdate zu erfordern.
Das Unternehmen setzte die Entfernung von emSign ECC Root CA–G3 aus dem Chrome Root Store für den Morgen des 27. Okt. pazifischer Zeit an. Chrome Canary und Beta erhielten die Änderung früher.
Android-Geräte erhielten am 19. Okt. über Google Play-Dienste Schutz vor den kompromittierten Intermediate-Zertifikaten. Google erklärte, Nutzer könnten durch einen Neustart ihrer Geräte sofort ein Update auslösen.
Auch Mozilla blockierte die kompromittierten Intermediates und leitete die Entfernung des betroffenen Roots aus seinem Truststore ein. Apple begann am 19. Okt. damit, die betroffenen TLS-Intermediates zu blockieren.
Diese Maßnahmen adressieren unterschiedliche Teile des Problems beim Zertifikatsvertrauen. Die Blockierung der kompromittierten Intermediates verhindert, dass Clients Zertifikaten vertrauen, die über diese Schlüssel ausgestellt wurden. Die Entfernung des Roots betrifft eine größere Anzahl von Zertifikatsketten.
Unternehmen sollten daher das Verhalten von Zertifikaten in den von ihnen unterstützten Browsern, Betriebssystemen und Anwendungen überprüfen.
Über den Browser hinaus: Was Sicherheitsteams prüfen sollten
Änderungen an Browsern und Betriebssystemen erreichen nicht zwangsläufig Software, die ihren eigenen Zertifikatsspeicher oder Validierungsprozess verwendet.
Die Leitlinien von NHS England fordern dazu auf, Abhängigkeiten in Containern, Entwicklungswerkzeugen, IoT-Geräten, Betriebstechnik, mobilen Anwendungen und der internen PKI zu überprüfen.
Auch VPNs und andere Anwendungen, die ihre eigene TLS-Validierung durchführen, benötigen möglicherweise Updates der jeweiligen Anbieter.
Die Programmiersprache Go liefert dafür ein Beispiel. Ihr Sicherheitsteam veröffentlichte Go 1.27.3 und 1.26.10, um Zertifikatsketten mit den kompromittierten Intermediates zu blockieren. Das Problem wird unter CVE-2026-111943 geführt.
Unternehmen, die betroffene Go-Versionen verwenden, sollten den Sicherheitshinweis prüfen und Anwendungen bei Bedarf neu erstellen oder erneut bereitstellen.
Andere Anbieter haben verwandten Risiken eigene Kennungen zugewiesen, darunter CVE-2026-91403 für Oracle Java und CVE-2026-113470 für Firefox. Administratoren sollten den jeweiligen Sicherheitshinweisen der Anbieter folgen, statt anzunehmen, dass auf allen Plattformen dieselbe Behebung gilt.
Das Zertifikatsvertrauen kann auch davon abhängen, wie Anwendungen vertrauenswürdige Roots installieren oder verwalten. So betraf eine kürzlich offengelegte Schwachstelle in Fiddler Classic die Installation eines Root-Zertifikats im Windows-Truststore. Obwohl sie nicht mit eMudhra zusammenhing, zeigt sie, warum die Zertifikatsverwaltung auf Anwendungsebene separat überprüft werden muss.
Beim eMudhra-Vorfall sollten Anwendungsverantwortliche Systeme mit eingebetteten CA-Zertifikaten, unabhängig verwalteten Truststores oder Softwareversionen priorisieren, die noch nicht mit den relevanten Schutzmaßnahmen des Anbieters ausgestattet wurden.
Keine bestätigte Ausnutzung, Prüfungen dauern jedoch an
Die verfügbaren Berichte der Anbieter belegen keine böswillige Ausnutzung der kompromittierten Intermediate-Schlüssel.
Google erklärte, dass vor ihrer Blockierung durch Chrome keine TLS-Zertifikate, die auf die sechs betroffenen Intermediates zurückführten, in Certificate Transparency protokolliert worden waren. Daher konnten betrügerische Zertifikate dieser Intermediates von Clients, die Anforderungen an Certificate Transparency durchsetzen, nicht akzeptiert werden.
Cisco Talos meldete, bis zum 21. Okt. keine beobachteten böswilligen Vorfälle im Zusammenhang mit den kompromittierten Zertifikaten.
Auch eMudhra erklärte, keine Hinweise auf eine weitergehende Kompromittierung der Infrastruktur gefunden zu haben.
Diese Erkenntnisse belegen nicht, dass ein Missbrauch unmöglich war. Sie beschreiben, was die Anbieter zum Zeitpunkt ihrer Stellungnahmen beobachtet hatten.
Der Vorfall zeigt außerdem, warum eine HTTPS-Verbindung allein kein Beleg für die Legitimität einer Website ist. Wie frühere Berichte über Phishing-Zertifikate gezeigt haben, können Angreifer gültige TLS-Zertifikate für Domains erlangen, die sie kontrollieren, ohne eine Zertifizierungsstelle zu kompromittieren.
Für die Betreiber betroffener Websites besteht die unmittelbare Aufgabe darin, Zertifikate zu ersetzen, deren Kette auf emSign ECC Root CA–G3 zurückführt, und zu bestätigen, dass die neue Kette vertrauenswürdig ist. Anschließend sollten Sicherheitsteams die umfassendere Abhängigkeitsprüfung durchführen, um Anwendungen und Geräte zu identifizieren, die den kompromittierten Intermediates möglicherweise weiterhin vertrauen.
Google überprüft weiterhin die verbleibenden CA-Zertifikate von eMudhra. Administratoren sollten die Sicherheitshinweise der Anbieter auf weitere Vertrauensänderungen überwachen, statt anzunehmen, dass die Entfernung am 27. Okt. den Vorfall beendet.
Lesen Sie auch: Prüfen Sie die Tools für das Patchmanagement zur Koordinierung von Sicherheitsupdates in betroffenen Systemen.