Microsoft tauscht die UEFI-Secure-Boot-Zertifikate von 2011 gegen die 2023er-Generation; die ersten alten Zertifikate laufen ab dem 24. Juni 2026 ab. Auf virtuellen Windows-Servern unter VMware pflegt kein OEM die Firmware-Variablen, Sie müssen selbst ran. Hier das praxiserprobte Verfahren für VMs ab vmx-19 (Windows Server 2019 bis 2025 verhalten sich identisch) inklusive des fast immer nötigen Platform-Key-Enrollments. Hintergrund: Secure-Boot-Zertifikate laufen am 24. Juni 2026 ab.

Beispiel: vCenter vcenter-1 mit ESXi 8.0.x, Zertifikate auf \\fileserver\certs\UEFI-Certs. Befehle laufen als Administrator in der VM, das Inventar per PowerCLI.

Worum es geht – und warum am Stichtag nichts ausfällt

Das 2011er-Zertifikat, das den Windows-Bootmanager signiert, läuft 2026 aus. Am Ablauftag fällt aber nichts aus: Secure Boot prüft zur Boot-Zeit kein Ablaufdatum, die Firmware hat keine vertrauenswürdige Uhr. Ein 2011-signierter Bootmanager validiert weiter, solange das 2011-Zertifikat in der DB liegt.

Damit der Server künftige Boot-Security-Updates (neue Bootmanager, DBX-Revocations) annimmt, müssen die 2023er-Zertifikate in die Firmware-Variablen. Drei Bausteine:

DB – die Signaturdatenbank bekommt die 2023er-CAs.
KEK (Key Exchange Key) – erlaubt künftige DB-/DBX-Updates und braucht eine gültige Autorisierung durch den Platform Key (PK).
Bootmanager – wird durch die 2023-signierte Variante ersetzt.

Gesteuert wird über den Registry-Wert AvailableUpdates und eine vorhandene geplante Aufgabe; jedes Bit ist ein Teilschritt und wird nach Erfolg gelöscht.

Das einzige echte Risiko ist ein Reset der UEFI-Variablen bzw. des NVRAM („Clear Secure Boot Keys“, Firmware-Defaults). Nutzt eine VM bereits den 2023-Bootmanager, fehlen danach die enrollten Schlüssel und sie bootet nicht mehr. NVRAM umgestellter VMs niemals zurücksetzen.

Voraussetzungen und Sicherheitsregeln

Sie brauchen:

ESXi 8.0 U2 oder neuer auf den Hosts.
VMs mit Firmware = EFI und aktivem Secure Boot (BIOS-VMs sind nicht betroffen).
Die Zertifikatsdateien WindowsOEMDevicesPK.der („Windows OEM Devices PK“) und KEK-2023.der („Microsoft Corporation KEK 2K CA 2023“).
PowerCLI auf der Admin-Maschine:

Install-Module VMware.PowerCLI -Scope CurrentUser -AllowClobber -Force
Set-PowerCLIConfiguration -InvalidCertificateAction Prompt -Scope User
Connect-VIServer -Server vcenter-1

Sicherheitsregeln für das gesamte Verfahren:

Produktivsysteme einzeln, nie parallel an mehreren kritischen VMs.
Vor jedem schreibenden Schritt ein Snapshot, bevorzugt ausgeschaltet (sichert das NVRAM konsistent).
vCenter-Webkonsole offen halten bei Arbeiten an Boot-Pfad oder EFI; RDP geht beim Reboot verloren.
Bei Event 1803 niemals rebooten, bevor der Platform Key repariert ist (Schritt 5).
Der VMX-Parameter uefi.allowAuthBypass wird nach dem PK-Enrollment zwingend wieder entfernt.
Kein Zeitdruck; an jedem Kontrollpunkt verifizieren.

Schritt 1: Inventar der VM-Flotte (read-only)

Hosts auf die Versions-Schwelle prüfen:

Get-VMHost | Select Name, Version, Build | Format-Table -AutoSize

Alle VMs mit Firmware, Secure-Boot-Status und Hardware-Version erfassen. Get-View ist zuverlässiger als die direkte Property, die bei Bulk-Abfragen leer bleiben kann:

Get-View -ViewType VirtualMachine -Property Name,Config.Firmware,Config.BootOptions,Config.Version |
  Select Name,
    @{N='HwVersion';E={$_.Config.Version}},
    @{N='Firmware';E={$_.Config.Firmware}},
    @{N='SecureBoot';E={$_.Config.BootOptions.EfiSecureBootEnabled}} |
  Sort Firmware, Name | Format-Table -AutoSize

Im Scope sind nur VMs mit Firmware = efi und SecureBoot = True. Appliances (etwa Linux-basierte Netzwerk- oder NAC-Geräte) versorgt der Hersteller, auch mit aktivem Secure Boot.

Verifizieren: Die Host-Liste zeigt überall ESXi 8.0 U2 oder neuer, und Sie haben eine Liste aller VMs mit Firmware = efi und SecureBoot = True. Nur diese VMs bearbeiten Sie in den folgenden Schritten.

Schritt 2: Ist-Zustand in der VM prüfen (read-only)

In der Ziel-VM als Administrator zeigt diese Abfrage alles Entscheidende:

"--- $env:COMPUTERNAME ---"
Confirm-SecureBootUEFI
Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update' | Select State
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Windows UEFI CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match '2023'
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' `
  -Name UEFICA2023Status,UEFICA2023Error -EA SilentlyContinue |
  Select UEFICA2023Status,UEFICA2023Error

Auswertung:

Ergebnis	Bedeutung
`Confirm-SecureBootUEFI = True`	Secure Boot aktiv – die VM ist im Scope
Aufgabe `Secure-Boot-Update` = `Ready`	Der Update-Mechanismus ist vorhanden
Aufgabe fehlt	Zuerst ein aktuelles kumulatives Update einspielen und neu starten – ohne die Aufgabe gibt es keinen Mechanismus, der die Zertifikate schreibt
DB-/KEK-Check = `False`	2023er-Zertifikate fehlen noch – volles Verfahren nötig
Platform Key nicht als Zertifikat lesbar	Vorbote für das PK-Problem (Event 1803) – das Enrollment in Schritt 5 fest einplanen

Erfahrungswert: Bei vmx-19-Bestands-VMs ist ein nicht lesbarer Platform Key der Regelfall; planen Sie das Enrollment aus Schritt 5 fest ein.

Verifizieren: Confirm-SecureBootUEFI liefert True und die Aufgabe Secure-Boot-Update steht auf Ready. Ist beides nicht der Fall, gehört die VM nicht in dieses Verfahren oder braucht zuerst ein kumulatives Update.

Schritt 3: DB-Zertifikat einspielen (Trigger 0x40)

Der defensive erste Schritt setzt nur das primäre DB-Zertifikat, noch nicht KEK und Bootmanager. Zuerst Snapshot (z. B. „vor SecureBoot DB-Cert“), dann Trigger setzen und Aufgabe starten:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates -Value 0x40
Start-ScheduledTask -TaskName '\Microsoft\Windows\PI\Secure-Boot-Update'
Start-Sleep -Seconds 45
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates | Select AvailableUpdates

AvailableUpdates fällt nach Erfolg auf 0. Dann kontrollierter Reboot mit offener Konsole (Server 2019 braucht gelegentlich zwei), anschließend verifizieren:

Confirm-SecureBootUEFI                                                                          # True
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'   # True

Erfolgssignal (Protokoll „System“, Quelle „Microsoft-Windows-TPM-WMI“): Event 1036, „Update für sicheren Start von Db erfolgreich angewendet“.

Verifizieren: Nach dem Neustart liefern beide Prüfbefehle True, AvailableUpdates steht auf 0, und im Protokoll „System“ findet sich Event 1036 der Quelle „Microsoft-Windows-TPM-WMI“.

Schritt 4: KEK und Bootmanager anstoßen (Trigger 0x5944)

Dieser Lauf bringt die restlichen DB-Zertifikate, den KEK 2023 und den 2023-signierten Bootmanager. Wieder frischer Snapshot, Trigger setzen, Aufgabe starten, Events lesen:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates -Value 0x5944
Start-ScheduledTask -TaskName '\Microsoft\Windows\PI\Secure-Boot-Update'
Start-Sleep -Seconds 60
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates | Select AvailableUpdates
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-TPM-WMI'; StartTime=(Get-Date).AddMinutes(-5)} |
  Where {$_.Id -in 1043,1044,1045,1799,1800,1801,1803,1795,1796} |
  Select TimeCreated, Id, Message | Format-List

Entscheidungspunkt:

Event 1803 („kein PK-signierter KEK gefunden“): Nicht rebooten. Trigger zurücksetzen, weiter mit Schritt 5.
Kein 1803, stattdessen Event 1799 („Bootmanager 2023 installiert“): direkt weiter zu Schritt 6.

# Nur bei Event 1803: Trigger zurücksetzen, NICHT neu starten
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates -Value 0

Server 2025 formuliert die Events leicht anders („Ursache: Boot Manager“).

Verifizieren: Die Event-Abfrage zeigt entweder 1803 (weiter mit Schritt 5, AvailableUpdates steht danach wieder auf 0) oder 1799 (weiter mit Schritt 6). Zeigt sie keines von beiden, starten Sie die Aufgabe nach einigen Minuten erneut und lesen die Events noch einmal.

Schritt 5: Platform-Key-Enrollment (nur bei Event 1803)

Ursache von Event 1803: Der Platform Key der VM hat eine ungültige Signatur und kann KEK-Updates nicht autorisieren. Lösung: „Windows OEM Devices PK“ und 2023er-KEK manuell über die Firmware enrollen.

Vorab: Ist ein vTPM mit TPM-versiegelter Verschlüsselung (etwa BitLocker) aktiv, Recovery-Key sichern oder Verschlüsselung temporär aussetzen; das PK-Enrollment ändert die Platform-Ownership und kann sonst eine Recovery auslösen.

Hilfsdisk anlegen und Zertifikate laden

VM herunterfahren, separaten Snapshot anlegen, eine 128-MB-Disk anhängen (Edit Settings → Add New Device → Hard Disk) und hochfahren. Die neue Disk eindeutig identifizieren (exakt 134217728 Byte) und mit FAT32 formatieren:

Get-Disk | Select Number, Size, OperationalStatus        # die Disk mit 134217728 Byte ist die neue
$n = <Nummer>                                            # NUR die 128-MB-Disk!
Set-Disk -Number $n -IsOffline $false
Set-Disk -Number $n -IsReadOnly $false
Initialize-Disk -Number $n -PartitionStyle MBR -EA SilentlyContinue
$part = New-Partition -DiskNumber $n -UseMaximumSize -AssignDriveLetter
Format-Volume -DriveLetter $part.DriveLetter -FileSystem FAT32 -NewFileSystemLabel KEYUPDATE -Confirm:$false
"Laufwerk: $($part.DriveLetter):"

Zertifikate kopieren und Subjects prüfen:

$drive = '<Buchstabe>:'
Copy-Item '\\fileserver\certs\UEFI-Certs\WindowsOEMDevicesPK.der' "$drive\"
Copy-Item '\\fileserver\certs\UEFI-Certs\KEK-2023.der' "$drive\"
(New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$drive\WindowsOEMDevicesPK.der")).Subject
(New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$drive\KEK-2023.der")).Subject

Erwartung: CN=Windows OEM Devices PK und CN=Microsoft Corporation KEK 2K CA 2023.

Tipp: Die Disk mit beiden .der-Dateien als VMDK aufheben und an die nächste VM hängen; dokumentieren, wo sie hängt, danach immer abhängen.

EFI vorbereiten und enrollen

VM ausschalten, in vCenter:

VMX-Parameter uefi.allowAuthBypass = TRUE setzen (Edit Settings → Advanced Parameters).
Force EFI Setup aktivieren (VM Options → Boot Options).
VM einschalten und die Webkonsole öffnen.

Im EFI-Menü dann:

Secure Boot Configuration → PK Options → Enroll PK → Volume KEYUPDATE → WindowsOEMDevicesPK.der → Commit/Yes
Esc → KEK Options → Enroll KEK → KEK-2023.der → Commit/Yes
Esc → Boot normally

VMware committet sofort, globales Speichern ist nicht nötig. Achten Sie auf eine Bestätigung pro Enroll und keinen roten Fehler.

Enrollment verifizieren

Nach dem Hochfahren in Windows:

$pk = Get-SecureBootUEFI -Name PK
$cert = $pk.Bytes[44..($pk.Bytes.Length-1)]
[IO.File]::WriteAllBytes("$env:TEMP\PK.der", $cert)
(New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$env:TEMP\PK.der")).Subject   # Windows OEM Devices PK
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match '2023'                            # True
Confirm-SecureBootUEFI                                                                                    # True

Aufräumen – Reihenfolge einhalten

VM herunterfahren.
VMX-Parameter uefi.allowAuthBypass entfernen – der am häufigsten vergessene Schritt, deshalb zuerst.
Force EFI Setup deaktivieren.
Die 128-MB-Disk abhängen (Identität dreifach prüfen).
Einschalten und gegenchecken:

Get-Disk | Select Number, Size, OperationalStatus                                 # Hilfsdisk weg
Confirm-SecureBootUEFI                                                            # True
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match '2023'    # True

Verifizieren: Der PK-Check zeigt CN=Windows OEM Devices PK, KEK-Check und Confirm-SecureBootUEFI liefern True, die Hilfsdisk fehlt in Get-Disk, und in den Advanced Parameters der VM steht kein uefi.allowAuthBypass mehr.

Schritt 6: Finaler Lauf und Schluss-Verifikation

Jetzt läuft der Bootmanager-Schritt durch. Snapshot (z. B. „nach PK-Enrollment, vor finalem 0x5944“), dann Trigger erneut setzen:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates -Value 0x5944
Start-ScheduledTask -TaskName '\Microsoft\Windows\PI\Secure-Boot-Update'
Start-Sleep -Seconds 60
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates | Select AvailableUpdates
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-TPM-WMI'; StartTime=(Get-Date).AddMinutes(-5)} |
  Where {$_.Id -in 1799,1803,1795,1796} | Select TimeCreated, Id, Message | Format-List

Erwartung: Event 1799, kein 1803, AvailableUpdates = 0x4000.

Wichtig: Event 1799 erscheint oft schon vor dem Reboot und bedeutet „installiert/gestaged“, nicht „wirksam“. Erst der Neustart aktiviert den Bootmanager; danach verifizieren, nie vorher „fertig“ melden:

Restart-Computer

Schluss-Verifikation nach dem Neustart:

Confirm-SecureBootUEFI
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Windows UEFI CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match '2023'
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates | Select AvailableUpdates

Verifizieren: Nach dem finalen Neustart liefern alle drei Checks True, AvailableUpdates steht auf 0x4000, und seit dem Neustart ist kein Event 1803, 1795 oder 1796 hinzugekommen.

Woran Sie erkennen, dass die VM wirklich fertig ist

Irrtum: Die Signatur von bootmgfw.efi belegt den Erfolg nicht. Die Datei bleibt unter C:\Windows\Boot und auf der EFI-System-Partition oft 2011-signiert, auch bei korrekt umgestellten VMs. Belastbar sind:

Confirm-SecureBootUEFI = True – die VM bootet mit aktivem Secure Boot.
DB-Check 2023 = True und KEK-Check 2023 = True.
UEFICA2023Status = Updated (ideal) oder Event 1799 plus AvailableUpdates = 0x4000 (fachlich fertig).
Kein UEFICA2023Error, kein Event 1803/1795/1796 mehr.

Referenz: AvailableUpdates-Bits und Event-IDs

0x5944 ist die Summe aller Teilschritte; jedes Bit wird nach Erfolg gelöscht:

Bit	Aktion
`0x0040`	Windows UEFI CA 2023 in die DB (entspricht dem 0x40-Einzelschritt)
`0x0800`	Microsoft Option ROM UEFI CA 2023 in die DB
`0x1000`	Microsoft UEFI CA 2023 in die DB
`0x0004`	KEK 2K CA 2023 anwenden (braucht einen gültigen PK!)
`0x0100`	2023-signierten Bootmanager installieren
`0x4000`	Internes Steuer-Bit (bleibt teils stehen, unkritisch)

Wichtigste Event-IDs (Protokoll „System“, Quelle „Microsoft-Windows-TPM-WMI“):

Event	Bedeutung
1036	DB-Update erfolgreich angewendet
1044 / 1045	Option-ROM- bzw. UEFI-CA-2023-Eintrag in der DB angewendet
1799	Bootmanager 2023 installiert (gestaged – erst nach Reboot wirksam)
1800	Neustart erforderlich (Boot Manager 2023)
1801	Zertifikate verfügbar, noch nicht auf die Firmware angewendet
1803	Kein PK-signierter KEK – PK-Enrollment nötig, nicht rebooten
1795 / 1796	Firmware-Fehler beim Update – Firmware, NVRAM und PK prüfen

Stolpersteine aus der Praxis

uefi.allowAuthBypass nicht entfernt. Kein Boot-Risiko, aber eine Sicherheits-Schwächung; beim nächsten nötigen Power-Off herausnehmen (nur ausgeschaltet änderbar).
Bootmanager-Schritt hängt mit 0x8007007E (ERROR_MOD_NOT_FOUND, Status InProgress). Nicht erzwingen: kein bcdboot, keine Operationen an der EFI-System-Partition. Aufgabe ein- bis zweimal neu starten, sonst Trigger auf 0 und parken: DB, KEK und PK sind der eigentliche Schutz, die etwa alle 12 Stunden laufende Aufgabe zieht den Bootmanager oft selbst nach.
Falsche Disk formatiert. Die 128-MB-Disk immer über die exakte Größe (134217728 Byte) verifizieren, gerade bei vielen Datenplatten.
„Nach Muster“ durchwinken. Vor jedem PK-Enrollment Event 1803 bestätigen.

Fazit

Rechnen Sie pro VM mit Platform-Key-Enrollment mit etwa 20 bis 30 Minuten inklusive Reboots; mit Routine und wiederverwendbarer KEYUPDATE-Disk geht es schneller. Der EFI- und Reboot-Teil bleibt bewusst manuell und pro VM einzeln. Maßgeblich bleiben die Microsoft-Quellen (aka.ms/GetSecureBoot) und die KB-Artikel des Virtualisierungsherstellers.

Weiterführend: PowerShell-Grundlagen für Windows-Admins, virtuelle Maschinen und Checkpoints unter Hyper-V (gleiche Zertifikatslogik, andere Werkzeuge) und vor Arbeiten an Boot-Pfaden ein Windows-Server-Backup mit getesteter Wiederherstellung.