Rund 30.000 TLS certificates müssen nach schwachen CA keys migriert werden
TLS certificates für rund 30.000 Websites müssen migriert werden, nachdem festgestellt wurde, dass acht Keys von intermediate CA leicht zu erraten waren. Der Vorstand von eMudhra hat beschlossen, sich aus dem weltweiten Geschäft mit Secure Sockets Layer und Transport Layer Security (SSL/TLS) certificates zurückzuziehen. Diese liefern die digitalen Nachweise, mit denen Browser vertrauenswürdige, verschlüsselte Verbindungen zu Websites herstellen.
Ein Sicherheitsforscher meldete am 17. Oktober, die private key für acht Zertifikate von eMudhra-intermediate CA wiederhergestellt zu haben. Eine intermediate CA befindet sich zwischen einem vertrauenswürdigen root und den darunter ausgestellten website certificates. Ihre private key ist der geheime Wert, mit dem certificates und zugehörige records signiert werden. Dem Bericht zufolge lag jeder der acht Werte unter 256, statt eine sehr große Zufallszahl zu sein, sodass sie nahezu sofort ermittelt werden konnten. Sechs der acht intermediates waren für TLS certificates vorgesehen.
Der Forscher informierte Apple, Google, Microsoft, Mozilla und eMudhra. Chrome und Firefox blockierten die sechs TLS intermediates innerhalb weniger Stunden. Google erklärte, dass vor dem Eingreifen von Chrome kein von diesen intermediates ausgestelltes website certificate in öffentlichen Certificate Transparency (CT) logs aufgetaucht sei. Certificate Transparency (CT) logs sind öffentliche records über ausgestellte website certificates. Software, die verlangt, dass certificates dort erscheinen, hätte certificates dieser intermediates daher vor der Blockierung nicht akzeptieren können. eMudhra erklärte, die acht intermediates hätten nie certificates für Websites oder Nutzer ausgestellt, und die eigenen Systeme seien nicht kompromittiert worden.
Die größeren Auswirkungen ergeben sich aus den Maßnahmen der Browser gegen emSign ECC Root CA - G3, den vertrauenswürdigen root oberhalb der betroffenen intermediates. Mozilla beschloss am 20. Oktober, diesem root in Firefox nicht mehr zu vertrauen. Die Entfernung durch Chrome soll die Nutzer voraussichtlich am Morgen des 27. Oktober pazifischer Zeit erreichen. Wird ein root entfernt, werden auch ansonsten legitime TLS certificates ungültig, deren trust chain auf ihn zurückführt. Websitebetreiber müssen diese Nachweise deshalb ersetzen, selbst wenn ihre eigenen Systeme nicht kompromittiert wurden.
Chrome zählte am 21. Oktober in öffentlichen Certificate Transparency (CT) logs rund 30.800 noch nicht abgelaufene certificates, die mit dem root verbunden waren. Nach Angaben von Chrome waren 99,9 % davon über InCommon ausgestellt worden, den von Internet2 für den Hochschulbereich eingerichteten Zertifikatsdienst. InCommon übertrug diesen Dienst zwischen April und Juli auf die CertiNext-Plattform von eMudhra. Google hat betroffene Betreiber angewiesen, ein neues TLS certificate aus einer anderen public key infrastructure hierarchy zu beziehen und zu installieren, die weiterhin im Chrome Root Store enthalten ist.
eMudhra schätzte, dass rund 30.000 certificates migriert werden müssen, und erklärte, etwa 97 % seien über Automated Certificate Management Environment (ACME) ausgestellt worden, ein Protokoll, über das Server certificates automatisch anfordern und erneuern. Chrome warnte, dass gewöhnliche ACME clients ein certificate in der Regel nicht vor dem normalen Erneuerungszeitraum ersetzen, sofern sie nicht ACME Renewal Information (ARI) unterstützen oder ein Administrator manuell eingreift. Der Wechsel von der betroffenen ECC hierarchy zur separaten RSA hierarchy kann außerdem Änderungen an den Client-Einstellungen erfordern.
Cornell riet seinen Zertifikatsinhabern, RSA certificates anzufordern, da diese derzeit den nicht betroffenen root von eMudhra verwenden. Die Universität identifizierte mehr als 300 eigene betroffene certificates. Auch die University of Michigan erklärte, dass InCommon RSA certificates derzeit nicht betroffen seien, warnte jedoch, dass auch deren root das Vertrauen verlieren könnte. Als wichtigste aktuelle Alternative nannte sie Let's Encrypt.
Die separate G1 RSA hierarchy wird während der Umstellung weiterhin Kunden bedienen. Mozilla erklärte am 20. Oktober, emSign Root CA - G1 zu diesem Zeitpunkt nicht zu entfernen. Chrome prüfte weiterhin, ob die übrigen CA certificates von eMudhra in seinem root store verbleiben sollten. Bei Stanford führen InCommon certificates über eine eMudhra-Authority mit dem Namen emSign Root TLS CA - G1 zu G1.
Fragen gibt es außerdem zu einer certificate revocation list (CRL), die am 14. Oktober für emSign Root TLS CA - G1 veröffentlicht wurde. Eine certificate revocation list (CRL) ist ein von einer CA signierter record über certificates, die nicht mehr gültig sind. Der Forscher erklärte im öffentlichen Incident Report von Mozilla, dass sich die Signatur dieser Liste nicht mit dem eigenen Key der CA verifizieren ließ. Ein anderer Beteiligter berichtete am 22. Oktober, die Liste sei offenbar mit einem eMudhra-Online-Certificate-Status-Protocol-(OCSP)-certificate signiert worden. Dieses signiert normalerweise Antworten auf die Frage, ob einzelne certificates widerrufen wurden. Der Beteiligte bewertete die Abweichung als offensichtliche Verwendung des falschen signing key und nicht als Hinweis auf einen weiteren schwachen key.
Chrome führte die ungültige Liste in zwölf Fragen an, die am 21. Oktober veröffentlicht wurden. Das Unternehmen fragte, welcher key die Liste signiert habe, ob eMudhra mehrere key pairs für diese CA oder irgendeinen root verwaltet habe, wohin Kunden migriert würden und wann die Migration abgeschlossen sein werde. eMudhra hatte am 20. Oktober erklärt, G1 sei die einzige verfügbare Alternative. Am folgenden Tag teilte das Unternehmen jedoch mit, dass betroffene US-Kunden neue certificates aus einer anderen, unabhängig betriebenen und öffentlich vertrauenswürdigen CA hierarchy erhielten.
Die Fragen greifen außerdem sechs ungültige certificate revocation lists (CRLs) auf, die eMudhra 2025 für dieselben intermediates veröffentlicht hatte. Im damaligen Incident Report hieß es, die Listen seien mit der passenden private key für jede intermediate CA neu erstellt worden. Am 19. Oktober teilte eMudhra Mozilla mit, dass die Listen zunächst mit den vorgesehenen keys signiert worden seien, später jedoch erneut mit den fehlerhaften keys signiert wurden, nachdem sich die ersten Signaturen als ungültig erwiesen hatten. Chrome erklärte, dies werfe ernsthafte Fragen zur Transparenz und zur Bearbeitung des Vorfalls von 2025 auf. Dazu gehöre auch die Frage, warum der frühere Bericht nicht offengelegt habe, dass für jede betroffene CA zwei key pairs existierten. Bis Donnerstag um 13:31 Uhr UTC hatte eMudhra die Fragen von Chrome im Bug Report nicht öffentlich beantwortet; der jüngste sichtbare Kommentar des Unternehmens war vom 20. Oktober.
eMudhra erklärte, betroffene Kunden würden von Partnern kostenlose Ersatz-certificates erhalten, nannte jedoch weder diese Partner noch einen Termin für den Ausstieg. Das Unternehmen wird Widerrufs- und Statusdienste betreiben, bis jedes von ihm ausgestellte SSL/TLS certificate entweder abgelaufen oder ersetzt worden ist. Aus der Ankündigung ging nicht hervor, ob während des Rückzugs weiterhin neue certificates über G1 ausgestellt werden. Die Geschäftsbereiche für digitale Signaturzertifikate, eSign und CertiNext werden fortgeführt.
Das Unternehmen erklärte, die weltweiten SSL/TLS-Dienste machten etwa 1 % seines Umsatzes aus. Als Faktoren für den Ausstieg nannte es die Kosten und die Komplexität von Anforderungen an Datensouveränität und Compliance, den Wettbewerb durch große Anbieter kostenloser certificates sowie die intensive Prüfung infolge des Vorfalls.
Websitebetreiber sollten feststellen, wer jedes aktive TLS certificate ausgestellt hat, prüfen, welchen root es verwendet, und betroffene Nachweise ersetzen, anstatt auf eine automatische Erneuerung zu warten. Für WordPress-Betreiber, die Änderungen an certificates zusammen mit der Sicherheit ihres Hostings prüfen, bietet AEU Hosting vollständig abgesichertes Managed WordPress Hosting.