Ein eMudhra-Zertifikatsschlüssel war die Zahl 4, damit ließ sich jede Website fälschen

Der geheime Schlüssel hinter einem der Zertifikate, die die Identität einer Website bestätigen, stellte sich als die Zahl vier heraus. Keine lange Zufallszahl, die zufällig mit einer Vier beginnt, sondern schlicht die Vier. Sieben weitere Schlüssel derselben indischen Zertifizierungsstelle, eMudhra, waren kaum größer. Wer sie besitzt, kann ein Zertifikat für jede beliebige Website ausstellen – von einer Bank bis zu einem E-Mail-Anbieter –, das jede Software, die eMudhra vertraut, als echt akzeptiert.

Diese Zertifikate werden von der Schlossanzeige im Browser überprüft. Mit einem gefälschten Zertifikat kann sich ein Angreifer, der sich zwischen Sie und das Internet schaltet – etwa im WLAN eines Cafés, über einen gehackten Router oder in einem feindseligen nationalen Netzwerk –, als echte Website ausgeben und mitlesen oder verändern, was Sie senden. Chrome, Firefox, Safari und die Plattformen von Microsoft vertrauen den acht Zertifikaten bereits nicht mehr. Auf Ihren Geräten gibt es jedoch reichlich andere Software, die das noch tut.

Ein gewöhnlicher Schlüssel dieses Typs ist eine zufällige Zahl mit etwa 384 Bit. Damit gibt es ungefähr 10 hoch 115 mögliche Kombinationen. Die Schlüssel von eMudhra waren zwischen 3 und 8 Bit lang: 4, 56, 66, 115, 155, 156, 230 und 237, wie Ars Technica sie auflistete. Der Sicherheitsforscher Scott Helme schrieb, er habe alle acht aus den öffentlichen Zertifikaten auf seinem Laptop ausgelesen – „und das dauerte weniger als eine Sekunde“. Später ergänzte er, dass auch Claude von Anthropic dasselbe mit einer einzigen Eingabeaufforderung geschafft habe.

Gestohlen werden musste dafür nichts. In seiner Stellungnahme gegenüber Mozilla, über die BleepingComputer berichtete, machte eMudhra einen Fehler im Skript verantwortlich, das bei der Zeremonie zur Schlüsselerzeugung verwendet wurde: Das Skript habe einen zweiten, schwachen Schlüsselsatz erstellt, und die Mitarbeitenden hätten versehentlich diesen ausgewählt, weil die Bezeichnungen ähnlich aussahen. Das Unternehmen, nach eigenen Angaben Anbieter von mehr als 60 Millionen digitalen Zertifikaten, teilte Mozilla mit, dass die meisten der betroffenen Zwischenzertifikate nie produktiv eingesetzt worden seien und es keine Hinweise darauf gebe, dass damit Zertifikate für Endnutzer signiert wurden. eMudhra hat alle acht widerrufen und die Ausstellung von Zertifikaten unter der betroffenen Stammzertifizierungsstelle eingestellt.

Bei Browsern ist die Sache einfach. Chrome, Firefox und Safari spielen Sperrlisten unbemerkt an ihre Nutzer aus und verlangen außerdem, dass jedes Zertifikat in öffentlichen Certificate-Transparency-Protokollen erscheint. Da dort kein Website-Zertifikat auftauchte, das auf diese Schlüssel zurückgeht, waren aktuelle Browser standardmäßig nie gefährdet. Die Lücke liegt überall sonst. Kommandozeilenwerkzeuge wie curl, Programmiersprachen wie Python, Node und Go, VPN-Clients, Docker-Container und Smart-Home-Geräte führen eigene Listen vertrauenswürdiger Zertifizierungsstellen mit sich, prüfen nur selten den Widerrufsstatus und ignorieren Transparenzprotokolle. Helme erstellte ein gefälschtes Zertifikat für die Zahlungs-API von Stripe und stellte fest, dass curl, Python und Node es auf jedem von ihm getesteten Linux- und macOS-Rechner akzeptierten.

„Das wird eine gewaltige Aufräumarbeit, größer als Heartbleed“, sagte Filippo Valsorda, Betreuer des Kryptografie-Codes der Programmiersprache Go, gegenüber Ars Technica. Er erinnerte dabei an die OpenSSL-Schwachstelle, deren Folgen jahrelang beseitigt werden mussten. Valsorda rechnet mit einem „sehr, sehr langen Nachlauf“ bei IoT-Geräten, Docker-Containern, vergessenen Linux-Rechnern und nicht mehr gepflegten Werkzeugen, die ihre eigenen Kopien der vertrauenswürdigen Stammzertifikate mitbringen. Um die Schlüssel auszunutzen, muss ein Angreifer weiterhin im Netzwerkpfad sitzen. Das liegt im Bereich der Möglichkeiten von Regierungen, eines kompromittierten Büronetzwerks oder der Betreiber eines öffentlichen Hotspots. Signal, WhatsApp und WireGuard sind nicht betroffen, da sie für ihre Verschlüsselung nicht auf diese Zertifikate angewiesen sind, wie Ars anmerkt.

Die Schlüssel ließen sich seit dem Tag wiederherstellen, an dem die Zertifikate im April 2025 erstellt wurden – über einen Zeitraum von etwa 17 Monaten. Es lässt sich nicht feststellen, ob jemand sie gegen Software eingesetzt hat, die die Transparenzprüfung überspringt. Außerdem wurden alle Zertifikate im Mai 2025 von der Stammzertifizierungsstelle AAA Certificate Services von Sectigo gegengezeichnet. Dadurch wuchs die Zahl der Systeme, die ihnen vertrauten.

Für die meisten Nutzer besteht die Lösung darin, Updates zu installieren. Ein Forscher meldete die Schlüssel den Browserherstellern am 17. Oktober. Mozilla sperrte die Zertifikate noch am selben Tag innerhalb von drei Stunden in Firefox. Am 20. Oktober veröffentlichte das Unternehmen Firefox 158.0.1, neue ESR-Versionen und NSS 3.131.1, das die eMudhra-Stammzertifizierungsstelle entfernt. Apple fügte den Schutz am 19. Oktober hinzu, Microsoft am 20. Oktober, wie aus der von Mozilla-Ingenieur Dennis Jackson betriebenen Website zum Vorfall hervorgeht. Ars stellte allerdings bei Veröffentlichung fest, dass Edge unter Windows 10 weiterhin eine Verbindung zu den Testservern herstellte. Go 1.27.3 und 1.26.10, pip 26.2.2, uv 0.13.4 und certifi 2026.10.19 sind erschienen. Cloudflare hat seine Apps WARP und 1.1.1.1 aktualisiert, und Linux-Distributionen liefern weiterhin neue Pakete mit ca-certificates aus. Das in macOS integrierte curl vertraut den Schlüsseln weiterhin, bis die Zertifikatsdatei von Hand bearbeitet wird.

Chrome hat bestätigt, dass die eMudhra-Stammzertifizierungsstelle mit Version 43 aus dem Chrome Root Store entfernt wird. Bis alle Geräte auf dem aktuellen Stand sind, trennen acht Bit einen großen Teil der Alltagssoftware von einer überzeugenden Fälschung jeder beliebigen Website.

Schlagwörter: Cybersicherheit, Mozilla, Firefox, eMudhra, Google Chrome, TLS-Zertifikate