Bei der niederländisch-indischen Zertifizierungsstelle (CA, Certification Authority) eMudhra sind nicht weniger als acht ihrer CA-Zertifikate nebst der privaten Schlüssel kompromittiert. Angreifer konnten diese nutzen, um sich TLS-Zertifikate für beliebige Domains, etwa q3k.google.com, auszustellen. Die großen Browserhersteller haben die Zertifikate gesperrt; für Endanwender bestand wohl keine Gefahr.

Der Vorfall wurde den Browserherstellern Mozilla und Chrome am 17. Oktober gegen 18 Uhr deutscher Zeit von einem „Mitglied der Community“ gemeldet. Die acht kompromittierten Zertifikate sind „Intermediate Certificates“, stehen also in der TLS-Zertifikatshierarchie zwischen dem Wurzelzertifikat und dem „End-Entity-Zertifikat“, das etwa für eine Domain wie q3k.google.com ausgestellt wurde. Durch Intermediate- oder Zwischenzertifikate können CAs bestimmte Geschäftszweige und Validierungsmethoden voneinander abkapseln oder den Umstieg auf neue kryptografische Techniken wie ECC vereinfachen. Sie erhalten von Browsern durch ihre Verbindung zum Wurzelzertifikat dasselbe Vertrauen wie dieses.

Wie mehrere Sicherheitsforscher und der Autor dieser Meldung im Laufe des Dienstagabends herausfanden, ist der Grund für den Vorfall so trivial wie peinlich: eMudhra hatte leicht zu erratende Werte für die privaten Schlüssel gewählt, die beim gewählten Verfahren EC-384 die Position auf einer elliptischen Kurve darstellen. Alle acht Werte sind Zahlen zwischen 0 und 255; die Länge der privaten Schlüssels beträgt also jeweils lediglich 8 Bit. Einer der privaten Schlüssel lautete schlicht „4“.

Dass eMudhra das private Schlüsselmaterial für gleich acht dieser Zertifikate auf derart unsichere Weise erstellte, wirft ein ungünstiges Licht auf die CA. Zertifizierungsstellen sind mit gutem Grund durch die strengen „Baseline Requirements“ des CA-Browser Forums (CA/B) zu sehr rigiden Sicherheits- und Compliance-Prozessen verpflichtet, um derlei Vorfälle zu vermeiden.

Screenshot des gefälschten Zertifikats für q3k.google.com beim Aufruf mit curl

Mit dem Kommandozeilenwerkzeug curl kann man noch TLS-Verbindungen zu einem Demonstrator aufbauen, indem man die Domain q3k.google.com aufruft, den Aufruf aber unter Umgehung des DNS (Domain Name System) an eine bestimmte Ziel-IP bindet: curl https://q3k.google.com --resolve 'q3k.google.com:443:135.181.235.221'. Auf dieser IP-Adresse im Netz des Hosters Hetzner lauscht ein Webserver, der eine Testseite ausgibt und dabei ein am 20. Oktober für Google ausgestelltes Zertifikat präsentiert.

Der Demonstrator zeigt zum einen, dass der Sicherheitsforscher mit dem Alias „q3k“ offenbar im Besitz eines der Intermediate-Zertifikate nebst Schlüssel ist – aber auch, warum für Endanwender wohl nur eine geringe Gefahr besteht. Denn: Ein gültiges TLS-Zertifikat vorweisen zu können, ist für Angreifer nur die halbe Miete. Sie müssen zudem den DNS-Server kontrollieren, der die von ihnen angegriffenen Domainnamen in IP-Adressen übersetzt – oder Kontrolle über das IP-Routing ihrer Opfer haben. Dennoch: Der Vorfall ist der größte anzunehmende Unfall für die Web-PKI.

Die großen Browserhersteller haben umgehend reagiert, etwa Mozilla. Der Browser hat bereits am 17. Oktober, knappe drei Stunden nach Bekanntwerden des Vorfalls, die kompromittierten Zertifikate in seine Sperrliste OneCRL aufgenommen und zudem am 20. Oktober die zugehörigen Stammzertifikate aus der Liste vertrauenswürdiger Zertifikate entfernt. Zum Zeitpunkt der Veröffentlichung dieser Meldung ist die von einem polnischen Sicherheitsforscher betriebene Demonstration auf Firefox, Safari und Chrome nicht mehr direkt zugänglich; stattdessen prangt eine Sicherheitswarnung auf dem Bildschirm, die vor einem gesperrten CA-Zertifikat warnt.

Wer selber prüfen will, ob der eigene Browser den kompromittierten Zertifikaten noch vertraut, kann das auf der Website emudhra.we-have-a-problem.com prüfen. Diese baut nacheinander eine Verbindung zu je einer Subdomain auf, die ein von den kompromittierten CAs signiertes Zertifikat vorzeigt.

Administratoren unixoider Systeme müssen hingegen selbst tätig werden, solange diese noch keine Aktualisierungen für ihre CA-Zertifikatspakate (unter Debian etwa ca-certificates) veröffentlicht haben. Verschiedene Betriebssysteme und Programmiersprachen warnen vor dem Zertifikatsmissbrauch mit der CVE-ID CVE-2026-111943, etwa Go, Python-certifi und NetBSD. Letztere empfehlen Nutzern, unverzüglich folgende Kommandos auszuführen:

certctl untrust /usr/share/certs/mozilla/all/emSign_Root_CA_-_C1.pem
certctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_C3.pem

Unter Debian/Ubuntu entfernt eine Aktualisierung des Paketes „ca-certificates“ das Vertrauen in die Zertifizierungsstelle eMudhra komplett.

Mittels curl lässt sich sodann in einer kurzen Schleife überprüfen, ob der Vertrauensentzug geklappt hat: for i in dv-g3b-emudhra dv-g3c-emudhra ov-g3b-emudhra ov-g3c-emudhra ev-g3b-emudhra ev-g3c-emudhra dv-g3b-aaa-emudhra dv-g3c-aaa-emudhra ov-g3b-aaa-emudhra ov-g3c-aaa-emudhra ev-g3b-aaa-emudhra ev-g3c-aaa-emudhra; do echo -n $i": "; curl https://$i.we-have-a-problem.com; done

Sobald ein- oder mehrfach die Ausgabe „Your client successfully connected to the site. That's bad!“ erscheint, hat die Umstellung nicht geklappt und sollte noch einmal überprüft werden.

Die Zertifizierungsstelle eMudhra dürfte nun einigen unangenehme Fragen gegenüberstehen: Etwa der, wie sie auf die Idee kam, dreistellige Zahlen als privaten Schlüssel für CA-Zertifikate zu verwenden. Auch das Unternehmen BDO, das den zur Aufnahme in den Zertifikats-Speichern der Browser notwendigen WebTrust-Audit durchführte, dürfte nun in der Kritik stehen. Schließlich sollte eine derart eklatant unsichere Schlüsselverwaltung bei einer gründlichen Überprüfung der Prozesse und technischen Maßnahmen einer Zertifizierungsstelle auffallen.

(cku)