Microsoft hat Ende Oktober 2026 auf kompromittierte Schlüssel aus der eMudhra-Zertifikatshierarchie reagiert. Für Windows 11 gibt es mit KB5134133 ein außerplanmäßiges Update. Besonders wichtig ist es für Rechner, die keine aktuellen Zertifikatsvertrauenslisten automatisch erhalten. Ein normaler Windows-Patchstand beantwortet diese Frage allein nicht.
Hier erfährst du, welche Schutzmechanismen beteiligt sind, wie du den lokalen Stand prüfst und was bei isolierten Firmengeräten zu beachten ist. Recherchestand: 29. Oktober 2026. Der Vorfall, Microsofts Gegenmaßnahmen und die Veröffentlichung dieses Artikels liegen an unterschiedlichen Tagen.
Was ist bei eMudhra passiert?
Laut Microsofts Sicherheitsmeldung vom 26. Oktober, aktualisiert am 27. Oktober 2026 betrifft der Vorfall acht private Schlüssel untergeordneter Zertifizierungsstellen: sechs für TLS und zwei für Codesignierung. Mit solchen Schlüsseln könnten Dritte scheinbar legitime Zertifikate erzeugen oder Software signieren. Microsoft beschreibt einen Vorfall bei eMudhra, keine Kompromittierung eigener Systeme.
Die Risiken unterscheiden sich: TLS-Zertifikate dienen unter anderem zur Authentifizierung von Websites und Diensten. Codesignaturen helfen bei der Zuordnung von Software zu einem Herausgeber. Eine missbrauchbare Vertrauenskette kann diese Prüfungen unterlaufen. Daraus folgt aber nicht, dass auf deinem Rechner bereits ein Angriff stattgefunden hat.
Warum Windows-Updates und Zertifikatsupdates verschiedene Dinge sind
Windows verwaltet Zertifikatsvertrauen über Certificate Trust Lists, kurz CTLs. Es gibt Listen für vertrauenswürdige und ausdrücklich nicht vertrauenswürdige Zertifikate. Der CTL-Updater kann diese unabhängig vom monatlichen Patchday aktualisieren. Microsoft erklärt den Mechanismus in Certificates and trust in Windows.
Eine erfolgreiche Installation des letzten kumulativen Updates belegt deshalb nicht automatisch, dass ein Rechner auch den vorgesehenen CTL-Verteilungsweg erreicht. Umgekehrt ist das Fehlen der Sonderupdate-KB allein kein Beweis für fehlenden Schutz auf einem online aktualisierten Gerät. Für die Bewertung brauchst du beide Informationen: Betriebssystemstand und tatsächliche Versorgung mit Zertifikatslisten.
Welche Gegenmaßnahmen Microsoft ausgerollt hat
Die offizielle Ankündigung des Microsoft Trusted Root Program unterscheidet mehrere Maßnahmen:
| Datum 2026 | Maßnahme |
|---|---|
| 20. Oktober | Windows-Sperrliste für die kompromittierten CA-Schlüssel; zusätzlich ein CRLSet-Update für Edge und WebView2. |
| 26. Oktober | Entfernung von sieben Zertifikaten aus der Windows-Vertrauensliste: sechs eMudhra-G3-Wurzeln und eine AAA-Certificate-Services-Kreuzsignierung. |
| 27. Oktober | Entsprechende Entfernung aus der Edge-Vertrauensliste. |
Die Sperre kompromittierter Schlüssel und die weitergehende Entfernung von Vertrauensankern sind unterschiedliche Schritte. Auch der Widerruf durch die Zertifizierungsstelle ist davon zu unterscheiden. Diese Trennung erklärt, weshalb mehrere Listen und Komponenten geprüft werden müssen.
Wer muss jetzt handeln?
Prüfe zuerst, zu welcher Gruppe dein Gerät gehört:
- Normaler Online-PC: Kontrolliere, dass automatische Windows-Zertifikatsupdates und Edge-Komponentenupdates zugelassen und erreichbar sind.
- Verwalteter Firmenrechner: Lass die IT den vorgesehenen Verteilungsweg und dessen aktuellen Stand prüfen.
- Isoliertes oder stark eingeschränktes Gerät: Kläre ausdrücklich, wie aktuelle vertrauenswürdige und gesperrte CTLs auf das System gelangen.
- Betreiber betroffener Dienste: Ermittle Zertifikatsketten, die von entfernten Vertrauensankern abhängen, und organisiere Ersatz.
Die letzte Empfehlung stammt aus der MSRC-Meldung. Microsoft warnt außerdem davor, Vertrauen in betroffene Hierarchien ohne Prüfung der Risiken lokal wiederherzustellen. Eine Zertifikatswarnung nach einer Vertrauensänderung kann eine wirksame Schutzmaßnahme anzeigen.
Lokale Zertifikatslisten mit certutil prüfen
Für die Diagnose kannst du in einer Eingabeaufforderung oder Windows PowerShell die folgenden Befehle ausführen. Sie wählen die im Registry-Cache vorhandenen Listen aus; es werden damit keine Zertifikate pauschal importiert oder gelöscht:
certutil -verifyCTL AuthRoot
certutil -verifyCTL DisallowedDie certutil-Referenz unterscheidet diese lokalen Objekte von AuthRootWU und DisallowedWU. Die WU-Varianten beziehen sich auf den Download-/URL-Cache; mit -f kann ein Download von Windows Update erzwungen werden. Verwechsle eine erfolgreich abgerufene aktuelle Liste daher nicht mit einem vollständigen Nachweis des bisher wirksamen lokalen Zustands.
Bewahre die vollständige Ausgabe mit Datum auf. Ein Fehler oder eine leere gefilterte Ausgabe ist zunächst ein Diagnoseergebnis, keine Bestätigung eines Angriffs. Unterstützte Parameter lassen sich lokal mit certutil -verifyCTL -? anzeigen.
Microsofts Online-Vergleich und seine Grenze
Das Trusted Root Program nennt folgenden Online-Prüfschritt:
certutil -f -verifyCTL DisallowedWU | findstr SequenceNumberDie dort für die eMudhra-Sperrmaßnahme dokumentierte Sequenznummer lautet 01dd5f6ca45c9d86. Diese Angabe gehört zum Stand der veröffentlichten Maßnahme; spätere Listen können andere Nummern haben. Vergleiche die Ausgabe mit der jeweils aktuellen Herstellerankündigung. Falls die Filterung wegen lokalisierter Ausgabe nichts zeigt, führe den Befehl ohne | findstr SequenceNumber aus.
Auf einem absichtlich isolierten Rechner ist ein fehlgeschlagener Internetabruf erwartbar. Ersetze dort nicht eigenmächtig den vorgesehenen internen Updatepfad.
KB5134133: Sonderupdate für Geräte ohne aktuelle CTLs
KB5134133 vom 26. Oktober 2026 richtet sich ausdrücklich an Geräte ohne aktuelle automatische CTL-Versorgung. Microsoft klassifiziert es als kumulatives, außerplanmäßiges Nicht-Sicherheitsupdate, obwohl der Anlass sicherheitsrelevant ist.
Die Builds lauten 26100.9725 für 24H2, 26200.9725 für 25H2 und 26300.9725 für 26H2. Die Zuordnung findest du auch im Microsoft Update Catalog, getrennt nach x64 und Arm64. Für andere Windows-Zweige gelten andere Pakete.
Der KB-Artikel verweist für die Bereitstellung auf den Catalog. Beachte Voraussetzungen und die angegebene Reihenfolge erforderlicher Checkpoint-Pakete. Installiere nicht irgendeine MSU-Datei nur aufgrund eines ähnlich klingenden Dateinamens.
Wichtig für Hotpatch: Microsoft weist darauf hin, dass entsprechend registrierte Geräte nach Installation dieses Updates erst nach der Januar-2027-Baseline wieder Hotpatch-Updates erhalten. Das gehört vor einer Freigabe in die Wartungsplanung. Prüfe vor Installation außerdem die aktuellen bekannten Probleme im KB-Artikel.
Isolierte Netze dauerhaft versorgen
Ein einzelnes Paket ersetzt keinen laufenden Prozess für Zertifikatsvertrauen. Microsoft dokumentiert eine interne CTL-Verteilung in Configure trusted roots and disallowed certificates. Die Konzepte sind unabhängig von WSUS.
Für eine administrative Staging-Synchronisierung zeigt Microsoft dieses Muster. Der Befehl ist auf einem dafür vorgesehenen Rechner mit Internetzugang in einer erhöhten PowerShell auszuführen:
certutil -syncWithWU \\SERVER\CTL-FREIGABEErsetze Server und Freigabe durch das vorbereitete Ziel; der ausführende Benutzer braucht Schreibrechte. Der Befehl lädt Dateien dorthin. Er konfiguriert die Clients nicht automatisch und belegt nicht, dass sie die Dateien bereits übernommen haben.
Plane Berechtigungen, Synchronisierung und Clientrichtlinien gemeinsam. Microsoft nennt für den Abruf insbesondere DNS-Auflösung und HTTP-Zugriff auf ctldl.windowsupdate.com. Neue Regeln sollten gezielt für den vorgesehenen Abrufrechner gelten. Die dokumentierten GPO-Einstellungen verschwinden nicht automatisch beim Entfernen einer GPO-Verknüpfung; dokumentiere deshalb auch die Rücknahme.
Edge prüfen und betroffene Dienste wieder funktionsfähig machen
In Edge kannst du unter edge://components den CRLSet-Eintrag prüfen. Das Trusted Root Program nennt die eMudhra-Maßnahme im Komponentenstand 2026.10.20 und bei Bedarf die dortige Updateprüfung. Eine bloße Browser-Versionsnummer erfasst diesen separaten Komponentenweg nicht.
Bleibt eine Anwendung nach den Vertrauensänderungen blockiert, dokumentiere Fehlermeldung, Zeitpunkt, Zertifikatskette und Anwendungsversion. Vergleiche die Kette mit den betroffenen Zertifikaten in der Herstellerliste. Eine neue Zertifikatskette oder ein Ersatzzertifikat sollte anschließend in genau der betroffenen Anwendung getestet werden. Unterschiedliche Anwendungen können unterschiedliche Vertrauensspeicher und Prüfverfahren verwenden.
Importiere betroffene Wurzeln nicht vorschnell wieder als vertrauenswürdig und schalte die Zertifikatsprüfung nicht ab. Bei anhaltenden Fehlern gehören die bereinigten Diagnoseausgaben und die konkrete Kette zum zuständigen Administrator oder Hersteller-Support.
Fazit
Der entscheidende Prüfpunkt ist der Weg, über den dein Windows-Gerät aktuelle Zertifikatslisten erhält. Für Online-Geräte zählen funktionierende automatische Vertrauensupdates; für isolierte Systeme braucht es eine kontrollierte Bereitstellung. Halte lokale Prüfung, Online-Vergleich und Anwendungstest auseinander. So lässt sich fehlender Schutz gezielter erkennen, ohne eine berechtigte Sperre durch einen unsicheren Workaround aufzuheben.