Blog / Acht Zertifikatsschlüssel von eMudhra waren für jeden berechenbar.

Acht Zertifikatsschlüssel von eMudhra waren für jeden berechenbar.

#Shopware#Sicherheit#TLS 6 Min. Lesezeit

Acht Zwischenzertifikate der Zertifizierungsstelle eMudhra hatten private Schlüssel, die sich sofort berechnen ließen. Browser blockieren sie bereits. Was Shopbetreiber auf ihren Servern und in ihren Projekten prüfen sollten.

Maschendrahtzaun mit einem großen aufgerissenen Loch in der Mitte, dahinter unscharf eine Wiese und Lichter in der Abenddämmerung. — Bild: Calvin Ma / Unsplash

Am 20. Oktober hat Dennis Jackson, Kryptografieingenieur bei Mozilla, einen ungewöhnlichen Vorfall öffentlich gemacht: Die privaten Schlüssel von acht Zwischenzertifikaten der indischen Zertifizierungsstelle eMudhra sind kompromittiert. Sechs davon durften TLS-Zertifikate für Websites ausstellen, zwei waren für Codesignaturen gedacht. Alle führen zu Stammzertifikaten, denen die Root-Programme von Mozilla, Microsoft, Apple und Google vertrauen. Informationsseite zum Vorfall.

Wer einen dieser Schlüssel besitzt, kann Zertifikate für beliebige Domains ausstellen und sich damit als fremde Website oder fremder Dienst ausgeben. Die großen Browser sperren die Zertifikate inzwischen. Offen ist die Lage bei Software, die Zertifikate selbst prüft. Dazu gehört auch die PHP-Installation, auf der ein Onlineshop läuft.

Einer der Schlüssel war die Zahl 4.

Ein privater Schlüssel für das hier verwendete Verfahren P-384 ist eine Zufallszahl mit 384 Bit. Bei den acht betroffenen Zwischenzertifikaten waren es laut Mozilla ganze Zahlen unter 256. Der Sicherheitsforscher Scott Helme fand unter anderem den Wert 4. Aus dem öffentlichen Zertifikat lässt sich ein solcher Schlüssel praktisch sofort berechnen. The Register zu den Schlüsselwerten.

Gemeldet hat das am 17. Oktober jemand, der unter dem Namen Wayne auftritt. Als Beweis signierte er mit allen acht Schlüsseln den Satz „We have a problem here“ und schickte die Signaturen an Mozilla, Google, Microsoft, Apple und eMudhra. Mozilla konnte die Schlüssel am selben Abend selbst nachrechnen. Mozilla-Bugreport 2083449.

Nach Darstellung von eMudhra entstand der Fehler bei der Schlüsselzeremonie am 30. April 2025. Bei einem Testschritt erzeugte ein fehlerhaftes Skript im Hardware-Sicherheitsmodul einen zweiten, schwachen Schlüsselsatz. Wegen ähnlicher Bezeichnungen wurden dessen Schlüssel für die Zertifikatsanträge verwendet. Der Fehler blieb rund 18 Monate unbemerkt, auch über zwei Audits hinweg. Wie ein Hardware-Sicherheitsmodul solche Schlüssel überhaupt erzeugen konnte, ist im Mozilla-Bugreport noch ungeklärt. Stellungnahme von eMudhra.

Browser sind geschützt, andere Programme erst nach einem Update.

Firefox und Chrome blockieren die Zertifikate seit dem 17. Oktober, Microsoft-Systeme seit dem 20. und Apple-Geräte seit dem 22. Oktober. Android-Geräte erhielten die Sperre ab dem 19. Oktober über die Google-Play-Dienste. eMudhra hat die Zwischenzertifikate am 18. Oktober widerrufen. Mozilla und Google entfernen außerdem das zugehörige Stammzertifikat „emSign ECC Root CA - G3“, im Chrome Root Store voraussichtlich am 27. Oktober. Google zum Chrome Root Store.

Browser verteilen solche Sperren über eigene Kanäle, ohne dass ein Update nötig ist. Viele andere Programme werten Sperrinformationen gar nicht aus. Sie vertrauen einem Zertifikat, solange dessen Aussteller in ihrer Liste vertrauenswürdiger Stammzertifikate steht. Laut der Informationsseite betrifft das Anwendungen und Bibliotheken mit eigener Zertifikatsliste sowie Programme auf Electron-Basis wie Slack oder Discord. Ein Update von Betriebssystem oder Browser reicht für sie nicht aus.

Eine Sache begrenzt den Schaden. Vor der Sperrung gab es für diese Zwischenzertifikate keine Einträge in den öffentlichen Certificate-Transparency-Protokollen. Browser, die solche Einträge verlangen, konnten deshalb nicht unbemerkt angegriffen werden. Viele andere Programme verlangen diese Einträge nicht, curl zum Beispiel. Ob Angreifer die schwachen Schlüssel in den vergangenen 18 Monaten gegen solche Programme eingesetzt haben, ist nicht bekannt.

Seit die Schlüssel öffentlich sind, stellen andere damit Zertifikate aus. Bis zum 25. Oktober zählte ctlogs.dev 107.181 eingetragene Zertifikate, das erste vom Abend des 19. Oktober. Fast alle sind erkennbar Tests und Demonstrationen, darunter rund 105.900 Zertifikate für google.com. Ein Programm mit veralteter Zertifikatsliste würde sie trotzdem akzeptieren. Auswertung von ctlogs.dev.

Was das für Shopware-Shops bedeutet.

Ein Onlineshop baut ständig selbst HTTPS-Verbindungen auf: zu Zahlungsanbietern, Versanddienstleistern und Warenwirtschaft, zu Diensten von Shopware und bei jeder Composer-Installation. PHP prüft diese Verbindungen über curl und OpenSSL gegen eine Liste vertrauenswürdiger Stammzertifikate. Sperrinformationen und Certificate-Transparency-Einträge spielen dabei standardmäßig keine Rolle.

Diese Liste stammt in der Regel aus dem Paket ca-certificates des Betriebssystems. Debian, Ubuntu und die anderen großen Distributionen haben es aktualisiert. Auf unserem eigenen Server hat unser Hoster das Update bereits eingespielt. curl bricht die Verbindung zur Testadresse der Informationsseite dort mit einem Zertifikatsfehler ab. Übersicht der aktualisierten Pakete.

Eine zweite Stelle liegt im Shop-Projekt selbst. Das Composer-Paket composer/ca-bundle bringt eine eigene Zertifikatsliste mit und nutzt sie, wenn es auf dem System keine findet. Bereinigt ist diese Liste in den Versionen 1.4.16 und 1.6.0. Auf einem Server mit aktueller Systemliste kommt diese Datei nicht zum Zug. Aktualisiert werden sollte das Paket trotzdem. composer/ca-bundle auf Packagist.

Läuft der Shop in Containern, steckt die Zertifikatsliste im Image. Ein Update auf dem Host ändert daran nichts, die Images müssen neu gebaut werden. Cloudflare weist ausdrücklich darauf hin und rät davon ab, Zertifikatsfehler durch Abschalten der Prüfung zu umgehen. Cloudflare zum Vorfall.

So lässt sich der eigene Server prüfen.

Die Informationsseite betreibt Testadressen, die mit den kompromittierten Zwischenzertifikaten signiert sind. Auf dem Shop-Server ausgeführt, sollten beide Aufrufe mit einem Zertifikatsfehler abbrechen:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Ob im Projekt noch eine veraltete Zertifikatsliste liegt, zeigt eine Suche nach dem gesperrten Stammzertifikat im Verzeichnis vendor:

grep -rl "emSign ECC Root CA - G3" vendor/

Ein Treffer zeigt, welches Paket aktualisiert werden muss. Der Test mit curl prüft nur die Systemliste. Cloudflare empfiehlt deshalb, den tatsächlichen Verbindungsweg der Anwendung zu testen, also auch Worker, Cronjobs und Container.

eMudhra zieht sich aus dem TLS-Geschäft zurück.

Für deutsche Shops dürften Zertifikate von eMudhra selten sein. Betroffen ist nach Angaben des Unternehmens eine einzige Kundenumgebung in den USA. Inzwischen hat eMudhra angekündigt, das weltweite Geschäft mit öffentlichen TLS-Zertifikaten aufzugeben. Es trug laut WinFuture rund ein Prozent zum Umsatz bei. WinFuture zum Rückzug.

Für die eigene Infrastruktur bleibt die Aufgabe dieselbe wie nach jedem Vorfall dieser Art: Zertifikatslisten auf Servern, in Containern und in Abhängigkeiten aktuell halten und die Prüfung nie abschalten. Bei der Kontrolle betreuter Shops unterstützen wir gern.