Führende Browser-Anbieter und Cloud-Sicherheitsdienstleister haben Notfall-Sperren für acht Zwischenzertifikate für TLS eingerichtet, die von der indischen Zertifizierungsstelle eMudhra Limited ausgestellt wurden. Zuvor hatten Forschende festgestellt, dass das Verfahren zur Schlüsselgenerierung fehlerhaft und „trivial auszunutzen“ war. Mozilla zufolge konnte das Unternehmen die betroffenen privaten Schlüssel wiederherstellen, nachdem es über das Problem informiert worden war. Das zeigt, wie Angreifer sich möglicherweise als legitime Websites ausgeben könnten.

Der Vorfall erinnert daran, dass Fehler in der Public-Key-Infrastruktur (PKI) nicht auf einen einzelnen Browser beschränkt bleiben. Viele Organisationen haben zwar schnell Zertifikatssperren hinzugefügt, doch Mozilla warnt, dass das Risiko für Systeme und Anwendungen fortbestehen kann, die solche Aktualisierungen nicht automatisch übernehmen.

Wichtigste Erkenntnisse

• Mozilla zufolge könnten die fehlerhaften eMudhra-Zwischenzertifikate Man-in-the-Middle-Angriffe ermöglichen, bei denen sich Angreifer als legitime Websites ausgeben.

• Technologieunternehmen reagierten, indem sie die acht Zertifikate in wichtigen Browsern und Plattformen sperrten, darunter Firefox, Chrome, Apple-Geräte und Microsoft-Umgebungen.

• Mozilla setzte Schutzmaßnahmen über OneCRL um und veröffentlichte außerdem Browser-Updates, damit Nutzer die erforderlichen Abhilfemaßnahmen erhielten.

• Mozilla betont, dass es keine eindeutigen Hinweise auf aktive Angriffe auf Browser gibt. Clients außerhalb von Browsern könnten jedoch weiterhin gefährdet sein.

Warum die Schwachstelle bei den eMudhra-Zertifikaten wichtig ist

Laut Dennis Jackson, Kryptografie-Ingenieur bei Mozilla, gehen die problematischen Zertifikate auf einen Schlüsselgenerierungsprozess zurück, der „fehlerhaft“ und „trivial auszunutzen“ war. In einem Vorfallbericht schreibt Jackson, Mozilla habe die privaten Schlüssel kurz nach dem ersten Hinweis am Samstag unabhängig rekonstruiert. Das half, die zugrunde liegende Schwachstelle zu bestätigen.

Kann ein Angreifer die Verbindung eines Nutzers abfangen, könnte er gefälschte Zertifikate vorlegen und sich so als echte Website ausgeben. Mozilla erklärt, dass Angreifer dadurch Informationen lesen oder verändern könnten, die während der Sitzung ausgetauscht werden. Das hängt davon ab, wie der Angriff ausgeführt wird und welche Schutzmaßnahmen in der Zielumgebung gelten.

Diese potenziellen Folgen sind der Hauptgrund für die raschen Notfallmaßnahmen in den Vertrauensspeichern: Das Vertrauen in Zertifikate bildet die Grundlage dafür, dass Browser und viele Client-Anwendungen entscheiden können, ob ein Endpunkt echt ist.

Wie der Schutz in Browsern und auf Plattformen eingeführt wurde

Das Sicherheitsteam von Firefox erklärte, es habe den Bericht am Samstag erhalten und umgehend damit begonnen, die betroffenen Zwischenzertifikate in Firefox mithilfe von OneCRL zu sperren. Diese Arbeit wurde noch am selben Tag abgeschlossen. Anschließend veröffentlichte Mozilla Updates für Firefox auf Desktop- und Android-Geräten.

Mozilla wies außerdem darauf hin, dass die Updates spezielle Einstellungen enthielten, damit bestimmte Nutzer die OneCRL-Schutzmaßnahme nicht verpassten. Das ist bedeutsam, denn bei der Sperrung von Zertifikaten geht es nicht nur darum, ob eine Sperre existiert, sondern auch darum, ob die Konfigurationen der Clients die Änderungen rechtzeitig übernehmen.

Cloudflare, das ebenfalls Sicherheitsinfrastruktur für den Webverkehr betreibt, berichtete, am Montag von dem Problem erfahren zu haben. Am Dienstag veröffentlichte das Unternehmen Updates für Cloudflare One und WARP Clients sowie für Cloudflare Tunnel und führte außerdem Schutzmaßnahmen für damit verbundene Dienste ein.

Jackson erklärte ferner, dass die Zertifikate seit Samstag in Chrome, seit Montag auf Apple-Geräten und seit Dienstag auf Microsoft-Plattformen gesperrt seien. Mit anderen Worten: Mehrere Vertrauenssysteme gingen innerhalb weniger Tage von der Erkennung zur Durchsetzung der Sperren in ihren Vertrauensspeichern über.

Was über eine mögliche Ausnutzung bekannt ist – und was unklar bleibt

Jackson sagte, es gebe keine Hinweise darauf, dass Firefox, Chrome, Edge oder Safari auf diese Weise angegriffen worden seien. Er verwies darauf, dass seit April 2025 keine Einträge zu den Zwischenzertifikaten in den Certificate-Transparency-Protokollen aufgetaucht seien.

Der Mozilla-Ingenieur warnte jedoch auch, dass viele Clients außerhalb des Browser-Ökosystems Certificate Transparency nicht durchsetzen. Das Fehlen von Protokolleinträgen beseitigt das Risiko daher nicht vollständig – Angreifer könnten weiterhin Systeme ins Visier nehmen, die andere Validierungsverfahren verwenden.

In derselben Diskussion über den Vorfall sagte Jackson, viele nachgelagerte Clients führten nicht dieselben Transparenzprüfungen durch, und „wir wissen nicht, ob Angreifer die fehlerhafte Schlüsselgenerierung ausgenutzt haben, um diese Clients ins Visier zu nehmen“. Für Unternehmen verdeutlicht dies eine verbreitete Asymmetrie bei PKI-Systemen: Browser bieten möglicherweise stärkere Schutzmechanismen, während benutzerdefinierte Clients, eingebettete Systeme und veraltete Unternehmenskomponenten dies nicht unbedingt tun.

Lehren aus früheren Vorfällen mit Zertifizierungsstellen

Die Reaktion auf den eMudhra-Vorfall erinnert an frühere Fehler bei Vertrauensspeichern – insbesondere an den DigiNotar-Einbruch von 2011. Damals kompromittierten Angreifer eine Zertifizierungsstelle und stellten Hunderte gefälschte SSL-Zertifikate aus, wodurch sie sich als Nutzer ausgeben und diese überwachen konnten.

Der aktuelle Vorfall betrifft zwar andere Zertifikate und hat einen anderen Ursprung, doch die praktische Lehre ist ähnlich: Werden die Schlüssel einer Zertifizierungsstelle falsch gehandhabt oder fehlerhaft erzeugt, können Angreifer möglicherweise glaubwürdige Zertifikate erstellen, die einfache Schutzmaßnahmen umgehen.

Mozillas Hinweis darauf, dass Sperren möglicherweise nicht automatisch überall übernommen werden, ist besonders für Unternehmensumgebungen relevant. Dort können interne Proxys, spezialisierte Clients und private Anwendungsumgebungen anders funktionieren als gängige Browser.

Leser sollten nun darauf achten, ob bestätigt wird, dass die gesperrten Zertifikate vollständig aus den Vertrauensspeichern aller wichtigen Clients entfernt wurden. Ebenso wichtig sind Hinweise dazu, in welchem Umfang Clients außerhalb von Browsern betroffen sein könnten, die Certificate Transparency möglicherweise nicht nutzen. Die längerfristige Herausforderung betrifft weniger die Browser – die größtenteils bereits geschützt sind – als vielmehr alle Systeme, deren Vertrauensentscheidungen nicht automatisch aktualisiert werden, wenn Zertifikatssperren veröffentlicht werden.

Dieser Artikel wurde ursprünglich unter dem Titel „Tech-Giganten sperren acht mit gefälschten Websites in Verbindung gebrachte eMudhra-Zertifikate“ auf Crypto Breaking News veröffentlicht – Ihrer vertrauenswürdigen Quelle für Kryptonachrichten, Bitcoin-Nachrichten und Blockchain-Updates.