Zu den acht betroffenen Zwischenzertifikaten gehören sechs für TLS und zwei für Code Signing:

  • TLS, domainvalidiert: EM DV TLS CA - G3B (eMudhra BV, Niederlande) und EM DV TLS CA - G3C (eMudhra Inc, USA)
  • TLS, organisationsvalidiert: EM OV TLS CA - G3B und EM OV TLS CA - G3C
  • TLS, Extended Validation: EM EV TLS CA - G3B und EM EV TLS CA - G3C
  • Code Signing: EM OV CS CA - G3B und EM OV CS CA - G3C

Die sechs TLS-Zertifikate wurden von emSign Root TLS CA - G3 ausgestellt und ketten zu emSign ECC Root CA - G3, einer Wurzel in den Root-Stores von Chrome und Apple sowie – bis zum 20. Oktober – auch bei Mozilla. eMudhra vertreibt Zertifikate unter der Marke emSign über Gesellschaften in Indien, den USA und den Niederlanden und ist in den Root-Stores von Mozilla, Chrome und Apple vertreten.

Jedes der acht Zertifikate existiert laut einer von Dennis Jackson, Kryptografie-Ingenieur bei Mozilla, veröffentlichten Zertifikatsliste zusätzlich als zweites Zertifikat mit demselben öffentlichen Schlüssel, cross-signiert von Sectigo unter dessen Wurzel AAA Certificate Services.

Nach Angaben des Chrome Root Program war vor der Sperre kein TLS-Zertifikat, das zu den sechs für Websites genutzten Zwischenstellen ketten würde, in Certificate Transparency protokolliert worden. Damit hätte keines in Chrome oder einem anderen Browser mit CT-Pflicht standardmäßig als vertrauenswürdig gelten können. Die beiden Code-Signing-Zertifikate musste Chrome nicht sperren, weil sein TLS-Verifizierer keinen Pfad über eine auf Code Signing beschränkte Zwischenstelle aufbaut.

Zeitlicher Ablauf der Sperren

Das Chrome Root Program erhielt die Meldung am 17. Oktober um 18:05 UTC und hatte bis 19:45 UTC ein CRLSet-Update ausgeliefert, das die sechs TLS-Zwischenzertifikate blockiert. Mozilla erhielt die Meldung um 20:06 UTC und schloss das Ausrollen einer OneCRL-Sperre an Firefox-Installationen mit Standardeinstellungen um 22:59 UTC ab. CRLSets und OneCRL sind Sperrlisten, die die Browser selbst abrufen – weder ein Update noch ein Neustart war nötig. Chromes Sperre greift am öffentlichen Schlüssel statt am Zertifikat und erfasst damit auch die von Sectigo cross-signierten Kopien; es ist derselbe Mechanismus, den Chrome zuvor in diesem Monat gegen unberechtigte Zertifikate für Google-Domains eingesetzt hatte.

Der Forscher, den Mozilla nur als Wayne nennt, signierte laut Jackson die Nachricht „Wir haben hier ein Problem – Wayne" mit jedem der acht Schlüssel und schickte sie noch am selben Tag an die Root-Programme. Jackson veröffentlichte Signaturen und Zertifikate auf einer einseitigen Website.

eMudhra hat die acht Zertifikate widerrufen. Apple sperrte sie laut Jacksons Website am 19. Oktober, Microsoft am 20. Oktober; weitere Trust Stores wurden am 19. Oktober benachrichtigt.

Die cross-signierten Kopien vergrößern das Risiko in Chrome und Firefox nicht: Beide vertrauen Sectigos Wurzel AAA Certificate Services seit April 2025 nicht mehr für Websites, und Chromes Root-Store-Datei führt sie nicht. Apples Root-Liste für iOS 26 und macOS 26, veröffentlicht im Dezember 2025, enthält sie hingegen.

Mozilla geht nach Angaben von Jackson auf der Policy-Mailingliste derzeit nicht davon aus, dass andere Zertifizierungsstellen betroffen sind. Chrome erklärte, man habe jedes weitere CA-Zertifikat im eigenen Store geprüft und „keine weiteren Fälle dieses Fehlermusters gefunden".

Go-Releases und weitere Korrekturen

Dieselben Schlüssel hatte Go in seinen Sicherheitsreleases vom 20. Oktober gesperrt, ohne die Zertifizierungsstelle zu nennen; die acht Hash-Werte im Go-Code stimmen mit den acht Zertifikaten überein. Go behandelte den Fix auf der Schiene URGENT, die die Sicherheitsrichtlinie des Projekts für Bedrohungen der Integrität des Ökosystems oder für aktiv ausgenutzte Fehler vorsieht; weder das Issue noch die Release Notes sagen, welcher Fall vorliegt.

Gos Filter liegt in der Standardbibliothek und weist jede Kette zurück, die einen der acht Schlüssel enthält – sowohl im eigenen Verifizierer als auch auf den System-Verifizierer-Pfaden unter macOS und Windows. Eine Abschaltoption gibt es nicht. Ein Programm übernimmt den Filter erst, wenn es mit dem neuen Release neu gebaut wird; Go 1.25 und älter sind außerhalb des Supports und erhalten keine Korrekturen.

Drei weitere Korrekturen setzen nicht auf Schlüsselsperren, sondern auf das Entfernen von Wurzeln: certifi, webpki-roots und Homebrews ca-certificates streichen emSign ECC Root CA - G3 aus ihren Bündeln, Homebrew zusätzlich Sectigos AAA Certificate Services und emSign Root TLS CA - G3. Damit entfällt auch jedes legitime Zertifikat, das zu diesen Wurzeln kettet. Mozilla, das dieselbe Änderung in NSS vornahm, erklärte, einige Server würden für Nutzer seiner Vertrauensliste außerhalb von Firefox unerreichbar, bis diese Server auf neue Zertifikatsketten umstellen.

Firefox benötigt nichts weiter, sofern Remote Settings nicht per Richtlinie deaktiviert oder im Netzwerk blockiert ist; für solche Installationen enthalten die Releases vom 20. Oktober die Sperrliste.

Browser bekommen Sperrinformationen zugeschoben. Viele andere Programme, die TLS-Zertifikate prüfen – von Go-Binaries bis zu allem, was Pythons certifi-Bündel nutzt –, werten keine Sperrdaten aus und vertrauen einer Kette weiter, bis sich ihr Code oder ihr Root-Bündel ändert. Mozillas Empfehlung an Betreiber eines Trust Stores: Wo Clients Sperrinformationen zuverlässig prüfen und Verbindungen ablehnen, wenn sie nicht prüfen können, ist nichts zu tun. Wo die Software einzelne Zwischenzertifikate sperren kann, sollten die acht jetzt gesperrt werden. Andernfalls sollte der Betreiber erwägen, das Vertrauen in die signierenden Wurzeln zu entfernen.

Eine Möglichkeit, früheren Missbrauch der Schlüssel zu erkennen, nennt keine der Stellen – abgesehen von Chromes CT-Suche, die nur protokollierte Zertifikate erfasst.

Folgen für eMudhra

Mozilla entfernte emSign ECC Root CA - G3 am 20. Oktober aus NSS. Chrome wird dieselbe Wurzel in Version 43 seines Root Stores entfernen und prüft laut Chrome Root Program angesichts der Schwere des Vorfalls auch den Status von eMudhras zweiter Wurzel im Store, emSign Root CA - G1.

Wie und wann die Schlüssel eMudhra verließen, ist unbekannt, ebenso, ob außer dem Forscher jemand über sie verfügt. Mozilla erklärte, man arbeite mit der Zertifizierungsstelle, anderen Root-Programmen und nachgelagerten Trust Stores an der Ursachenanalyse und werde nachlegen, sobald möglich. eMudhras Repository für Vertrauensdienste enthielt am 20. Oktober keinen Hinweis auf den Vorfall.

Im Go-Issue, dessen Release Notes „spezifische Sicherheitsbedenken rund um deren Betrieb" anführen, fragte ein Kommentator nach einer Erklärung der Hashes im Patch. Filippo Valsorda, der die Kryptografie-Pakete in Gos Standardbibliothek betreut, antwortete, die Schlüssel seien kompromittiert und die Zertifikate widerrufen; Linux-Root-Stores seien zu schlecht gepflegt, als dass Sperrinformationen die Anwendungen erreichten, und die Schlüssel im Code zu hinterlegen sei derzeit die einzige Option.