eMudhra widerruft acht weitere Zwischenzertifizierungsstellen nach Schlüsselpanne

Jede Zwischenzertifizierungsstelle besitzt einen eigenen privaten Schlüssel, mit dem sie die von ihr ausgestellten Zertifikate signiert. Bei den acht im Oktober kompromittierten CAs lag das Problem nach Angaben des Unternehmens darin, dass eine einzige Zeile im Skript jeden ihrer Schlüssel auf ein einziges Byte verkürzte.

Von den nun widerrufenen acht RSA-CAs waren sechs für Website-Zertifikate (TLS) und zwei für Code-Signing vorgesehen. Vier davon hatte eMudhra im Mai in den Produktivbetrieb genommen. Die Liste des Unternehmens umfasst 195 Zertifikate dieser Aussteller, 29 davon für eigene Domains:

• 130 von EM DV TLS CA - G2C
• 63 von EM OV TLS CA - G2C
• 2 von der Code-Signing-CA EM OV CS CA - G2C

Neben den eigenen Domains tauchen in den Zertifikaten mehrere Universitäten und Colleges, ein County sowie weitere Organisationen auf. Das jüngste Zertifikat wurde vergangene Woche ausgestellt, wenige Tage vor dem Widerruf. Laut eMudhra wurden alle Inhaber auf neue Zertifikate umgestellt.

Ursprung in einer Schlüsselzeremonie

Beide Probleme gehen laut dem vollständigen Vorfallsbericht, den eMudhra diese Woche im Mozilla-Bugtracker veröffentlicht hat, auf eine Schlüsselzeremonie am 30. April 2025 zurück. An diesem Tag erzeugte das Unternehmen 16 CA-Schlüssel auf HSMs von Utimaco, darunter die acht, die hinter der Kompromittierung im Oktober stehen. Bestimmt waren die Schlüssel für HSMs von Crypto4A an den Standorten in den USA und der EU. Da sich Schlüssel zwischen HSMs verschiedener Hersteller nur eingeschränkt übertragen lassen, schrieb das PKI-Betriebsteam das Python-Skript, das jeden Schlüssel für den Transport verpacken (wrap) und wieder entpacken (unwrap) sollte.

Der Durchlauf an jenem Tag war eine Probe der Übertragung; der FIPS-zugelassene Modus des Quell-HSM war dafür im Rahmen einer genehmigten Ausnahme abgeschaltet. Nach dem Durchlauf las das Skript jeden privaten Schlüssel aus dem HSM in den Arbeitsspeicher des Zeremonierechners und baute den Schlüssel aus dieser Kopie neu auf. Bei den acht ECDSA-Schlüsseln kürzte nach Darstellung des Berichts eine einzige Zeile beim Zurücklesen den privaten Wert auf sein führendes Byte. Der neu aufgebaute Schlüssel trug eine nahezu identische Bezeichnung wie das Original, sodass die schwache Kopie zur Signatur und Zertifizierung weitergereicht wurde.

Alle acht Schlüssel lassen sich aus ihren öffentlichen Zertifikaten berechnen. Der kleinste, der von EM OV TLS CA - G3C, hat den Wert 4, der größte 237. In der Zeremonie prüfte nichts die Stärke der Schlüssel oder glich den zertifizierten Schlüssel mit dem ursprünglich erzeugten ab. Die schwachen Schlüssel lieferten weiterhin gültige Signaturen; ihre Zertifikate bestanden Linting-Prüfungen und zwei WebTrust-Auditzyklen unbemerkt. Die HSMs funktionierten nach Angaben von eMudhra die ganze Zeit korrekt, den Fehler sieht das Unternehmen bei seinem eigenen Skript und seinen Prozesskontrollen.

Ein frühes Anzeichen waren laut Bericht ungültige CRL-Signaturen im Juni 2025. eMudhra behob sie damals, indem es die Sperrlisten mit den Schlüsseln neu signierte, die zu den Zertifikaten passten – also mit den schwachen.

Warum die RSA-Schlüssel doch betroffen sind

Dem Bericht zufolge durchliefen auch die acht RSA-Schlüssel denselben Rückleseschritt, den das Unternehmen in seiner früheren Antwort ausgeschlossen hatte. Anfang vergangener Woche erklärte eMudhra, die früheren Antworten hätten nur den damaligen Kenntnisstand der Teams wiedergegeben, auch was die Skriptpfade der jeweiligen Schlüsselgruppen betraf.

Das Skript verkürzte diese Schlüssel nicht, und jede Signatur lässt sich weiterhin gegen den zertifizierten Schlüssel prüfen. Ihre privaten Bestandteile, etwa der private Exponent und eine der Primzahlen, lagen jedoch im Speicher eines Python-Prozesses auf dem Zeremonierechner. Deshalb könne das Unternehmen nicht positiv nachweisen, dass dieses Schlüsselmaterial im Einklang mit CPS §6.2.6 stand – seiner eigenen Regel für das Übertragen von Schlüsseln in ein und aus einem HSM. Protokolle und Dateien des Rechners können den Umgang mit dem Material nicht verlässlich belegen.

Zu dieser Einschätzung kam eMudhra Anfang November nach Gesprächen mit den Root-Programmen der Browser. Die acht RSA-CAs wurden mit dem Grundcode cessationOfOperation widerrufen, nicht mit dem Code für eine CA-Kompromittierung, der beim Widerruf der ersten acht am 18. Oktober verwendet worden war. Teilnehmer im Bug-Thread fragen, warum das Unternehmen nicht keyCompromise gewählt hat. Sie fordern außerdem die Veröffentlichung des Skripts, einige wollen wissen, wie private Schlüssel die HSMs überhaupt verlassen konnten.

Laut eMudhra wurde das Wrap-und-Unwrap-Verfahren nur dieses eine Mal eingesetzt; bei allen anderen Schlüsselzeremonien seien die Schlüssel direkt im HSM erzeugt worden. KPMG, vom Unternehmen als unabhängiger Prüfer beauftragt, soll bis zum 4. Dezember fertig sein. Eine Bestandsaufnahme aller CA-Schlüssel hat eMudhra für den 30. November angekündigt.

Ein Missbrauchsfall ist dem Unternehmen nicht bekannt. Wer einen der Oktober-Schlüssel besaß, hätte sich nach Angaben einer Informationsseite von Dennis Jackson, der die Schlüssel für Mozilla untersuchte, als beliebige Website ausgeben können. Browser, die Certificate Transparency durchsetzen, hätten sich nicht täuschen lassen. Ob die Schlüssel gegen Software ohne diese Prüfung eingesetzt wurden, ist unbekannt.

Was emSign-Kunden prüfen sollten

eMudhra, das Zertifikate unter der Marke emSign vertreibt, zieht sich nach einer Ankündigung vom 22. Oktober aus dem Geschäft mit öffentlich vertrauenswürdigen TLS-Zertifikaten zurück. Betroffene Zertifikate finden Inhaber in der Liste des Unternehmens oder über eine Suche in Certificate-Transparency-Logs nach den widerrufenen G2C-TLS-Ausstellern.

Sämtliche Ausstellungen aus der G1-Hierarchie sollen vor dem 16. November enden; die verbleibenden Kunden, vor allem ein Hochschulverbund in Nordamerika, wechseln zu einem anderen Anbieter. Microsoft beginnt laut einer Aktualisierung seines Sicherheitsbeitrags am 16. November, die zehn verbliebenen eMudhra-Roots zu entfernen, darunter emSign Root CA - G1. Zertifikate, die auf diese Roots verweisen, verlieren dann in Windows und Edge das Standardvertrauen, in einigen weiteren Microsoft-Produkten nach jeweils eigenem Zeitplan. Laut dem Auslaufplan von eMudhra vertrauen Chrome und Firefox keinen G1-Zertifikaten mehr, die nach dem 16. November ausgestellt werden; Apple beendet am 30. November das Vertrauen in alle G1-Zertifikate, auch ältere.

Apple teilte in einem Support-Dokument mit, dass macOS 27.2.1, 26.7.3 und 15.8.3 mitgelieferte Kommandozeilenwerkzeuge wie curl und git die kompromittierten TLS-CA-Zertifikate nicht mehr akzeptieren lassen. Zudem entfernen die Updates fünf Roots, darunter emSign Root CA - G1, aus /etc/ssl/cert.pem; Werkzeuge, die auf diese Datei setzen, können manche Websites mit Zertifikatskette zu diesen Roots daher womöglich nicht mehr verifizieren.