Acht Zertifikate gesperrt: Sicherheitsvorfall bei Zertifizierungsstelle eMudhra

Der niederländisch-indischen Zertifizierungsstelle (CA, Certification Authority) eMudhra sind offenbar nicht weniger als acht ihrer CA-Zertifikate nebst der privaten Schlüssel entwendet worden. 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 Nutzer bestand wohl keine Gefahr.

Wie es zu dem Vorfall kam, ist unklar – bekannt ist lediglich, dass er dem Browserhersteller Mozilla am 17. Oktober gegen 18 Uhr deutscher Zeit von einem „Mitglied der Community“ gemeldet wurde. 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.

Dass eMudhra das private Schlüsselmaterial für gleich acht dieser Zertifikate entwendet wurde, 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.

Demonstrator zeigt Verwundbarkeit

Lediglich mit dem Kommandozeilenwerkzeug curl kann man noch TLS-Verbindungen zur Demonstration 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 Nutzer 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.

Browser sind sicher, Admins sollten prüfen

Die großen Browserhersteller haben reagiert, etwa Mozilla. Der Browser hat bereits 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 können Systemverwalter das Vertrauen mit den folgenden Maßnahmen auf der Kommandozeile entziehen:

1. sudo dpkg-reconfigure ca-certificates
2. “Ask“ auswählen und folgende Einträge abwählen:
   mozilla/emSign_ECC_Root_CA_-_C3.crt
mozilla/emSign_ECC_Root_CA_-_G3.crt
mozilla/emSign_Root_CA_-_C1.crt
mozilla/emSign_Root_CA_-_G1.crt
3. „OK“ drücken.

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 verschiedene Unbekannte frei über private Schlüssel gleich mehrerer Zwischenzertifikate verfügen und mit diesen TLS-Zertifikate ausstellen können.