eMudhra widerruft acht weitere CAs nach Offenlegung von RSA-Schlüsseln durch Skriptfehler

Die Certificate Authority eMudhra hat acht zusätzliche Intermediate-Certificate-Authorities (CAs) widerrufen, nachdem festgestellt wurde, dass ein benutzerdefiniertes Python-Skript, das während einer Schlüsselzeremonie verwendet wurde, deren RSA-Private Keys offengelegt hatte. Das Unternehmen gab zunächst an, diese CAs seien vom Oktober-Vorfall nicht betroffen gewesen, revidierte seine Position jedoch Anfang November nach weiteren Untersuchungen und Diskussionen mit den Root-Programmen der Browser.

Was passiert ist

Der Vorfall geht auf eine Schlüsselzeremonie am 30. April 2025 zurück, bei der eMudhra 16 CA-Schlüssel auf Utimaco-Hardware-Sicherheitsmodulen (HSMs) generierte. Diese Schlüssel sollten auf Crypto4A-HSMs an den US- und EU-Standorten des Unternehmens übertragen werden. Da die Übertragung von Schlüsseln zwischen HSMs verschiedener Anbieter eingeschränkt ist, schrieb das PKI-Betriebsteam ein Python-Skript, um die Schlüssel für den Transport zu verpacken (Wrap) und auszupacken (Unwrap). Während eines Testlaufs dieses Transfers las das Skript die Private Keys aus dem HSM in den Speicher des Zeremonie-Computers, um sie wiederherzustellen.

Bei acht ECDSA-Schlüsseln truncatierte eine einzelne Zeile im Skript den privaten Wert auf sein führendes Byte, wodurch kritisch schwache Schlüssel entstanden, die anschließend zertifiziert wurden. Während diese acht im Oktober widerrufen wurden, ging das Unternehmen zunächst davon aus, dass acht RSA-Schlüssel, die durch dasselbe Skript verarbeitet wurden, sicher seien, da das Skript sie nicht truncatierte. Die Untersuchung ergab jedoch, dass die privaten Komponenten dieser RSA-Schlüssel, wie der private Exponent und die Primzahlen, im Speicher des Python-Prozesses auf dem Zeremonie-Computer verblieben waren.

Diese Offenlegung bedeutete, dass eMudhra die Einhaltung seiner eigenen Certification Practice Statement (CPS) bezüglich der Schlüsselbehandlung nicht nachweisen konnte. Das Unternehmen erklärte, es „kann nicht positiv belegen, dass dieses Schlüsselmaterial konform war“ mit den Regeln, die bestimmen, wie Schlüssel in und aus HSMs bewegt werden. Infolgedessen wurden die acht RSA-CAs Ende letzter Woche widerrufen. Sechs davon waren für TLS-Website-Zertifikate und zwei für Code-Signing bestimmt; insgesamt waren 195 ausgestellte Zertifikate betroffen, darunter 29 für die eigenen Domains von eMudhra.

Wichtige Details

• Acht Intermediate-CAs wurden aufgrund der Offenlegung von RSA-Schlüsseln im Speicher widerrufen, nicht wegen Schlüssel-Truncation.
• Der Fehler stammte von einem Python-Skript, das während einer Schlüsselzeremonie am 30. April 2025 verwendet wurde.
• 195 Zertifikate waren betroffen, darunter solche für Universitäten, einen Landkreis und eMudhra selbst.
• Das Unternehmen behauptete zunächst in einem Update an Mozilla am 19. Oktober, dass diese CAs nicht betroffen seien.
• Der Widerrufsgrund wurde als cessationOfOperation angegeben, nicht als keyCompromise.
• Microsoft wird die verbleibenden eMudhra-Wurzelzertifikate ab dem 16. November aus Windows und Edge entfernen.

Hintergrund

Hardware Security Modules (HSMs) sind physische Geräte, die entwickelt wurden, um kryptografische Schlüssel sicher zu erzeugen und zu speichern. Ein Kernprinzip der HSM-Nutzung ist, dass Private Keys das Gerät niemals im Klartext verlassen dürfen. Wenn Organisationen Schlüssel zwischen verschiedenen HSM-Anbietern migrieren müssen, verwenden sie oft Wrapping-Prozesse, die den Schlüssel für den Transport verschlüsseln. In diesem Fall umging das benutzerdefinierte Skript von eMudhra Standard-Schutzmaßnahmen, indem es den Schlüssel zur Rekonstruktion in den Systemspeicher las, was ein Fenster schuf, in dem das geheime Material für Extraktion oder Protokollierung anfällig war.

Certificate Authorities operieren unter strengen Audits wie WebTrust und müssen sich an ein Certification Practice Statement (CPS) halten. Wenn eine CA nicht nachweisen kann, dass ein privater Schlüssel gemäß diesen Regeln behandelt wurde, können Browser und Betriebssysteme das Vertrauen in diese CA widerrufen. Dies stellt sicher, dass das Risiko gemildert wird, indem die Vertrauenskette invalidiert wird, falls ein Schlüssel potenziell kompromittiert ist, auch ohne Nachweis eines Missbrauchs.

Warum es wichtig ist

Für Teams, die Self-Hosted-Software betreiben, hebt dieser Vorfall die Fragilität des Vertrauens im öffentlichen Zertifikats-Ökosystem hervor. Wenn Sie sich auf Zertifikate der emSign-Marke von eMudhra verlassen, könnten Ihre Dienste bald Vertrauensfehler in Browsern und Betriebssystemen erfahren. Microsoft entfernt die verbleibenden eMudhra-Wurzeln am 16. November, und Apple beendet das Vertrauen in alle G1-Zertifikate bis zum 30. November. Das bedeutet, dass interne Tools, APIs oder kundenseitige Apps, die diese Zertifikate verwenden, nicht mehr funktionieren werden, es sei denn, sie werden migriert.

Über unmittelbare Ausfälle hinaus dient diese Geschichte als Warnung vor benutzerdefinierten Skripten in kritischer Sicherheitsinfrastruktur. Selbst große, auditierte Organisationen können durch einfache Codierungsfehler schwerwiegende Schwachstellen einführen. Für DevOps- und IT-Leiter unterstreicht dies die Bedeutung der Überprüfung der Herkunft und Behandlung kryptografischer Materialien, insbesondere bei der Nutzung von Drittanbieter-CAs, die möglicherweise den Markt verlassen oder Stabilitätsprobleme haben.

Was Sie tun können

• Prüfen Sie über Certificate Transparency Logs, ob Ihre Dienste Zertifikate verwenden, die von den G1- oder G2C-Hierarchien von eMudhra ausgestellt wurden.
• Ersetzen Sie betroffene Zertifikate sofort durch welche von einem stabilen, vertrauenswürdigen Anbieter.
• Aktualisieren Sie macOS-Systeme auf die Versionen 27.2.1, 26.7.3 oder 15.8.3, um sicherzustellen, dass gebündelte Tools wie curl kompromittierte Wurzeln ablehnen.
• Überwachen Sie Ihre Anwendungsprotokolle auf TLS-Handshake-Fehler, die auf Vertrauensprobleme mit älteren Zertifikaten hinweisen könnten.
• Überprüfen Sie Ihre eigenen Schlüsselverwaltungsverfahren, um sicherzustellen, dass keine benutzerdefinierten Skripte Private Keys im Speicher offenlegen.
• Stellen Sie sicher, dass Ihr Monitoring-Stack Sie bei Änderungen des Ablaufdatums oder des Widerrufsstatus von Zertifikaten alarmiert.