Kompromittierte eMudhra-CA-Schlüssel machen Browser-Trust-Updates zum IT-Flottencheck

Was kompromittiert wurde – und was nicht

Am 17. Oktober entwickelte sich der eMudhra-Vorfall von einem Problem der Zertifikatsverwaltung zu einer umfassenderen Vertrauensentscheidung. Ermittler stellten fest, dass sich die privaten Schlüssel von acht untergeordneten eMudhra-Zertifizierungsstellen rekonstruieren ließen, weil sie mit unzureichender kryptografischer Zufälligkeit erzeugt worden waren. Dieses Detail ist entscheidend: Mit einem kompromittierten privaten CA-Schlüssel kann ein Angreifer Zertifikate erstellen, die scheinbar über eine vertrauenswürdige Stelle verkettet sind. Die Reaktion darf sich daher nicht auf die Frage beschränken, ob eine bestimmte Website aufgerufen wurde. Erforderlich ist vielmehr eine genaue Bestandsaufnahme der betroffenen ausstellenden Stellen sowie eine Trennung zwischen bestätigter Gefährdung und Annahmen über den übrigen Teil der eMudhra-Hierarchie.

Die acht betroffenen untergeordneten CAs lassen sich in zwei klar getrennte Gruppen einteilen. Sechs davon waren TLS-Intermediate-CAs, die in Zertifikatsketten für verschlüsselte Netzwerkverbindungen verwendet wurden. Die beiden anderen waren Code-Signing-Intermediate-CAs, die Signaturen für Software oder andere signierte Inhalte unterstützten. Würde man diese Kategorien gleich behandeln, würden zwei unterschiedliche Prüfungsfragen vermischt. Ein Browser oder Betriebssystem kann beim Verbindungsaufbau zu einem Dienst eine TLS-Kette bewerten, während ein Prüfer für Codesignaturen beim Entscheid über die Vertrauenswürdigkeit einer Software eine Signatur und deren Zertifikatskette auswertet. Beide Verfahren beruhen auf Zertifikatsinfrastruktur, doch die betroffenen Anwendungsfälle sowie die Systeme, die Vertrauen zwischenspeichern oder durchsetzen, sind nicht identisch.

Die Hinweise von Google und Mozilla beschreiben die Kompromittierung als einen Vorfall, der diese acht eMudhra-Intermediate-CAs betrifft. Ihre Leitlinien markieren zugleich eine wichtige Grenze dessen, was nicht festgestellt wurde: In den genannten Hinweisen gibt es keinen Anhaltspunkt dafür, dass jedes eMudhra-Root-Zertifikat oder jedes andere eMudhra-Intermediate kompromittiert wurde. Das ist kein Grund, sämtliche eMudhra-Zertifikate unangetastet zu lassen, aber ebenso wenig eine Grundlage dafür, die gesamte Zertifizierungsstelle pauschal als unsicher zu behandeln. Die praktischere und präzisere Frage lautet: Vertraut ein System auf eines der identifizierten Intermediate-Zertifikate oder auf eine Kette, die über einen Root- oder Cross-Signing-Pfad führt, den Anbieter aus dem Vertrauensmodell entfernen?

Diese Unterscheidung erklärt, warum die Reaktion über gezielte Maßnahmen zum Entzug des Vertrauens umgesetzt wird und nicht über die pauschale Behauptung, jedes von eMudhra ausgestellte Zertifikat sei ungültig. Anbieter können Zertifikate blockieren, die mit dem betroffenen öffentlichen Schlüsselmaterial verbunden sind, oder bestimmte Vertrauenspfade entfernen. Administratoren müssen jedoch weiterhin klären, ob ihre eigenen Zertifikate, ihre Inspektionsinfrastruktur, ihre Workflows zur Softwarevalidierung oder eingebettete Truststores von diesen Pfaden abhängen. Anders gesagt: Die bestätigte Kompromittierung benennt die Schlüssel, die als offengelegt behandelt werden müssen. Sie beantwortet nicht automatisch, welche Dienste einer Organisation ausfallen, wenn das Vertrauen verschärft wird.

Auch die technische Ursache ist bedeutsam. Die Rekonstruierbarkeit der privaten Schlüssel wurde auf unzureichende Zufälligkeit bei der Erzeugung kryptografischer Schlüssel zurückgeführt. Das unterscheidet sich von einem Hinweis darauf, dass ein Angreifer ein Passwort erraten oder einen privaten Schlüssel durch einen gewöhnlichen Einbruch in einen Server erlangt hätte. Sobald sich das zugrunde liegende Schlüsselmaterial jedoch rekonstruieren lässt, ist die betriebliche Konsequenz für abhängige Systeme ähnlich: Zertifikate, die unter den betroffenen untergeordneten CAs ausgestellt wurden, können nicht mehr allein deshalb als vertrauenswürdig gelten, weil sie den vertrauten Namen eMudhra tragen oder zu einem anerkannten Root-Zertifikat führen. Die Validierung muss den spezifisch kompromittierten Aussteller und die inzwischen eingesetzten Maßnahmen zum Entzug des Vertrauens berücksichtigen.

Für IT-Teams sollte die erste Inventargrenze daher bei der Zertifikatskette liegen, nicht bei der Marke, die in einem Zertifikatsbetrachter angezeigt wird. Dokumentieren Sie, ob Zertifikate bei einem der sechs betroffenen TLS-Intermediate-Zertifikate enden, ob signierte Software eines der beiden Code-Signing-Intermediate-Zertifikate verwendet und ob die Kette einen betroffenen Root- oder Cross-Signing-Pfad erreicht, dessen Entfernung ein Anbieter angekündigt hat. Halten Sie außerdem das negative Ergebnis sichtbar: Systeme, die nicht betroffene eMudhra-Roots oder -Intermediate-Zertifikate verwenden, gelten aufgrund der hier zitierten Hinweise nicht automatisch als kompromittiert. Diese Trennung macht spätere Abhilfemaßnahmen präziser, bewahrt einen nachvollziehbaren Nachweis der durchgeführten Prüfung und verhindert, dass ein gezieltes Truststore-Update durch einen unnötig weitreichenden Ausfall ersetzt wird.

Warum Browser-Nutzer schneller geschützt waren als andere Software

Die erste Schutzschicht erreichte verbreitete Browser, weil deren Anbieter Vertrauensentscheidungen über zentral verwaltete Update-Mechanismen verteilen können. Chrome nutzte eine SPKI-basierte CRLSet-Sperre, um Zertifikate zurückzuweisen, die mit den kompromittierten eMudhra-Zwischenschlüsseln verbunden waren. Entscheidend ist, dass diese Maßnahme auf die Identität des öffentlichen Schlüssels der Zertifizierungsstelle zielt und nicht nur auf die Seriennummer eines einzelnen Zertifikats. Dadurch kann der Browser betroffene Zertifikatsketten auch dann stoppen, wenn das präsentierte Zertifikat neu ausgestellt, ersetzt oder nicht einzeln aufgeführt ist. Unter Android nutzte Google außerdem Google Play Services, um den Schutz über den Browser hinaus auszuweiten. Die entsprechende Vertrauensentscheidung konnte so unterstützte Geräte über einen Plattformdienst erreichen, ohne dass jede Anwendung ihre eigene Zertifikatslogik ausliefern musste.

Firefox verfolgte ein ähnliches Ziel mit OneCRL, Mozillas Mechanismus zur Verteilung von Zertifikatswiderrufsentscheidungen an Firefox-Clients. Mozilla beschrieb außerdem Änderungen am Root-Store, die an einer breiteren Vertrauensgrenze ansetzen: Statt nur Zertifikate abzulehnen, die unterhalb eines bestimmten Zwischenzertifikats ausgestellt wurden, kann ein Client einer Root oder einem damit verbundenen Pfad insgesamt nicht mehr vertrauen. Diese Reichweite ist hilfreich, wenn dasselbe Ökosystem über unterschiedliche Zwischenzertifikate oder Cross-Signing-Konstellationen erreichbar ist. Sie erklärt aber auch, warum Vertrauensänderungen sorgfältig bewertet werden müssen. Ein Browser-Update kann die Gefährdung bei gewöhnlichen Websitzungen schließen, während andere Software dieselbe Zertifikatskette weiterhin anders bewertet.

Certificate Transparency half, das Zeitfenster für Clients zu begrenzen, die diese Funktion erzwingen, denn öffentlich vertrauenswürdige TLS-Zertifikate sollen einen prüfbaren Eintrag in öffentlichen Protokollen hinterlassen. Für einen durchsetzenden Client kann dieser Eintrag die Erkennung und Richtlinienentscheidungen zu Zertifikaten unterstützen, die nicht hätten ausgestellt oder denen nicht hätte vertraut werden dürfen. Er macht jedoch nicht jeden TLS-Verbraucher zu einem durchsetzenden Client. Prüfungen durch Certificate Transparency, Widerrufsmechanismen und Aktualisierungen von Trust-Stores sind voneinander getrennte Kontrollen. Eine Anwendung kann einige davon, keine davon oder eine interne Variante implementieren, die sich anders verhält als ein aktueller Browser.

Deshalb sollte die Aussage „Browser-Nutzer waren geschützt“ nicht als „alle Systeme, die TLS verwenden, waren geschützt“ verstanden werden. Ein Browser erhält normalerweise vom Anbieter verwaltete Richtlinien- und Trust-Store-Updates. Ein Unternehmen kann jedoch zusätzlich auf Zertifikatspakete des Betriebssystems, eingebettete Anwendungsspeicher, Java- oder andere Laufzeitpakete, Netzwerkgeräte, TLS-Inspektionssysteme, Container-Images und eigenständige Bibliotheken angewiesen sein. Diese Komponenten aktualisieren sich möglicherweise nach unterschiedlichen Zeitplänen oder erfordern, dass ein Administrator ein Paket direkt ersetzt. Manche Anwendungen führen eigene Widerrufsprüfungen durch, andere verlassen sich auf das Host-Betriebssystem. Ein Dienst, der den aktualisierten Store nicht verwendet, kann weiterhin eine Kette aufbauen, die ein aktueller Browser ablehnt.

Der Fehlerfall kann auch in die entgegengesetzte Richtung laufen. Ein Client kann zwar über eine Widerrufsfunktion verfügen, eine nicht verfügbare Antwort aber als akzeptabel behandeln oder die Prüfung bei einem Fehler offen fortsetzen. Die Existenz eines Widerrufssignals garantiert dann keine Durchsetzung. Lokale Richtlinien, Netzwerkerreichbarkeit, zwischengespeicherte Entscheidungen und das Verhalten der Anwendung spielen sämtlich eine Rolle. Dasselbe gilt für Geräte, die TLS beenden oder inspizieren: Der Browser am Endpunkt kann aktuell sein, während das zwischengeschaltete Gerät weiterhin einen älteren Vertrauensbestand hält und aufgrund seiner eigenen Konfiguration Ketten akzeptiert oder erzeugt.

Für IT-Teams besteht die praktische Unterscheidung daher zwischen vom Anbieter gesteuertem Browserschutz und lokal gesteuerten Vertrauensentscheidungen. Chromes CRLSet-Reaktion, die Schutzmaßnahmen von Google Play Services, Firefox’ OneCRL-Aktion und Änderungen am Root-Store senken das Risiko für Clients, die diese Maßnahmen erhalten und durchsetzen. Sie beweisen jedoch nicht, dass jedes zertifikatsverarbeitende Element einer IT-Flotte denselben Schutzumfang besitzt. Die entscheidende Frage lautet nicht nur, ob die Nutzer aktualisierte Browser haben, sondern ob das Unternehmen die Software und Geräte identifiziert hat, die separate Trust-Stores verwalten, eigene Widerrufsprüfungen durchführen oder den Betrieb fortsetzen, wenn diese Prüfungen scheitern.

Die betrieblichen Störungen, auf die sich IT-Teams einstellen müssen

Einer kompromittierten Zertifizierungsstelle das Vertrauen zu entziehen, ist für Clients, die die Änderung durchsetzen können, notwendig – operativ bleibt das jedoch nicht folgenlos. Google weist darauf hin, dass das Entfernen von emSign ECC Root CA - G3 legitime Zertifikate unbrauchbar machen kann, die weiterhin von dieser Root-CA oder einer verwandten Zertifikatskette abhängen. Auch Mozillas Analyse nennt mehrere betroffene Root- und Cross-Signing-Pfade. Für IT-Teams lautet die praktische Frage daher nicht einfach, ob ein Browser ein Zertifikat als vertrauenswürdig meldet. Entscheidend ist, ob ein Geschäftsdienst, ein Prüfgerät, ein Softwarepaket oder ein Validierungsprozess noch von einem Pfad abhängt, dem das Vertrauen demnächst entzogen wird.

Websites sollten als eine Bestandskategorie betrachtet werden, nicht als Stellvertreter für die gesamte Flotte. Ein öffentlich erreichbarer Dienst kann ein Zertifikat über eine Kette ausliefern, deren Aktualisierung Browser zeitnah übernehmen, während ein interner Dienst, ein veralteter Endpunkt oder ein Nicht-Browser-Client diese Kette weiterhin anders aufbaut. Dasselbe gilt für Server: Ein Server kann für eingehende Verbindungen korrekt konfiguriert sein und bei ausgehenden Verbindungen trotzdem noch von einem betroffenen Zertifikat abhängen. Die Zertifikatserfassung sollte deshalb sowohl die von eigenen Diensten präsentierten Zertifikate als auch die von den sie betreibenden Systemen vertrauten Zertifikate abdecken.

TLS-Inspektion bringt ein weiteres Fehlerbild mit sich. Netzwerkgeräte und Unternehmens-Proxys beenden eine Verbindung häufig, prüfen sie und bauen im Namen des Nutzers eine zweite Verbindung auf. Verfügt ein Gerät über einen eigenen Truststore, ein eingebettetes Zertifikats-Bundle oder eine vom Anbieter verwaltete Validierungslogik, ändert ein Browser-Update auf dem Endpunkt möglicherweise nichts daran, wie das Gerät die betroffene Kette bewertet. Umgekehrt kann das Ersetzen oder Entfernen eines von einem Inspektionssystem verwendeten Zertifikats den Datenverkehr vieler Nutzer gleichzeitig unterbrechen. Inspektions-Gateways, Load-Balancer und andere Vermittler sollten als eigenständige Vertrauensverbraucher geprüft werden. Ihre Konfiguration und Update-Mechanismen sind getrennt von denen der Endpunkt-Browser zu dokumentieren.

Container-Images und Anwendungsumgebungen schaffen eine ähnliche Trennung zwischen Betriebssystem und Workload. Ein Image kann ein paketbasiertes CA-Bundle enthalten, das unverändert bleibt, nachdem der Host ein Update erhalten hat. Auch Java-Installationen und andere Anwendungen mit eigenen Zertifikats-Bundles können weiterhin einen eingebetteten Truststore statt des Plattform-Stores verwenden. Damit werden Image, Laufzeitumgebung und Anwendungs-Bundle zu getrennten Bestandsfragen. Teams sollten ermitteln, welche Dienste das Vertrauen vom Host übernehmen, welche Zertifikate in das Image kopieren und welche ein eigenes Bundle pflegen, das über den jeweiligen Release-Prozess der Anwendung aktualisiert werden muss.

Die Validierung von Codesignaturen muss unabhängig von HTTPS geprüft werden. Zu den kompromittierten eMudhra-Intermediate-CAs gehören neben TLS-Intermediates auch solche für Codesignaturen. Eine auf Browser ausgerichtete Reaktion belegt daher nicht, dass die Pfade zur Softwarevalidierung überprüft wurden. Build-Systeme, Endpoint-Security-Tools, Paketmanager und andere Systeme, die Signaturen validieren, können andere Root-CAs, Intermediates oder ein anderes Sperrverhalten verwenden. Außerdem können sie Richtlinien zu einem anderen Zeitpunkt anwenden als ein Browser oder der Truststore des Betriebssystems. Die relevante Frage ist nicht, ob eine Workstation ein Browser-Update erhalten hat, sondern ob jedes System, das signierte Software akzeptiert, die betroffenen Signaturpfade bewertet hat.

Das Risiko von Ausfällen ist dort am größten, wo Vertrauen dupliziert, eingebettet oder über Geräte vermittelt wird. Eine umfassende Entfernung kann für Clients, die die neue Richtlinie beachten, einen kompromittierten Pfad schließen. Dieselbe Änderung kann jedoch einen legitimen Dienst unzugänglich machen, wenn dessen Zertifikatskette noch nicht ersetzt wurde. Eine eng begrenzte Reaktion kann die Verfügbarkeit erhalten und gleichzeitig nicht verwaltete Clients offenlassen. Dieser Zielkonflikt spricht dafür, Abhängigkeiten vor Änderungen in der gesamten Flotte zu erfassen: Zertifikat, Kette, Truststore, validierende Komponente und betroffenen Geschäftsdienst dokumentieren und anschließend das Ergebnis in der Umgebung testen, die die Validierung tatsächlich durchführt.

Für heterogene Umgebungen sollte „aktualisiert“ daher mehr bedeuten als eine aktuelle Browserversion. Gemeint sein sollte, dass die relevanten Website-Zertifikatsketten, Serverkonfigurationen, Inspektions-Appliances, Container- und Java-Truststores, Anwendungspakete sowie Prüfer für Codesignaturen berücksichtigt wurden. Wenn eine Änderung am Root-Store legitime Zertifikate beeinträchtigen könnte, sollten Teams sie schrittweise einführen und einen mit getesteten Dienstabhängigkeiten verknüpften Rollback-Plan bereithalten. Ziel ist ein kontrollierter Vertrauensentzug: Abhängigkeiten von kompromittierten Pfaden entfernen und zugleich einen klaren, belegbaren Weg zur Wiederherstellung des Dienstes offenhalten, falls eine legitime Kette übersehen wurde.

Ein belastbarer Reaktionsplan für heterogene Umgebungen

Am sichersten ist es, den eMudhra-Vorfall als Übung zur Prüfung von Truststores und Zertifikatsbeständen zu behandeln – nicht als reine Browser-Patch-Aufgabe. Zunächst sollte ermittelt werden, an welchen Stellen die betroffenen eMudhra-Intermediate-Zertifikate und ihre übergeordneten Root-Zertifikate in der Umgebung als vertrauenswürdig gelten: auf verwalteten Arbeitsstationen, Servern, in Containern, Java- und Anwendungsbundles, Netzwerk-Appliances, TLS-Inspektionsgeräten, Mobilgeräten sowie in Build- oder Signatursystemen. Die entscheidende Frage lautet nicht nur, ob ein Browser aktuell ist. Es geht darum, ob eine geschäftskritische Verbindung, Validierungsbibliothek, Appliance oder ein Workflow für signierte Software weiterhin eine Zertifikatskette akzeptieren kann, die nicht mehr vertrauenswürdig sein sollte.

Die Hinweise der Hersteller sollten den ersten Kontrollpunkt bilden. Die relevanten Updates für Chrome, Firefox, Android, Ubuntu und andere Pakete werden über den normalen Änderungsprozess eingespielt. Anschließend sollte auf repräsentativen Systemen geprüft werden, ob die erwartete Änderung am Truststore oder an der Sperrprüfung tatsächlich vorhanden ist. Das Ubuntu-Update für ca-certificates ist besonders wichtig für Systeme, die auf das von der Distribution bereitgestellte Vertrauenspaket zurückgreifen. Browser und Anwendungen mit eigenen Stores müssen dagegen separat geprüft werden. Für jede unterstützte Plattform sollten Paket- oder Browserversion, Aktualisierungsstatus und Zustand des Truststores dokumentiert werden. So hat „gepatcht“ eine überprüfbare Bedeutung und wird nicht allein aus dem letzten Gerätekontakt abgeleitet.

Danach werden Zertifikate und Validierungspfade erfasst. Zertifikatsinventare, Konfigurationen von Load-Balancern und Webservern, Service Meshes, Container-Images, Java-Keystores, Anwendungsbundles, Inspektionsprofile und Appliance-Richtlinien sollten nach den betroffenen eMudhra-Intermediate-Zertifikaten und zugehörigen Roots durchsucht werden. Bei kundenorientierten Zertifikaten muss die vollständige Kette ermittelt werden, die tatsächlich von jedem Endpunkt ausgeliefert wird. Ein Zertifikat kann in einem Browser gültig sein, während ein anderer Client, Proxy oder eine serverseitige Bibliothek einen anderen Pfad verwendet. Bei intern ausgestelltem oder inspiziertem Datenverkehr sind beide Seiten der Verbindung zu prüfen: die Vertrauenseinstellungen des Inspektionsgeräts und der Client-Truststore, der das neu signierte Zertifikat erhält. Die Prüfung von Codesignaturen sollte getrennt von der TLS-Analyse erfolgen, denn ein Signaturzertifikat kann die Verteilung und Ausführung von Software beeinflussen, auch wenn kein Webbrowser beteiligt ist.

Der Austausch sollte vor der für den 27. Oktober geplanten Änderung im Chrome Root Store erfolgen. Jedes Kundenzertifikat, das von einem betroffenen Pfad abhängt, sollte neu ausgestellt oder durch ein Zertifikat mit einer Kette ersetzt werden, die weder von den kompromittierten Intermediate-Zertifikaten noch von einem Root-Zertifikat abhängt, dessen Vertrauen entzogen werden soll. Die Einführung erfolgt kontrolliert und schrittweise. Das operative Ziel ist, die riskante Abhängigkeit zu beseitigen, bevor Clients den neuen Zustand erzwingen – nicht erst auf Verbindungsfehler zu warten, die einen übersehenen Dienst sichtbar machen. Der Zertifikatsaustausch muss die ausgelieferte Kette, die Bereitstellung der Intermediate-Zertifikate, die Erneuerungsautomatisierung sowie alle fest verankerten oder ausdrücklich konfigurierten Vertrauensbeziehungen einschließen, die verhindern könnten, dass die neue Kette akzeptiert wird.

Die Tests müssen auch Pfade abdecken, die bei normalen Browserprüfungen unberücksichtigt bleiben. Dafür sollte eine kleine, aber repräsentative Matrix geschäftskritischer Websites, APIs, ausgehender Integrationen, Administrationskonsolen, Inspektionsrouten, containerisierter Dienste, Java-Anwendungen, mobiler Abläufe sowie Signatur- und Update-Prozesse für Software erstellt werden. Getestet werden sollte aus verwalteten und nicht verwalteten Netzwerksegmenten, sofern beide im Geltungsbereich liegen, und mit den aktualisierten Truststores und Browserversionen, die die Produktivsysteme erhalten werden. Ein erfolgreich geladener Webauftritt ist nur ein Ergebnis. Wo diese Funktionen relevant sind, sollten auch die Zertifikatskettenvalidierung, das Proxy-Verhalten, das Verhalten der Anwendungsbibliotheken sowie die Möglichkeit zur Installation oder Validierung signierter Software erfasst werden.

Da das Entfernen von Root-Zertifikaten legitime Zertifikate unbrauchbar machen kann, sollte die Aberkennung des Vertrauens schrittweise erfolgen, wenn sich die Umgebung nicht innerhalb eines Wartungsfensters vollständig bewerten lässt. Beginnen Sie mit der Bestandsaufnahme und der Ermittlung von Abhängigkeiten. Aktualisieren Sie anschließend eine kontrollierte Pilotgruppe, beobachten Sie Ausfälle und weiten Sie die Abdeckung aus, sobald die kritischen Pfade funktionieren. Hängt ein Dienst von einem abgelehnten Zertifikat ab, sollte der dokumentierte Austausch des dienstseitigen Zertifikats oder der Zertifikatskette die bevorzugte Rückfallmaßnahme sein. Ist eine vorübergehende Vertrauensausnahme unvermeidbar, muss sie als ausdrücklich beschlossene, zeitlich begrenzte Risikomaßnahme mit verantwortlicher Person und Löschdatum behandelt werden, statt das umfassende Vertrauen in der gesamten Flotte stillschweigend wiederherzustellen.

Bewahren Sie schließlich Nachweise auf, die sowohl die durchgeführten Maßnahmen als auch deren Abdeckung belegen: ermittelte betroffene Systeme, ersetzte Zertifikate, installierte Herstellerupdates, geprüfte Truststores, abgeschlossene Testfälle, genehmigte Ausnahmen und zugewiesene verbleibende Lücken. So lässt sich unterscheiden, ob tatsächlich keine Gefährdung vorliegt oder ein System lediglich nicht getestet wurde. Außerdem werden Nacharbeiten möglich, wenn weitere Pakete, Anwendungen oder Appliances eigene Hinweise zur Behebung veröffentlichen. Entscheidend ist nicht nur, dass die großen Browser ihr Verhalten geändert haben. Die Organisation muss zeigen können, wo Vertrauen durchgesetzt, wo es entzogen, welche Dienste getestet und wie die verbleibende Unsicherheit gesteuert wurde.