Das Prüfwerkzeug mitmproxy stellt seit Version 12.3.0 per Schalter Zertifikate für jede Website aus, signiert mit einem kompromittierten Zwischenzertifikat von eMudhra. Browser lehnen solche Zertifikate ab, WordPress 7.1.3 und die Kommandozeilenwerkzeuge von macOS vertrauen ihnen weiter.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenDer private Schlüssel des Zwischenzertifikats EM OV TLS CA G3C ist die Zahl 4. So steht es im Quelltext von mitmproxy 12.3.0, erschienen in der Nacht zum 22. Oktober.[1] Zwei Tage nach Bekanntwerden der acht schwachen Schlüssel von eMudhra genügt damit ein Schalter, um Programme mit veralteter Liste vertrauenswürdiger Zertifikate zu täuschen.
Das Wichtigste in Kürze
- mitmproxy 12.3.0 signiert per Schalter Zertifikate mit einem der acht kompromittierten eMudhra-Schlüssel.
- Chrome streicht am 27. Oktober das Wurzelzertifikat emSign ECC Root CA G3.
- Google stellt eMudhra zwölf Fragen, auch zu einem Warnsignal aus dem Juni 2025.
- WordPress 7.1.3 und die Kommandozeilenwerkzeuge von macOS vertrauen den Zertifikaten weiterhin.
Was ändert der Schalter –emudhra?
Im Normalbetrieb erzeugt mitmproxy eine eigene Zertifizierungsstelle, die Nutzer erst installieren müssen, bevor das Werkzeug verschlüsselte Verbindungen mitliest. Mit –emudhra nimmt es stattdessen den Schlüssel von EM OV TLS CA G3C. Die Variante –emudhra-old nutzt für Listen vertrauenswürdiger Wurzelzertifikate, die älter als 2021 sind, die zusätzliche Signatur von Sectigos Wurzelzertifikat AAA Certificate Services.[1] Jedes Programm, das einer dieser Ketten noch vertraut, akzeptiert die Zertifikate ohne Installation.
Ausrechnen konnte die Schlüssel jeder schon vorher. In einem Vorschlag vom 20. Oktober bat ein Nutzer darum, sie per Knopfdruck anzubieten, statt Nutzer die Dateien zusammensuchen zu lassen.[2]
Wie viele Programme noch vertrauen, zeigt der Testserver von Mozilla-Entwickler Dennis Jackson. Eine Stichprobe zählte am 22. Oktober binnen knapp neun Stunden über 500.000 Verbindungen, die ein kompromittiertes Zertifikat akzeptierten. Am häufigsten meldeten sich in iOS-Apps eingebettete Browseransichten, Safari und curl, die Browserkennungen lassen sich allerdings fälschen.[3] Android-Apps sind laut Google nur geschützt, wenn sie auf die neueste Systemversion ausgelegt sind oder diese öffentlichen Zertifikatsprotokolle selbst prüfen.[5]
Warum stellt Google eMudhra zwölf Fragen?
Das Chrome Root Program stellte eMudhra am 21. Oktober zwölf Fragen und bemängelte, dass die Statusseite von eMudhra weder das gesperrte Wurzelzertifikat noch die betroffenen Zwischenzertifikate nennt.[4] Laut den öffentlichen Protokollen aller ausgestellten Zertifikate (Certificate Transparency) gelten noch rund 30.800 Zertifikate unter emSign ECC Root CA G3, 30.791 davon stammen von InCommon, dem Zertifikatsdienst des US-Hochschulnetzes Internet2.
Am 27. Oktober entfernt Chrome dieses Wurzelzertifikat. Betroffene Websites brauchen laut Google sofort ein Zertifikat einer anderen Zertifizierungsstelle.[5]
Am schärfsten fragt Google nach einem Warnsignal aus dem Juni 2025. Damals passten die Signaturen unter eMudhras Sperrlisten nicht zu den Zwischenzertifikaten. eMudhra signierte die Listen mit einem zweiten, passenden Schlüssel neu, ohne zu klären, warum für dieselben Zertifizierungsstellen zwei Schlüsselpaare existierten.[4] Der zweite Schlüssel war der schwache.
Findet eine Zertifizierungsstelle einen unerklärten zweiten Schlüssel, muss sie die Ausstellung stoppen. eMudhra signierte 16 Monate lang weiter.
Markus Seyfferth, Chefredakteur Dr. Web
Stand der Korrekturen
Was sollten Betreiber jetzt tun?
WordPress 7.1.3 liefert emSign ECC Root CA G3 weiter in der eigenen Zertifikatsliste aus, anhand derer es ausgehende Verbindungen zu Schnittstellen prüft.[6] Art. 32 DSGVO nennt Verschlüsselung ausdrücklich als Schutzmaßnahme, eine Verbindung mit gefälschtem Zertifikat schützt aber nicht vor Mitlesern.[7]
- Laufzeitumgebungen aktualisieren: Node.js 22.23.4, 24.22.1 und 26.12.1 sowie Java enthalten seit dem 21. Oktober die bereinigte Liste.[3]
- macOS nachbessern: curl, git und python3 prüfen anhand der nicht aktualisierten Datei /etc/ssl/cert.pem. Jacksons Seite nennt einen Befehl zum Bereinigen.[3]
- Selbst prüfen: Ein Aufruf von dv-g3b-aaa-emudhra.we-have-a-problem.com per curl muss mit einem Zertifikatsfehler enden, ebenso die Adresse ohne „-aaa“.
Ob jemand die Schlüssel vor dem 17. Oktober außerhalb der Browser missbraucht hat, ist offen, eMudhras Antworten stehen aus.
Quellen
7 Quellen anzeigenQuellen ausblenden
- mitmproxy auf GitHub„22 October 2026: mitmproxy 12.3.0“, Änderungsprotokoll und Quelltext certs.py
- mitmproxy auf GitHubInclude eMudhra certificate as easily choosable option, Issue 8497
- Dennis Jackson (Mozilla)eMudhra Intermediate CA Compromise und Connection Statistics (Abruf 22. Oktober 2026, 12:45 Uhr)
- Mozilla BugzillaFragen des Chrome Root Program an eMudhra, Bug 2083449 (21. Oktober 2026)
- GoogleProtecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
- WordPress auf GitHubZertifikatsliste in WordPress 7.1.3
- Datenschutz-GrundverordnungArt. 32 DSGVO, Sicherheit der Verarbeitung
Mehr Newshunger?
- Zwischenzertifikate von eMudhra kompromittiert: Jeder konnte die privaten Schlüssel berechnen
- Angreifer erschleichen sich TLS-Zertifikate für Google und andere große Dienste
- Railway: Angreifer lasen entschlüsselte Umgebungsvariablen von Kunden aus
- Kompromittiertes LiteLLM 1.107.0 auf PyPI stahl Zugangsdaten und installierte eine Hintertür
- WordPress 7.1.3: das dritte Sicherheitsupdate in 19 Tagen
- Cloudflare baut eine Zertifizierungsstelle für das gesamte Internet
- Claude klärt die Herkunft der ECDSA-Kurven: Die NSA-Startwerte stammen aus einem simplen Zufallsgenerator
- Cybersecurity-Glossar 2026: 99 Begriffe von BSI bis Zero Trust für Entscheider
