Microsoft Secureboot Zertifikate Panik. Was wirklich zu tun ist

Da das Thema doch oft noch bei mir angesprochen wird, hier mal die ausführliche Version meiner Einschätzung.

NEIN, die VMs bleiben nicht einfach stehen

NEIN es explodiert auch nichts ;)

JA es kann auf längere Sicht zu Problemen oder Sicherheitseinschränkungen führen wenn Systeme der neuen CA nicht vertrauen. Microsoft hat das hier entsprechend beschrieben: Windows Secure Boot certificate expiration and CA updates.

Kurz zur Einordnung, worum es überhaupt geht. Die ursprünglichen Secure Boot Zertifikate von Microsoft wurden 2011 ausgestellt und laufen jetzt nach und nach aus:

Microsoft Corporation KEK CA 2011 und Microsoft Corporation UEFI CA 2011 -> Ablauf 27. Juni 2026
Microsoft Windows Production PCA 2011 –> Ablauf 19. Oktober 2026

Wichtig dabei: das ist kein harter Stichtag, an dem Geräte aufhören zu booten. Betroffene Systeme laufen einfach weiter, bekommen aber keine neuen Boot-Sicherheitsupdates mehr.

Was genau jetzt zu tun ist

1. Prüfen ob alle Windows Server die neuen Zertifikate bereits haben

Anders als beim Client läuft das bei Server NICHT automatisch über Windows Update. Das muss aktiv geprüft und gegebenenfalls angestoßen werden. Bei Server 2019 sind die Zertifikate zwar schon seit Mai 2024 in den monatlichen Cumulative Updates enthalten, werden aber oft nicht automatisch angewendet, um Boot-Probleme auf älterer Hardware oder in virtuellen Umgebungen zu vermeiden.

Den Status pro Server kann man direkt per PowerShell checken:

Confirm-SecureBootUEFI; if ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023') { "OK - 2023 CA aktiv" } else { "ACHTUNG - nur 2011 CA" }

Wer mehrere Server auf einmal prüfen will, habe ich ein kleines Skript welches per Remote PowerShell die Server abfragt:

Infrastructure-Toolkit/Microsoft/Operations/Check-SecureBoot-CA.ps1 auf GitHub

.\check-secureboot-ca.ps1 -ComputerName Test-Server-01,Test-Server-02,Test-Server-03

$vms = (Get-ADComputer -Filter {OperatingSystem -like "*Server*"}).Name
.\check-secureboot-ca.ps1 -ComputerName $vms

Ergebnis des Secure Boot CA Checks

Status-Übersicht

Status zeigt das Endergebnis auf einen Blick, ServicingStatus kommt direkt aus der Registry:

Updated: 2023 CA vollständig aktiv, nichts zu tun
InProgress: Prozess läuft, aber noch nicht abgeschlossen. Ein Reboot hat hier in der Praxis immer geholfen
leer: Registry-Key nicht vorhanden, entweder wurde die VM auf einem bereits gepatchten Host neu erstellt oder der Servicing-Mechanismus ist noch nicht angelaufen
Status: WARNING – 2011 CA only: 2023 CA fehlt noch in der UEFI db, manueller Trigger notwendig

Falls bei einem Server nichts automatisch updatet, kann der Prozess manuell angestoßen werden:

reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

Schon fast alles auf Updated ohne Registry Key?

Neuere kumulative Updates (2022, 2025) bringen den Servicing-Mechanismus inzwischen oft selbst mit. Vor allem VMs, die erst kürzlich auf einem bereits gepatchten Host erstellt wurden, starten direkt mit beiden Zertifikaten. Der manuelle Registry-Trigger ist eher der Notfallhebel für Systeme, die nicht von selbst durchlaufen.

2. Bei VMs mit virtuellem TPM und oder Bitlocker Einsatz genauer hinschauen

Das gilt für Hyper-V und VMware gleichermaßen. Jede VM mit aktivem vTPM muss im Zweifel neu provisioniert werden, weil die Zertifikate Teil der TPM Measurements beim Boot sind. Ein nachträgliches Update von außen kann hier BitLocker Recovery auslösen, das will eigentlich niemand im Produktivbetrieb erleben.

3. Hyper-V: bestehende VMs übernehmen das neue KEK nicht automatisch vom Host

Das ist der Punkt, der in den meisten Artikeln zu kurz kommt. Neu erstellte VMs auf einem gepatchten Host starten direkt mit beiden Zertifikaten. Bestehende VMs dagegen nicht, Microsofts Position dazu ist, dass ein neuer Trust Root nur auf neue VMs angewendet werden kann.

In der Praxis gibt’s trotzdem einen Workaround ohne Neuerstellung der VM, allerdings nirgends offiziell dokumentiert, sondern aus dem Community Forum:

VM herunterfahren
Secure Boot Template in den VM Settings auf “Microsoft UEFI Certificate Authority” umstellen, übernehmen
Template wieder zurück auf “Microsoft Windows” stellen, übernehmen
VM starten

Danach ist das KEK aktualisiert.

Secure Boot Template Dialog in den Hyper-V VM Settings

Diagnose per Eventlog

Event ID 1795 mit der Meldung “media is write protected” beim Versuch, die Secure Boot Variable KEK 2023 zu aktualisieren, ist das typische Symptom für hängende Updates in Hyper-V VMs.

4. VMware: Broadcom übernimmt das Platform Key Update, KEK/DB bleiben Sache des Gast-OS

Broadcom VMware übernimmt das Platform-Key-Update am Hypervisor automatisiert per CU. KEK und DB bleiben aber weiterhin Aufgabe des Windows Patchings im Gast, genau wie überall sonst auch. Bei Windows VMs läuft das in der Regel sauber im Hintergrund, sofern das KEK CA 2011 und UEFI CA 2011 bereits in der vUEFI vorhanden sind.

NULL Platform Key bei älteren VMs

Ein Stolperstein, der gerne übersehen wird: VMs, die vor ESXi 8.0.2 erstellt wurden, haben oft einen NULL Platform Key im NVRAM, quasi einen Platzhalter ohne echten Owner. Ohne gültigen PK kann auch kein KEK Update autorisiert werden, der ganze automatische Mechanismus läuft dann ins Leere. Hier hilft nur ein manuelles PK Update am Hypervisor, bevor überhaupt irgendwas in Richtung KEK/DB passieren kann.

Workaround bei NULL PK: NVRAM Datei umbenennen statt löschen, ESXi regeneriert sie beim nächsten Boot mit den 2023er Zertifikaten (ab ESXi 8.0.2). Vorher Snapshot ziehen, bei vTPM/Bitlocker Recovery Key bereithalten.

Quelle dazu direkt von Broadcom: Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines

Fazit

Kein Grund zur Panik, aber auch kein Thema, das man einfach aussitzen sollte. Wer jetzt einmal sauber durchprüft, spart sich in ein paar Monaten den Stress, wenn plötzlich Boot Manager Updates oder neue OS Versionen nicht mehr installiert werden können, weil die alte CA nicht mehr vertraut wird.

Skript gibt’s wie immer offen auf GitHub, Feedback und Verbesserungsvorschläge sind willkommen.