eMudhra-Zertifikate kompromittiert: Browserhersteller reagieren

Ein Fehler bei der Zertifizierungsstelle eMudhra sorgt derzeit für Aufsehen in der IT-Sicherheitswelt. Acht sogenannte Intermediate-Zertifikate mussten widerrufen werden, nachdem Forscher festgestellt hatten, dass deren private Schlüssel praktisch keinen nennenswerten Schutz boten.

Das Problem ist durchaus bemerkenswert: Die verwendeten P-384-Schlüssel waren so schwach erzeugt worden, dass sich die privaten Schlüssel mit gerade einmal 256 möglichen Werten durchprobieren ließen.

Bei einem der Zertifikate hatte der private Schlüssel sogar schlicht den Wert 4.

Mozilla, Google und Apple haben inzwischen reagiert und die betroffenen Zertifikate blockiert.

Was ist überhaupt passiert?

Entdeckt wurde das Problem am 17. Oktober 2026 von einem Sicherheitsforscher unter dem Namen Wayne bei der Analyse öffentlich verfügbarer Zertifikatsdaten.

Betroffen sind acht Intermediate-Zertifikate von eMudhra, deren Schlüssel im April 2025 erzeugt worden waren.

Normalerweise basiert die Sicherheit solcher Zertifikate darauf, dass der private Schlüssel praktisch unmöglich zu erraten oder zu berechnen ist.

In diesem Fall war genau das nicht gegeben.

Die erzeugten Schlüssel hatten Werte unter 256.

Damit musste ein Angreifer schlimmstenfalls nur wenige hundert Möglichkeiten ausprobieren.

Für moderne Kryptografie ist das ungefähr so, als würde man einen Hochsicherheitstresor mit einem Vorhängeschloss aus dem Baumarkt sichern.

Ein privater Schlüssel hatte den Wert 4

Wie extrem das Problem tatsächlich war, zeigte der Sicherheitsforscher Flüpke.

Er veröffentlichte einen der betroffenen privaten Schlüssel als Nachweis.

Der private Schlüssel des Intermediate-Zertifikats „EM OV TLS CA - G3C“ hatte demnach den Wert:

4

BleepingComputer konnte laut Bericht bestätigen, dass dieser Schlüssel tatsächlich zu einem der widerrufenen Zertifikate gehört.

Das ist natürlich alles andere als das, was man bei einem kryptografischen Schlüssel einer Zertifizierungsstelle erwartet.

Warum das so gefährlich ist

Intermediate-Zertifikate befinden sich in der Vertrauenskette zwischen einer Root-CA und den eigentlichen Zertifikaten von Webseiten oder Diensten.

Besitzt jemand den privaten Schlüssel einer solchen Intermediate-CA, kann das theoretisch sehr weitreichende Folgen haben.

Ein Angreifer könnte damit unter Umständen gefälschte Zertifikate erstellen, die von betroffenen Systemen trotzdem als vertrauenswürdig angesehen werden.

Dadurch wären beispielsweise Angriffe denkbar, bei denen sich ein Angreifer gegenüber einem Nutzer als legitime Webseite ausgibt oder verschlüsselte Verbindungen abfängt.

Wichtig ist allerdings die Einschränkung:

Bislang gibt es laut eMudhra keine Hinweise darauf, dass die schwachen Schlüssel tatsächlich für solche Angriffe verwendet wurden.

Das Risiko war vorhanden. Ein nachgewiesener Missbrauch ist nach aktuellem Stand aber nicht bekannt.

Fehler in einem Skript war offenbar die Ursache

eMudhra erklärte gegenüber Mozilla, wie es zu der Panne kommen konnte.

Demnach wurde im April 2025 ein Skript verwendet, um die Zertifikate beziehungsweise die zugehörigen Schlüssel zu erzeugen.

Dabei entstand versehentlich ein zweiter Satz schwacher Schlüssel.

Diese hätten offenbar ähnliche Bezeichnungen wie die korrekt erzeugten Schlüssel besessen.

Bei der späteren Signierung wurden dann versehentlich die falschen Schlüssel ausgewählt.

Ein klassisches Beispiel dafür, wie ein zunächst klein wirkender Fehler in einer automatisierten Infrastruktur enorme Auswirkungen haben kann.

Einige Zertifikate wurden zusätzlich von Sectigo signiert

Ein Teil der betroffenen Intermediate-Zertifikate wurde außerdem bei Sectigo zum sogenannten Cross-Signing eingereicht.

Dadurch konnten die Zertifikate über zusätzliche Vertrauensketten akzeptiert werden.

eMudhra erklärt allerdings, dass die meisten betroffenen Intermediate-Zertifikate nicht produktiv eingesetzt worden seien.

Außerdem habe das Unternehmen bislang keine Hinweise gefunden, dass damit Zertifikate für Endnutzer ausgestellt wurden.

Trotzdem bestand das Problem seit April 2025.

Damit waren die schwachen Schlüssel theoretisch rund anderthalb Jahre lang rekonstruierbar.

eMudhra widerruft alle acht Zertifikate

Nach Bekanntwerden des Problems hat eMudhra die acht betroffenen Intermediate-Zertifikate widerrufen.

Zusätzlich wurde die Ausstellung neuer Zertifikate unter der betroffenen G3-Root vorerst gestoppt.

Damit ist das grundlegende Problem auf Seiten der Zertifizierungsstelle zunächst eingedämmt.

Entscheidend ist jetzt allerdings, dass Betriebssysteme, Browser, Programmiersprachen und andere Software die kompromittierten Zertifikate auch tatsächlich nicht mehr akzeptieren.

Und genau dort liegt der zweite Teil der Geschichte.

Mozilla reagierte noch am selben Tag

Mozilla blockierte die kompromittierten Zertifikate bereits am 17. Oktober 2026 über das sogenannte OneCRL-System von Firefox.

Der Vorteil dabei:

Nutzer mussten dafür weder ein komplettes Browser-Update installieren noch Firefox neu starten.

Die Sperrinformation konnte separat verteilt werden.

Am 20. Oktober veröffentlichte Mozilla zusätzlich Firefox 158.0.1 sowie entsprechende Updates für die ESR-Versionen.

Diese sollen auch Systeme schützen, die aus bestimmten Gründen die vorherige OneCRL-Aktualisierung nicht erhalten konnten.

Google und Apple blockieren die Zertifikate ebenfalls

Auch Google reagierte am 17. Oktober.

Chrome blockierte die sechs kompromittierten Intermediate-Zertifikate, die tatsächlich zur Ausstellung von TLS-Zertifikaten berechtigt waren.

Apple ergänzte entsprechende Schutzmaßnahmen am 19. Oktober 2026.

Damit dürften die meisten normalen Browsernutzer inzwischen geschützt sein.

Ganz erledigt ist das Problem damit allerdings noch nicht.

Nicht jede Software verwendet den Zertifikatsspeicher des Systems

Und genau dieser Punkt ist besonders wichtig.

Viele Programme verwenden nicht automatisch den Zertifikatsspeicher des Betriebssystems oder eines Browsers.

Manche Anwendungen bringen ihren eigenen CA-Speicher mit.

Andere prüfen Widerrufsinformationen möglicherweise überhaupt nicht oder nur eingeschränkt.

Dadurch können einzelne Programme die kompromittierten Intermediate-Zertifikate theoretisch weiterhin akzeptieren, obwohl Firefox oder Chrome sie bereits blockieren.

Das betrifft insbesondere Entwicklungsumgebungen, Programmiersprachen, Container oder Software mit eigenen CA-Paketen.

Zahlreiche Projekte veröffentlichen Updates

Inzwischen wurden bereits mehrere Softwarepakete angepasst.

Unter anderem stehen Aktualisierungen für folgende Komponenten bereit:

Bei anderen Projekten wie Debian, FreeBSD, Node.js oder Bun waren die entsprechenden Aktualisierungen zum Zeitpunkt des Berichts noch nicht abgeschlossen.

Für die Go-Implementierung wird das Problem als CVE-2026-111943 geführt.

Auch macOS hat eine Besonderheit

Interessant ist außerdem ein Hinweis des Mozilla-Kryptografieentwicklers Dennis Jackson.

Demnach könnte das in macOS integrierte:

/usr/bin/curl

unter bestimmten Umständen die kompromittierten Zertifikate weiterhin akzeptieren.

Der Grund liegt offenbar darin, wie dort Zertifikate beziehungsweise Widerrufsinformationen geprüft werden.

Das zeigt ziemlich gut, warum eine Sperre in Chrome oder Firefox allein nicht automatisch bedeutet, dass jede Anwendung auf dem Rechner geschützt ist.

Administratoren sollten Updates nicht aufschieben

Für normale Anwender dürfte vor allem eines wichtig sein:

Browser und Betriebssystem aktuell halten.

Administratoren sollten zusätzlich prüfen, ob auf Servern, Entwicklungsumgebungen oder Containern eigene CA-Bundles verwendet werden.

Besonders relevant sind Anwendungen, die:

• eigene Zertifikatsspeicher mitbringen
• alte CA-Bundles verwenden
• Widerrufsinformationen nicht auswerten
• Zertifikate unabhängig vom Betriebssystem validieren

Für den Vorfall gibt es inzwischen auch spezielle Testendpunkte, mit denen sich prüfen lässt, ob ein System die problematischen Zertifikate noch akzeptiert.

Der Fall zeigt, wie viel Vertrauen in Zertifizierungsstellen steckt

Ich finde den Vorfall vor allem deshalb interessant, weil er zeigt, wie zentral Zertifizierungsstellen für die Sicherheit des Webs sind.

Beim Besuch einer HTTPS-Webseite verlassen wir uns darauf, dass der Browser die Identität der Seite zuverlässig überprüfen kann.

Dahinter steckt eine ganze Kette von Zertifikaten und Vertrauensstellen.

Wenn irgendwo in dieser Kette ein privater Schlüssel kompromittiert wird, kann das Auswirkungen weit über eine einzelne Webseite hinaus haben.

Und in diesem Fall musste der Schlüssel nicht einmal aufwendig gestohlen werden.

Man konnte ihn praktisch erraten.

Ein kryptografischer Schlüssel sollte nicht erratbar sein

Das klingt selbstverständlich, ist aber eigentlich die Kernaussage des ganzen Vorfalls.

P-384 gehört zu den etablierten Verfahren für elliptische Kurven und bietet bei korrekter Implementierung sehr hohe Sicherheit.

Das hilft allerdings nichts, wenn der tatsächlich erzeugte private Schlüssel aus einer winzigen Menge möglicher Zahlen stammt.

Die Kryptografie selbst war hier also nicht gebrochen.

Die Schlüsselerzeugung war fehlerhaft.

Das ist ein wichtiger Unterschied.

Ein starkes Verfahren kann nur so sicher sein wie seine konkrete Implementierung.

Mein Eindruck

Dass ein Intermediate-CA-Schlüssel am Ende den Wert 4 besitzt, ist schon ziemlich bemerkenswert.

Gleichzeitig zeigt der Vorfall positiv, dass die Reaktionsmechanismen des Ökosystems grundsätzlich funktioniert haben.

Der Fehler wurde entdeckt.

Die Zertifikate wurden widerrufen.

Mozilla, Google und Apple reagierten schnell.

Verschiedene Softwareprojekte veröffentlichten Aktualisierungen.

Trotzdem bleibt natürlich die unangenehme Frage, ob jemand die Schwäche zwischen April 2025 und Oktober 2026 bereits entdeckt und ausgenutzt hat.

Dafür gibt es bislang keine Hinweise.

Ganz ausschließen lässt sich ein vergangener Missbrauch allein dadurch aber natürlich nicht.

Fazit

Die Zertifizierungsstelle eMudhra musste acht Intermediate-Zertifikate widerrufen, deren private Schlüssel aufgrund einer fehlerhaften Erzeugung extrem schwach waren.

Die Schlüssel lagen in einem Wertebereich von weniger als 256 Möglichkeiten.

Bei einem öffentlich demonstrierten Zertifikat lautete der private Schlüssel sogar schlicht:

4

Dadurch hätten die Schlüssel praktisch ohne Aufwand rekonstruiert und möglicherweise zur Ausstellung gefälschter vertrauenswürdiger Zertifikate verwendet werden können.

Bislang gibt es allerdings keine Hinweise auf einen tatsächlichen Missbrauch.

Mozilla, Google und Apple haben die kompromittierten Zertifikate inzwischen blockiert. Auch zahlreiche andere Softwareprojekte stellen aktualisierte Zertifikatsspeicher bereit.

Für Nutzer und Administratoren gilt deshalb vor allem:

Updates installieren – besonders bei Software, die ihren eigenen Zertifikatsspeicher verwendet.

Der Vorfall zeigt ziemlich eindrucksvoll, dass selbst starke Kryptografie wenig hilft, wenn bei der Schlüsselerzeugung am Ende eine Zahl herauskommt, die man an zwei Händen abzählen könnte.

Quellen

BleepingComputer:
Mozilla, Google, Apple block compromised eMudhra CA certificates
https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Mozilla Bugzilla – eMudhra Incident Report:
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Mozilla Security Blog:
https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/

Incident-Übersicht und Testmöglichkeiten:
https://emudhra.we-have-a-problem.com/

Go Security Update:
https://groups.google.com/g/golang-announce/c/66pojueaQek