Die indische Zertifizierungsstelle eMudhra hat am 10. November 2026 ihren vollständigen Vorfallbericht im Bugzilla von Mozilla veröffentlicht – einen Tag später als zuletzt zugesagt. Er erklärt, warum im Oktober acht Zwischenzertifikate der Marke emSign praktisch ungeschützt waren, und er enthält eine neue Nachricht: Am 7. November hat eMudhra acht weitere Zwischenzertifikate zurückgezogen. Bei ihnen sind die Schlüssel nicht schwach, das Unternehmen kann aber nicht belegen, dass sie das Sicherheitsmodul nie ungeschützt verlassen haben.

Was eine Zertifizierungsstelle tut – und was hier schiefging

Eine Zertifizierungsstelle (Certificate Authority, CA) bestätigt mit ihrer digitalen Unterschrift, dass ein TLS-Zertifikat wirklich zu einer Domain gehört. Browser und Betriebssysteme liefern eine Liste von Wurzelzertifikaten mit, denen sie vertrauen. Von diesen Wurzeln leiten die CAs Zwischenzertifikate ab, mit denen sie im Alltag die Zertifikate für Websites ausstellen. Wer den privaten Schlüssel eines solchen Zwischenzertifikats kennt, kann sich für jede beliebige Domain ein Zertifikat ausstellen, das Browser ohne Warnung annehmen.

Genau das war bei eMudhra möglich. Am 17. Oktober 2026 meldete ein Sicherheitsforscher den Browser-Herstellern und eMudhra, dass er die privaten Schlüssel von acht Zwischenzertifikaten errechnen konnte: sechs für TLS, zwei für Code-Signaturen. Mozilla vollzog das laut seinem Eintrag im Bugzilla noch am selben Abend unabhängig nach. Die Schlüssel auf der elliptischen Kurve P-384 hätten zufällige, riesige Zahlen sein müssen. Tatsächlich war der geheime Wert bei allen acht kleiner als 256. Es genügte also, die ersten 256 möglichen Schlüssel durchzuprobieren.

eMudhra zog die acht Zertifikate am 18. Oktober zurück, Sectigo am 19. Oktober acht weitere, mit denen es dieselben Schlüssel gegengezeichnet hatte. Nach Angaben von eMudhra wurde mit den betroffenen Zwischenzertifikaten nie ein Zertifikat für Kunden ausgestellt, ein Missbrauch sei nicht bekannt.

Symbolbild: Steckkarte eines Hardware-Sicherheitsmoduls von nCipher mit blauem Kühlkörper

Symbolbild: Hardware-Sicherheitsmodul nCipher nShield F3 als Steckkarte – in solchen Modulen erzeugen und verwahren Zertifizierungsstellen ihre Schlüssel; eMudhra nutzte Geräte anderer Hersteller. Foto: Alexander Klink, CC BY 3.0, via Wikimedia Commons

Ein Python-Skript schnitt die Schlüssel ab

Der Bericht führt den Fehler auf eine einzige Schlüsselzeremonie am 30. April 2025 zurück. Damals erzeugte eMudhra 16 Schlüsselpaare für Zwischenzertifikate der Serien „B“ und „C“, gedacht für den Betrieb in Europa und den USA: acht ECDSA-Schlüssel (P-384) und acht RSA-Schlüssel mit 4096 Bit. Die Hardware-Sicherheitsmodule (HSM) für den US-Standort waren nach Angaben des Unternehmens wegen Lieferengpässen noch nicht da. Deshalb entstanden die Schlüssel auf vorhandenen Geräten von Utimaco und sollten später verschlüsselt auf Module des Herstellers Crypto4A umziehen.

Für diesen Umzug schrieb das Betriebsteam ein eigenes Python-Skript, das den Export probeweise durchspielte. Die HSM arbeiteten laut Bericht korrekt und erzeugten zunächst einwandfreie Schlüssel. Das Skript las den privaten Schlüssel danach aber aus dem Modul in den Arbeitsspeicher des Rechners und legte daraus ein neues Schlüsselobjekt an. Bei den ECDSA-Schlüsseln kürzte eine einzelne Codezeile den Wert dabei auf ein Byte. Weil das fehlerhafte Objekt fast denselben Namen trug wie das Original, wurde ausgerechnet dieses für den Zertifikatsantrag verwendet und von der Wurzel unterschrieben.

Aufgefallen ist das niemandem: Auch ein schwacher Schlüssel erzeugt gültige Signaturen, und eine Prüfung der Schlüsselstärke gab es in der Zeremonie nicht. Eine Gelegenheit ließ eMudhra verstreichen. Im Juni 2025 passten die Signaturen der Sperrlisten nicht zu den Zertifikaten, weil sie mit den ursprünglichen, guten Schlüsseln erzeugt worden waren. Das Unternehmen signierte kurzerhand mit den anderen Schlüsseln neu, ohne nach der Ursache zu suchen – und damit mit den schwachen.

Warum acht weitere Zertifikate fallen

Die acht RSA-Schlüssel derselben Zeremonie durchliefen das gleiche Skript. Sie wurden nicht gekürzt, lagen beim erneuten Import aber ebenfalls im Arbeitsspeicher eines Python-Prozesses. Die eigenen Regeln von eMudhra und die Baseline Requirements der Branche verlangen, dass ein CA-Schlüssel sein Sicherheitsmodul nur geschützt verlässt. Weil sich im Nachhinein weder belegen noch ausschließen lässt, was mit den Daten geschah, hat eMudhra die acht RSA-Zwischenzertifikate der Reihen G2B und G2C am 7. November mit dem Grund „Betrieb eingestellt“ gesperrt. In der Diskussion zum Bericht wird diese Begründung kritisiert: Mehrere Teilnehmer fragen, warum nicht „Schlüssel kompromittiert“ angegeben wurde.

Anders als die schwachen ECDSA-Zertifikate waren vier der RSA-Zertifikate seit Mai 2026 im Einsatz und haben Zertifikate für Kunden ausgestellt, das letzte am 3. November. Die betroffenen Kunden sind nach Angaben von eMudhra bereits umgezogen.

Browser entziehen das Vertrauen

Der Entzug des Vertrauens ist das schärfste Mittel, das Browser-Hersteller gegenüber einer CA haben, denn danach sind deren Zertifikate wertlos. Mozilla sperrte die acht Zwischenzertifikate am 17. Oktober binnen drei Stunden über die Sperrliste OneCRL, Chrome verteilte nach Angaben von Google noch schneller ein CRLSet. Weil viele andere Programme solche Sperrlisten nicht auswerten, entfernten beide zusätzlich die Wurzel emSign ECC Root CA - G3: Mozilla am 20. Oktober mit NSS 3.131.1, Chrome mit einer Aktualisierung des Chrome Root Store, die Google für den 27. Oktober ankündigte.

Die zweite Wurzel, emSign Root CA - G1, läuft aus. Chrome 153 und neuer vertrauen laut Google keinen Zertifikaten dieser Kette mehr, deren frühester Zeitstempel aus der Certificate Transparency nach dem 16. November 2026 liegt; ältere Zertifikate bleiben gültig. Nach Angaben von eMudhra gilt für Firefox derselbe Stichtag, Apple entferne die Wurzel am 30. November vollständig. eMudhra selbst hat den Ausstieg aus dem Geschäft mit öffentlich vertrauenswürdigen TLS-Zertifikaten erklärt und will die Ausstellung vor dem 16. November einstellen.

Vergleichbar harte Schritte gab es selten. 2011 warf Mozilla den niederländischen Anbieter DigiNotar nach unrechtmäßig ausgestellten Zertifikaten vollständig aus dem Programm. 2017 kündigte Google an, Symantec-Zertifikaten das Vertrauen zu entziehen, was Chrome 2018 in zwei Stufen umsetzte. Im Juni 2024 traf es Entrust: Chrome akzeptiert seit Version 131 keine Entrust-Zertifikate mehr, deren frühester Zeitstempel nach dem 11. November 2024 liegt.

Offene Fragen

eMudhra hat die Beratungsfirma KPMG mit einer unabhängigen Prüfung beauftragt; Verbesserungen daraus sollen bis zum 4. Dezember umgesetzt sein. Fachleute fragen im Bugzilla unter anderem, wie das Schlüsselmaterial im Arbeitsspeicher geschützt war. Das Unternehmen weist seinerseits darauf hin, dass die schwachen Schlüssel rund 18 Monate lang öffentlich einsehbar waren und weder Prüfer noch die Werkzeuge der Browser-Hersteller sie bemerkten. Google hat angekündigt, die zentrale Datenbank der CAs künftig automatisch auf schwache Schlüssel zu prüfen.

Was du jetzt tun solltest

Die meisten Websites sind nicht betroffen: Laut Google hingen am 21. Oktober rund 30.800 gültige Zertifikate an der entfernten Wurzel, fast alle ausgestellt für Hochschulen des US-Verbunds InCommon. Prüfen solltest du es trotzdem, wenn du Zertifikate über eMudhra, emSign oder die Plattform CertiNext bezogen hast.

  • Kette ansehen: Lass dir die Zertifikatskette deines Servers ausgeben und achte auf Aussteller mit „emSign“ oder „EM … TLS CA“ im Namen.
  • Zertifikat ersetzen: Führt die Kette zu emSign ECC Root CA - G3, akzeptiert Chrome das Zertifikat nicht mehr, und auch Mozilla hat die Wurzel aus seiner Liste gestrichen. Führt sie zu emSign Root CA - G1, verliert das Zertifikat auf Apple-Geräten nach Angaben von eMudhra am 30. November sein Vertrauen. Besorge dir in beiden Fällen ein Zertifikat einer anderen CA; eMudhra vermittelt Bestandskunden nach eigenen Angaben kostenlos Ersatz.
  • Automatik umstellen: Bezieht dein Server Zertifikate per ACME von emSign, trage beim Client eine andere CA ein. Nach dem 16. November will emSign nichts mehr ausstellen, und Chrome ab Version 153 würde neuere Zertifikate dieser Kette ohnehin ablehnen.
  • Eigene Vertrauenslisten aktualisieren: Software, die Mozillas Liste mitbringt oder eine eigene pflegt, braucht ein Update, damit die entfernte Wurzel verschwindet. Die Hashwerte aller betroffenen Zertifikate stehen im Vorfallbericht.
openssl s_client -connect example.org:443 -showcerts </dev/null | grep -E "s:|i:"

Quellen

Bildnachweis