Bei der Zertifizierungsstelle eMudhra ist etwas passiert, das in der Web-PKI eigentlich nie passieren darf: Acht ihrer Zwischenzertifikate samt privater Schlüssel sind in fremde Hände geraten. Damit ließen sich gültige TLS-Zertifikate für jede beliebige Domain ausstellen, ein Sicherheitsforscher hat das mit einem Zertifikat für q3k.google.com auch direkt vorgeführt. Die großen Browser haben die betroffenen Zertifikate inzwischen gesperrt. Für normale Nutzer war das Risiko gering, für Serverbetreiber gibt es aber etwas zu tun.
Was genau schiefgelaufen ist
Gemeldet wurde der Vorfall am 17. Oktober am frühen Abend an Mozilla und Google. Betroffen sind sogenannte Intermediate Certificates. Sie sitzen in der Zertifikatskette zwischen dem Wurzelzertifikat und dem Zertifikat, das am Ende für eine Domain ausgestellt wird. CAs nutzen solche Zwischenstufen, um Produktlinien oder Validierungsverfahren sauber zu trennen. Weil sie am Root hängen, genießen sie im Browser genau dasselbe Vertrauen wie die Wurzel selbst.
Zunächst sah alles nach gestohlenen Schlüsseln aus. Im Laufe des Dienstagabends wurde dann klar, dass es noch peinlicher ist: eMudhra hatte die privaten Schlüssel schlicht so schwach erzeugt, dass man sie erraten konnte. Beim verwendeten Verfahren EC-384 ist der private Schlüssel eine Zahl, die einen Punkt auf einer elliptischen Kurve festlegt. Alle acht Werte lagen zwischen 0 und 255, hatten also nur 8 Bit. Einer der Schlüssel war tatsächlich einfach die Zahl 4.
Das ist mehr als ein Schönheitsfehler. CAs müssen sich an die strengen Baseline Requirements des CA/Browser Forums halten, gerade damit so etwas nicht vorkommt. Kritische Fragen dürfte sich auch die Prüfgesellschaft BDO gefallen lassen, die das für die Aufnahme in die Browser-Zertifikatsspeicher nötige WebTrust-Audit durchgeführt hat. Eine derart eklatante Schwäche hätte bei einer gründlichen Prüfung auffallen müssen.
Warum du als Endanwender eher ruhig bleiben kannst
Ein gefälschtes, aber formal gültiges Zertifikat reicht für einen Angriff nicht aus. Ein Angreifer muss zusätzlich dafür sorgen, dass dein Rechner bei der Namensauflösung auf seinen Server zeigt. Er braucht also Kontrolle über DNS oder das IP-Routing seines Opfers. Die Demo des Forschers funktionierte deshalb nur, wenn man curl per --resolve gezielt an eine bestimmte IP-Adresse schickte. Trotzdem gilt: Für das Vertrauensmodell der Web-PKI ist so ein Vorfall der schlimmste denkbare Fall.
Die Browserhersteller haben schnell gehandelt. Mozilla hat die Zertifikate schon rund drei Stunden nach der Meldung in seine Sperrliste OneCRL aufgenommen und am 20. Oktober auch die zugehörigen Wurzelzertifikate aus dem Vertrauensspeicher entfernt. Firefox, Chrome und Safari zeigen beim Aufruf der Demo inzwischen eine deutliche Warnung. Ob dein Browser den betroffenen Zertifikaten noch vertraut, kannst du auf der Testseite emudhra.we-have-a-problem.com nachsehen.
Was Admins jetzt tun sollten
Auf Servern sieht es anders aus. Unix-artige Systeme bringen eigene CA-Pakete mit, und solange die nicht aktualisiert sind, vertrauen Tools wie curl, wget oder deine Anwendungen den kompromittierten Zertifikaten weiter. Die Lücke läuft unter CVE-2026-111943, Warnungen gibt es unter anderem von Go, Python-certifi und NetBSD.
- Debian und Ubuntu: Aktualisiere das Paket
ca-certificates. Die neue Version entzieht eMudhra das Vertrauen vollständig. - NetBSD: Dort wird empfohlen, die beiden Wurzeln manuell zu entfernen:
certctl untrust /usr/share/certs/mozilla/all/emSign_Root_CA_-_C1.pemcertctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_C3.pem- Python-Umgebungen und Go-Builds: Prüfe, ob
certifibzw. die eingebetteten Root-Stores auf dem neuesten Stand sind.
Ob die Änderung greift, testest du mit einer kleinen Schleife über die Testdomains:
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; doneTaucht dabei irgendwo die Meldung „Your client successfully connected to the site. That's bad!“ auf, vertraut dein System eMudhra noch. Dann solltest du den Schritt wiederholen und gegebenenfalls auch Container-Images und CI-Runner prüfen, die ihre eigenen CA-Bundles mitbringen.