Sicherheit & Datenschutz

eMudhra steigt aus dem globalen SSL-Geschäft aus, nachdem schwache Schlüssel entdeckt wurden

eMudhra wird sich vom globalen SSL/TLS-Markt zurückziehen, nachdem Forscher herausgefunden haben, dass acht private Schlüssel von Intermediate-CAs leicht zu erraten waren. Dies erzwang einen massenhaften Austausch von Zertifikaten.

Serverschränke unter einer Glaskuppel mit Warnleuchten und gebrochenen Ketten, die gebrochenes SSL-Vertrauen symbolisieren
Für diesen Artikel erstellte Illustration

Automatisch aus dem englischen Original übersetzt.

Die indische Zertifizierungsstelle eMudhra gab am Donnerstag bekannt, dass sie ihr globales Geschäft mit SSL/TLS-Zertifikaten einstellen wird. Die Entscheidung folgt der Entdeckung eines Sicherheitsforschers, dass acht private Schlüssel ihrer Intermediate Certificate Authorities (CA) kritisch schwach und leicht wiederherstellbar waren. Große Browser-Anbieter wie Google und Mozilla haben bereits Maßnahmen ergriffen, um die betroffenen Root-Zertifikate nicht mehr als vertrauenswürdig einzustufen, was zehntausende Websites beeinträchtigt.

Was passiert ist

Der Vorfall begann am 17. Oktober, als ein Forscher Apple, Google, Microsoft, Mozilla und eMudhra meldete, dass acht private Schlüssel von Intermediate-CAs kompromittiert seien. Diese Schlüssel, bei denen es sich eigentlich um große Zufallszahlen hätte handeln sollen, lagen alle unter dem Wert 256. Diese extreme Schwäche bedeutete, dass jeder die privaten Schlüssel nahezu sofort berechnen konnte, wodurch das kryptografische Vertrauensmodell für alle darunter ausgestellten Zertifikate effektiv gebrochen wurde. Sechs dieser acht Schlüssel wurden für Website-TLS-Zertifikate verwendet.

Als Reaktion darauf blockierten Chrome und Firefox die sechs betroffenen TLS-Intermediate-CAs innerhalb weniger Stunden nach der Meldung. Google bestätigte, dass vor der Blockierung keine Website-Zertifikate von diesen Intermediate-CAs in öffentlichen Certificate Transparency Logs aufgetaucht waren, was bedeutet, dass sie wahrscheinlich nicht zur Ausstellung gültiger Zertifikate für Endbenutzer verwendet wurden. eMudhra erklärte, dass seine Systeme nicht gehackt worden seien und dass diese spezifischen schwachen Schlüssel nie zur Ausstellung von Zertifikaten an Kunden verwendet wurden. Der Vertrauensschaden war jedoch sofort und schwerwiegend.

Nach der Offenlegung beschloss der Vorstand von eMudhra, sich vollständig aus dem globalen SSL/TLS-Markt zurückzuziehen. Das Unternehmen begründete dies damit, dass dieses Segment nur etwa 1 % seines Umsatzes ausmacht und komplexe Kosten für Datensouveränität und Compliance mit sich bringt. Zudem wies das Unternehmen darauf hin, dass die Aufmerksamkeit in den sozialen Medien im Verhältnis zur Größe des Geschäfts unverhältnismäßig gewesen sei. eMudhra wird seine anderen Dienste, einschließlich digitaler Signaturen und der CertiNext-Plattform, weiter betreiben, aber die Ausgabe neuer globaler TLS-Zertifikate einstellen.

Wichtige Details

  • Chrome wird das Root-Zertifikat „emSign ECC Root CA - G3“ am Morgen des 27. Oktober (Pazifische Zeit) nicht mehr als vertrauenswürdig einstufen.
  • Mozilla entschied am 20. Oktober, das gleiche Root-Zertifikat in Firefox nicht mehr zu vertrauen, was legitime Zertifikate, die daran gekettet sind, abschneidet.
  • Laut einer Zählung von Chrome waren zum 21. Oktober ungefähr 30.800 nicht abgelaufene Zertifikate an das betroffene Root-Zertifikat gekettet.
  • Etwa 99,9 % der betroffenen Zertifikate wurden über InCommon ausgestellt, einen Dienst für die Hochschulgemeinschaft.
  • eMudhra schätzt, dass etwa 30.000 Zertifikate ersetzt werden müssen, wobei 97 % über das ACME-Protokoll ausgestellt wurden.
  • Standard-ACME-Clients ersetzen Zertifikate außerhalb ihres Erneuerungszeitraums nicht automatisch, es sei denn, sie unterstützen ACME Renewal Information (ARI).

Hintergrund

Um die Schwere des Vorfalls zu verstehen, hilft es zu wissen, wie das TLS-Vertrauen funktioniert. Browser und Betriebssysteme pflegen einen „Root Store“ mit vertrauenswürdigen Zertifizierungsstellen. Wenn eine Website ein Zertifikat präsentiert, prüft der Browser, ob es zu einem dieser vertrauenswürdigen Roots zurückverfolgt werden kann. Wenn der Root aus dem Store entfernt wird, wie es bei eMudhras ECC-Root geschehen ist, wird jedes darunter ausgestellte Zertifikat als nicht vertrauenswürdig eingestuft. Benutzer sehen Sicherheitwarnungen, und automatisierte Systeme können möglicherweise keine Verbindung herstellen.

Das spezifische Versagen hier betraf private Schlüssel von Intermediate-CAs. Eine Intermediate-CA sitzt zwischen dem Root und dem Endbenutzer-Zertifikat. Wenn der private Schlüssel einer Intermediate-CA bekannt ist, kann ein Angreifer betrügerische Zertifikate für jede Domain ausstellen. In diesem Fall waren die Schlüssel so klein (unter 256), dass sie keinerlei Sicherheit boten. Obwohl eMudhra behauptet, dass diese Schlüssel nicht zur Ausstellung verwendet wurden, signalisiert allein die Existenz solcher schwacher Schlüssel in einer Produktionsumgebung ein kritisches Versagen bei den Prozessen zur Schlüsselerzeugung.

Warum das wichtig ist

Für Teams, die selbst gehostete Software betreiben oder interne Dienste verwalten, verdeutlicht dieser Vorfall die Fragilität, wenn man sich auf einen einzigen Zertifikatsanbieter verlässt. Selbst wenn Ihre öffentlich zugängliche Website eine andere CA nutzt, könnten interne Tools oder Partnerintegrationen auf von eMudhra ausgestellte Zertifikate angewiesen sein. Da Chrome und Firefox das Vertrauen entziehen, werden alle Dienste, die von diesen Zertifikaten abhängen, nicht mehr funktionieren. Dazu gehören APIs, Microservices und Drittanbieter-Integrationen, die TLS-Ketten streng validieren.

Der Migrationsprozess ist ebenfalls komplex. Google hat Betreiber angewiesen, sofort neue Zertifikate aus einer anderen PKI-Hierarchie zu beziehen. Der Wechsel von einem ECC-basierten Root zu einem RSA-basierten oder zu einem völlig anderen Anbieter erfordert jedoch oft manuelle Eingriffe. Automatisierte Tools wie ACME-Clients bewältigen außerplanmäßige Ersetzungen möglicherweise nicht reibungslos, insbesondere wenn sie keine Unterstützung für ACME Renewal Information bieten. Dies führt zu einem Anstieg manueller Arbeit für IT- und DevOps-Teams, die jeden betroffenen Endpoint aufspüren müssen.

Darüber hinaus wirft der Vorfall Fragen zur Transparenz und betrieblichen Hygiene auf. eMudhra hatte 2025 ungültige Certificate Revocation Lists (CRLs) für ähnliche Intermediate-CAs veröffentlicht und damals behauptet, das Problem durch die Neugenerierung der CRLs mit geeigneten Schlüsseln behoben zu haben. Die jüngste Entdeckung deutet darauf hin, dass diese Korrekturen möglicherweise resigning mit fehlerhaften Schlüsseln beinhalteten, ein Detail, das im früheren Bericht nicht offengelegt wurde. Diese Unklarheit macht es für Kunden schwierig, das Risiko verbleibender eMudhra-Roots, wie dem G1 RSA Root, der noch von Chrome überprüft wird, einzuschätzen.

Was Sie tun können

  • Prüfen Sie Ihr Inventar auf Zertifikate, die von eMudhra ausgestellt wurden, insbesondere solche, die an „emSign ECC Root CA - G3“ gekettet sind.
  • Überprüfen Sie, ob Ihre Dienste Teil der InCommon-Federation sind, da 99,9 % der betroffenen Zertifikate zu dieser Gruppe gehören.
  • Ersetzen Sie betroffene Zertifikate sofort durch solche von einer anderen, vertrauenswürdigen CA-Hierarchie, wie Let's Encrypt oder einem kommerziellen Anbieter.
  • Stellen Sie sicher, dass Ihre ACME-Clients ACME Renewal Information (ARI) unterstützen, um zukünftige erzwungene Ersetzungen reibungsloser zu handhaben.
  • Beobachten Sie den Status des G1 RSA Roots von eMudhra, da Chrome noch nicht entschieden hat, ob er im Root Store verbleibt.
  • Aktualisieren Sie Ihre Monitoring-Systeme, um bei Zertifikatsänderungen und Vertrauensproblemen Alarm zu schlagen, damit Sie nicht vertrauenswürdige Roots erkennen, bevor es die Benutzer tun.

Weitere News

Alle News