Secure Boot 2023: UEFI-Zertifikate auf Windows-Server-VMs unter VMware umstellen

Microsoft tauscht die UEFI-Secure-Boot-Zertifikate von 2011 gegen die 2023er-Generation; die ersten alten Zertifikate sind am 24. Juni 2026 abgelaufen. 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.

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.

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:

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

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“.

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“).

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.

EFI vorbereiten und enrollen

VM ausschalten, in vCenter:

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

Im EFI-Menü dann:

1. Secure Boot Configuration → PK Options → Enroll PK → Volume KEYUPDATE → WindowsOEMDevicesPK.der → Commit/Yes
2. Esc → KEK Options → Enroll KEK → KEK-2023.der → Commit/Yes
3. 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

1. VM herunterfahren.
2. VMX-Parameter uefi.allowAuthBypass entfernen (der am häufigsten vergessene Schritt, deshalb zuerst).
3. Force EFI Setup deaktivieren.
4. Die 128-MB-Disk abhängen (Identität dreifach prüfen).
5. 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

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.

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

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:

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

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.

Typische Fehler

Die Event-Meldungen stehen im Protokoll „System“ (Quelle „Microsoft-Windows-TPM-WMI“) und sind im englischen Wortlaut aus der Microsoft-Dokumentation wiedergegeben. Die letzte Meldung stammt aus der Broadcom-Dokumentation und erscheint beim Enrollment im EFI-Menü.

Event 1803: A PK-signed Key Exchange Key (KEK) cannot be found for this device.

Der Platform Key der VM kann den neuen KEK nicht autorisieren. Laut Broadcom haben VMs, die auf ESXi vor 9.0 angelegt wurden, standardmäßig einen Platform Key mit NULL-Signatur. Nicht neu starten, Trigger auf 0 setzen und das Enrollment aus Schritt 5 durchführen.

Event 1801: Secure Boot certificates have been updated but are not yet applied to the device firmware.

Windows hat die 2023er-Zertifikate bereit, in der Firmware der VM sind sie noch nicht angekommen. Broadcom nennt als Ursachen einen abgelaufenen oder fehlenden KEK und einen ungültigen Platform Key. Den Stand wie in Schritt 2 prüfen und die Schritte 3 bis 6 abarbeiten.

Event 1795: The system firmware returned an error <firmware error code> when attempting to update a Secure Boot variable.

Die Firmware hat das Schreiben von DB, DBX oder KEK abgelehnt, Windows versucht es beim nächsten Neustart erneut. Firmware, NVRAM (nicht zurücksetzen) und Platform Key prüfen; bei VMware-VMs stellt VMware die Firmware, maßgeblich ist dann die Broadcom-KB 423893.

Event 1796: The Secure Boot update failed to update <event type> with error <error code>.

Ein unerwarteter Fehler beim Update, Windows wiederholt den Versuch beim nächsten Neustart. Broadcom führt in KB 423919 1796 wie 1803 als Symptom eines fehlenden gültigen Platform Keys; in dem Fall hilft das Enrollment aus Schritt 5.

Event 1800: A reboot is required before installing the Secure Boot update: <event type>.

Eine vorherige Änderung, etwa ein Bootmanager-Update, braucht erst einen Neustart. Kontrolliert neu starten (Konsole offen) und die Aufgabe danach erneut anstoßen.

Event 1032: The Secure Boot update <event type> was not applied due to a known incompatibility with the current BitLocker configuration.

Das Update würde BitLocker in die Wiederherstellung schicken und wurde deshalb nicht angewendet. Recovery-Key sichern und BitLocker für zwei Neustarts aussetzen, wie es Microsoft in KB 5016061 beschreibt.

Only DER encoded certificate file (*.cer/der/crt) is supported

Die Meldung kommt beim Enrollment, wenn die Zertifikatsdatei nicht im DER-Format vorliegt oder beschädigt ist. Laut Broadcom die .der-Datei neu herunterladen und erneut auf die KEYUPDATE-Disk kopieren.

Häufige Fragen

Bootet die VM nach dem Ablauf der 2011er-Zertifikate noch?

Ja. Microsoft schreibt, dass nicht umgestellte Geräte weiter starten und normal arbeiten, Broadcom bestätigt das für VMware-VMs. Sie bekommen aber keine neuen Schutzupdates für den frühen Bootvorgang mehr (KB 5062710, KB 423893).

Welche Zertifikate laufen wann ab?

Laut Microsoft: Microsoft Corporation KEK CA 2011 am 24. Juni 2026 (Nachfolger Microsoft Corporation KEK 2K CA 2023), Microsoft UEFI CA 2011 am 27. Juni 2026 (Nachfolger Microsoft UEFI CA 2023 und Microsoft Option ROM UEFI CA 2023), Microsoft Windows Production PCA 2011 am 19. Oktober 2026 (Nachfolger Windows UEFI CA 2023).

Gibt es einen automatischen Weg ohne Enrollment im EFI-Menü?

Broadcom beschreibt in KB 423893 ab ESX 8.0 U3j ein SilentPK-Update für VMs ohne vTPM, der Platform Key wird dann beim Neustart der VM gesetzt. Ab ESX 9.1.1.0 gibt es für die dort genannten Windows-Versionen mit vTPM ein Capsule-PK-Update, das VMware Tools 13.1.5 und das Windows-Kumulativupdate von Juli 2026 oder neuer voraussetzt. Von der manuellen VMX-Methode für VMs mit vTPM rät Broadcom bei Windows-VMs ab und empfiehlt dort, auf eine automatische Lösung in einem künftigen Release zu warten.

Welche Hardware-Version braucht die VM?

Alle PK-Update-Wege von Broadcom setzen Hardware-Version 14 oder neuer voraus, weil erst sie das nötige virtuelle NVRAM bietet. VMs mit Hardware-Version 13 heben Sie vorher an, bis Version 12 gibt es kein Secure Boot.

Hilft es, das NVRAM der VM zu löschen?

Nein. Broadcom hat seine frühere Anleitung durch KB 423919 ersetzt, um Hinweise auf das Löschen des NVRAM zu vermeiden, weil das die VM beschädigen kann. Bei VMs, die schon den 2023-Bootmanager nutzen, fehlen danach außerdem die enrollten Schlüssel und sie booten nicht mehr.

Warum zeigt bootmgfw.efi nach der Umstellung noch die 2011-Signatur?

Laut Broadcom können Get-AuthenticodeSignature auf bootmgfw.efi und der Registry-Wert WindowsUEFICA2023Capable einen falschen Stand melden. Maßgeblich ist laut Broadcom der Registry-Wert UEFICA2023Status (KB 436896), laut Microsoft steht Updated für den erfolgreichen Abschluss (KB 5068202).

Wie lange dauert es ohne manuellen Anstoß?

Die Aufgabe Secure-Boot-Update läuft laut Microsoft alle 12 Stunden. Microsoft rechnet mit etwa 48 Stunden und einem oder mehreren Neustarts, bis die Zertifikate angewendet sind, sobald das Gerät für das Update vorgesehen ist (KB 5062713).

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ührende Anleitungen und Quellen

• PowerShell-Grundlagen für Windows-Admins
• BitLocker im Betrieb ausrollen und Recovery-Keys verwalten
• Windows Server Backup einrichten und Wiederherstellung testen
• Hyper-V: virtuelle Maschine erstellen und Checkpoints nutzen (gleiche Zertifikatslogik, andere Werkzeuge)
• Microsoft: Windows Secure Boot certificate expiration and CA updates (KB 5062710)
• Microsoft: Secure Boot Certificate updates: Guidance for IT professionals (KB 5062713)
• Microsoft: Registry key updates for Secure Boot (KB 5068202)
• Microsoft: Secure Boot DB and DBX variable update events (KB 5016061)
• Broadcom: Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines (KB 423893)
• Broadcom: Manual Update of the Secure Boot Platform Key in Virtual Machines (KB 423919)
• Broadcom: Windows secure boot 2023 certificate verification discrepancies (KB 436896)