eMudhra-Zertifikate kompromittiert: Was Unternehmen jetzt prüfen müssen

Ein HTTPS-Schloss im Browser gilt vielen als das verlässlichste Sicherheitssignal im Netz. Dass dieses Vertrauen an einer einzigen Zertifizierungsstelle hängen kann, deren Fehler sich über die gesamte Lieferkette fortpflanzt, hat Mitte Oktober 2026 der Fall der indischen Zertifizierungsstelle eMudhra gezeigt. Acht ihrer Zwischenzertifikate ließen sich fälschen, weil die zugrundeliegenden privaten Schlüssel viel zu kurz waren. Für Unternehmen, die eine eigene Website, einen Onlineshop, ein Kundenportal oder interne Dienste per TLS absichern, lohnt sich ein Blick darauf, was passiert ist – und was aus dem Vorfall an Prüfpflichten bleibt, selbst wenn das eigene Zertifikat nicht von eMudhra stammt.

Was passiert ist

Am Samstag, dem 17. Oktober 2026, um 18:05 UTC erhielt das Chrome Root Program laut dem Sicherheitsblog von Google (öffnet in neuem Tab) den Hinweis eines unabhängigen Sicherheitsforschers: Die privaten Schlüssel von acht Zwischenzertifikaten der Zertifizierungsstelle eMudhra seien kompromittiert. Zwischenzertifikate stehen in der TLS-Vertrauenskette zwischen dem Wurzelzertifikat und dem Zertifikat, das eine konkrete Domain erhält – sie genießen über diese Verbindung dasselbe Vertrauen wie die Wurzel selbst.

Der Grund war laut heise online (öffnet in neuem Tab) keine gestohlene Infrastruktur, sondern ein handwerklicher Fehler: eMudhra hatte für das verwendete Verfahren EC-384 derart leicht zu erratende Werte als privaten Schlüssel gewählt, dass die eigentlich sehr lange Schlüssellänge auf tatsächlich nur 8 Bit zusammenschrumpfte – Zahlen zwischen 0 und 255. Einer der acht Schlüssel lautete schlicht „4". Mit einem derart kurzen Wert lässt sich ein gültig aussehendes TLS-Zertifikat für praktisch jede beliebige Domain fälschen, ohne dass der eigentliche Seitenbetreiber etwas davon merkt.

Laut Microsofts offizieller Stellungnahme im MSRC-Blog (öffnet in neuem Tab) betraf das Problem acht Zwischen-Zertifizierungsstellen: sechs für TLS-Verschlüsselung und zwei für Code-Signing, also für die digitale Signatur von Software. Mit den TLS-Schlüsseln ließen sich laut Microsoft Websites oder Dienste imitieren und Kommunikation potenziell abfangen; mit den Code-Signing-Schlüsseln ließe sich Schadsoftware so signieren, dass sie wie ein Produkt eines vertrauenswürdigen Herausgebers aussieht.

Wie schnell die Browserhersteller reagierten

Der Reaktionsgeschwindigkeit der großen Browserhersteller zeigt, wie ernst die Lage genommen wurde. Laut Google waren Chrome-Nutzer bereits um 19:45 UTC desselben Tages geschützt – gut eineinhalb Stunden nach Bestätigung des Fundes schaltete das Chrome Root Program (öffnet in neuem Tab) ein CRLSet-Update scharf, das die betroffenen Schlüssel sperrte, ohne dass Nutzer ein Browser-Update installieren mussten. Mozilla handelte laut heise ähnlich schnell und nahm die Zertifikate binnen drei Stunden in seine eigene Sperrliste auf.

Bei Microsoft zog sich die Reaktion über mehrere Tage, weil sie tiefer in Windows selbst eingreift. Laut der Zeitleiste des Microsoft Trusted Root Program auf GitHub (öffnet in neuem Tab) veröffentlichte Microsoft am 20. Oktober zunächst ein außerplanmäßiges Update für die Windows-Sperrliste sowie ein CRLSet-Update für Edge und WebView2. Am 26. Oktober folgte ein weiterer Schritt: Microsoft entfernte sieben Zertifikate – sechs eMudhra-Wurzelzertifikate sowie ein mitsigniertes AAA-Certificate-Services-Zertifikat – vollständig aus der Windows-Vertrauensliste, am 27. Oktober auch aus der von Edge. Microsoft betont in derselben Quelle ausdrücklich den Unterschied zwischen Widerruf und Entfernung: Der Widerruf richtet sich gegen die bekannten kompromittierten Zwischenzertifikate, die Entfernung ist eine grundsätzlichere Entscheidung darüber, welchen Zertifikaten Windows künftig überhaupt noch vertraut.

Warum das auch ein Thema für den Mittelstand ist

Wer selbst kein Zertifikat von eMudhra bezogen hat, hält sich schnell für nicht betroffen. Zwei Gründe sprechen dagegen, das Thema deshalb zu überspringen. Erstens: eMudhra bediente laut Reuters (öffnet in neuem Tab) Kunden weit über Indien hinaus, darunter IT-Dienstleister wie Infosys und TCS, deren Software wiederum in vielen Unternehmen weltweit im Einsatz ist – eine Vertrauenskette, die ein einzelnes Unternehmen kaum vollständig überblickt. Zweitens, und praktischer relevanter: Die von Microsoft und den Browserherstellern vorgenommenen Änderungen an den Vertrauenslisten betreffen jedes Windows-Gerät und jeden Edge- oder Chrome-Browser im Unternehmen automatisch, sobald die entsprechenden Updates eingespielt sind. Für Geräte, die regelmäßige Windows-Updates erhalten, läuft das weitgehend im Hintergrund. Kritisch wird es laut Microsofts eigenem Hinweis bei getrennten oder selten aktualisierten Systemen: Server, die keine automatischen Zertifikatslisten-Updates erhalten, VM-Images, die vor dem 20. Oktober erstellt wurden, und eigene Software, die Zertifikatsprüfungen nicht zuverlässig durchführt oder eine eigene, nicht aktualisierte Zertifikatsliste mitbringt.

Cloudflare macht in seinem eigenen Reaktionsbericht (öffnet in neuem Tab) deutlich, dass auch Kunden mit eigener Infrastruktur aktiv werden müssen – konkret alle, die Ursprungsserver im Modus „Full (strict)" betreiben und dort möglicherweise selbst Zertifikate einsetzen, die über eine der betroffenen eMudhra-Hierarchien signiert wurden. Wer eigene APIs gegen externe Dienste mit TLS-Client-Authentifizierung absichert oder eigene vertraute Zertifikatsspeicher in Containern oder Build-Pipelines pflegt, sollte diese laut Cloudflare gezielt auf die betroffenen Zwischenzertifikate prüfen, statt sich allein auf automatische Browser-Updates zu verlassen.

Wie ernst der Vorfall für eMudhra selbst wurde

Wie gravierend der Fehler eingestuft wurde, zeigt die Konsequenz, die eMudhra selbst gezogen hat: Laut Reuters (öffnet in neuem Tab) kündigte das Unternehmen am 22. Oktober 2026 an, sich vollständig aus dem globalen Geschäft mit SSL/TLS-Zertifikaten zurückzuziehen, nachdem Google, Apple und Microsoft den Zertifikaten nicht mehr vertrauten. Die Aktie von eMudhra verlor laut Reuters in den zwei Tagen nach Bekanntwerden der Lücke 40 Prozent ihres Wertes. Besonders bemerkenswert: Laut eigener Aussage des Unternehmens gegenüber Reuters blieb die Schwachstelle 18 Monate lang unentdeckt und überstand in dieser Zeit zwei reguläre Sicherheitsaudits – ein Hinweis darauf, dass sich auch etablierte Prüfprozesse nicht zwangsläufig auf kryptografische Grundlagenfehler dieser Art erstrecken.

Was IT-Verantwortliche konkret prüfen sollten

1. Windows- und Browser-Updates nicht aufschieben. Die relevanten Schutzmaßnahmen laufen über die regulären Update-Kanäle von Windows, Edge und Chrome. Wo automatische Updates deaktiviert sind, sollten die von Microsoft genannten Disallowed-Certificate-Trust-List-Updates manuell nachgezogen werden.
2. Getrennte und selten gepflegte Systeme gezielt prüfen. Server ohne Internetanbindung, ältere VM-Images und eingebettete Geräte mit eigener Zertifikatsverwaltung erhalten die automatischen Schutzmaßnahmen nicht von selbst.
3. Eigene TLS-Konfiguration auf eMudhra-Abhängigkeiten durchsehen, insbesondere bei Ursprungszertifikaten hinter einem CDN im strikten Modus, bei mTLS-Konfigurationen und bei selbst gepflegten Zertifikatsspeichern in Containern.
4. Lieferkette mitdenken. Wer Software von Dienstleistern einsetzt, deren eigene Infrastruktur über eMudhra-Zertifikate abgesichert war, sollte beim Anbieter nach dem Status der Umstellung fragen – ähnlich wie bei anderen Software-Lieferketten-Vorfällen der letzten Jahre.
5. Vertrauensentzug verifizieren, wo eigene Systeme betroffen sein könnten. Microsoft stellt dafür über den Befehl certutil -f -verifyCTL DisallowedWU eine Prüfmöglichkeit bereit, mit der sich die Sequenznummer der eingespielten Sperrliste kontrollieren lässt.

Was bleibt

Der eMudhra-Fall ist in erster Linie ein Vorfall bei einer einzelnen Zertifizierungsstelle – aber er zeigt ein strukturelles Problem der Web-PKI, das jedes Unternehmen betrifft, das sich auf TLS-Zertifikate verlässt: Vertrauen wird an einer Stelle zentral vergeben und wirkt dann über unzählige Weiterverwendungen hinweg, ohne dass der einzelne Nutzer die ursprüngliche Kette noch sieht. Für die eigene IT heißt das nicht, bei jedem Zertifikatsvorfall in Alarmbereitschaft zu verfallen. Es heißt aber, dass die Update-Kanäle, über die solche Vertrauensentscheidungen bei Windows, Edge und Chrome automatisch nachgezogen werden, tatsächlich laufen – und dass genau dort, wo sie es aus guten Gründen nicht tun, jemand im Unternehmen weiß, dass er selbst nachziehen muss.