Secure Boot-certificaten en Hyper-V: waarom je Gen 2-VM's niet bijwerken, en wat er in 2026 stukgaat

1. De vraag over hostfirmware

De Secure Boot van een Generation 2-VM is volledig gevirtualiseerd. Hyper-V voorziet elke Gen 2-VM van zijn eigen virtuele UEFI-firmware, en Microsoft is er duidelijk over dat deze firmware losstaat van wat er op de fysieke host draait. Secure Boot en UEFI-firmware zijn op de host zelf niet vereist. De key stores van de VM zitten in de eigen NVRAM van de VM, die deel uitmaakt van de VM-configuratie, niet op het fysieke moederbord, en niet gedeeld met enige andere VM.

Hieruit volgen twee dingen, en zij zijn de reden voor dit hele onderwerp.

Ten eerste heeft de fysieke host geen hardware Secure Boot nodig, en geen BIOS- of systeemfirmware-update, om zijn guests de certificaten van 2023 te laten ontvangen. Een host met oude systeemfirmware en hardware Secure Boot uitgeschakeld kan zijn Gen 2-guests nog steeds van actuele certificaten voorzien en die bijwerken. Zeg het ook andersom, want dat is het stuk dat mensen verkeerd inschatten: een Gen 2-VM met Secure Boot ingeschakeld valt volledig binnen de scope van het 2023-certificaatwerk, zelfs wanneer de host Secure Boot uitgeschakeld heeft of niet ondersteunt. De toestand van de host beschermt de VM niet en stelt hem evenmin vrij. Als je hebt aangenomen dat hosts zonder Secure Boot hun VM's buiten scope plaatsen, dan is het tegendeel waar.

Ten tweede, omdat elke VM zijn eigen onafhankelijke NVRAM draagt, lost geen enkele actie op de host alle guests in één keer op. De host patchen reikt niet tot in de NVRAM van een draaiende VM. Elke guest, en elke template, is een aparte certificaatopslag die zich in een andere staat kan bevinden en die afzonderlijk gecontroleerd moet worden.

De twee vragen die door elkaar worden gehaald staan dus los van elkaar:

• Hardware Secure Boot en systeemfirmware van de host: irrelevant voor de vraag of guests de 2023-certificaten kunnen opnemen.
• Patchniveau van het host-OS, patchniveau van het guest-OS, en de NVRAM-status per VM: dat is het hele probleem.

De afhankelijkheid is software, op elk niveau, en zij is per VM.

2. De certificaatopslagplaatsen, en de overgang van 2011 naar 2023

Secure Boot bewaart zijn vertrouwen in vier UEFI-variabelen, en de meldingen in het event log slaan nergens op tot je weet wat elk ervan is.

PK, de Platform Key, is de enige rootsleutel die wijzigingen aan de KEK-lijst autoriseert. KEK, de Key Exchange Key, bevat de sleutels die de twee onderliggende signature-databases mogen bijwerken. DB is de database van toegestane handtekeningen, de certificaten waartegen een boot-component ondertekend moet zijn om te mogen draaien. DBX is het tegenovergestelde, de verboden database, een intrekkingslijst van handtekeningen die geweigerd moeten worden, ook als ze verder geldig zijn.

De vervanging is geen schone één-op-één-wissel, en daarom oogt de uitvoer druk. In de KEK wordt Microsoft Corporation KEK CA 2011 opgevolgd door Microsoft Corporation KEK 2K CA 2023. Deze ene sleutel is de poort: zonder de 2023-KEK op zijn plaats kan de guest de DB-updates die erna komen niet autoriseren. In de DB wordt de third-party Microsoft Corporation UEFI CA 2011 vervangen door twee 2023-certificaten, Windows UEFI CA 2023 en Microsoft UEFI CA 2023, waarbij de laatste de option ROMs dekt, en de ondertekenaar van de Windows Boot Manager, Microsoft Windows Production PCA 2011, verschuift naar het 2023-bootpad.

De praktische conclusie is kort: het boot-kritieke certificaat dat je moet bevestigen is Windows UEFI CA 2023 in de DB, en dat wordt afgeschermd door KEK 2K CA 2023 in de KEK. Als de 2023-KEK ontbreekt, landt er stroomafwaarts niets, ongeacht wat je binnen de guest instelt.

3. Wat de deadlines van 2026 en 2027 daadwerkelijk stukmaken

Wees hier precies, want de koppen overdrijven de directe impact en onderschatten de uiteindelijke, en juist de nuance laat je plannen in plaats van panikeren.

Een VM die na juni 2026 nog uitsluitend de 2011-certificaten vertrouwt, stopt op die datum niet met booten. Hij blijft normaal starten en draaien, en gewone Windows-updates blijven installeren. Op de dag zelf faalt er niets.

Wat hij verliest is de beveiligingsketen voor de vroege bootfase: updates voor de Windows Boot Manager, Secure Boot DB-updates, DBX-intrekkingslijst-updates, en mitigaties voor toekomstige boot-niveaukwetsbaarheden van de BlackLotus-klasse (CVE-2023-24932). Het systeem zit vast op zijn huidige bootpad-beveiligingsniveau, zonder manier om dat te verhogen.

De gevolgen zijn gefaseerd, en dat is het goede nieuws voor de planning. Microsoft heeft aangegeven dat beveiligingsupdates voor de Windows Boot Manager rond oktober 2026 stoppen met landen op systemen met het oude certificaat, en dat het verlopen van Windows Production PCA 2011 in 2027 volgt. Het toekomstgerichte risico dat het meeste telt is bootmedia: een OS-image, WinPE-build of herstelmedium dat uitsluitend tegen de 2023-certificaten is ondertekend, boot niet op een VM waarvan de DB die nooit heeft ontvangen. Dat is het scenario dat een uitgesteld klusje verandert in een Sev-1 tijdens een herstelactie, precies op het moment dat je grijpt naar media die een vastgelopen VM weigert te vertrouwen.

Geen van deze datums is deze week. Ze liggen allemaal dicht genoeg bij dat een geclusterde omgeving met honderden guests nu zou moeten inventariseren en in de komende onderhoudsvensters zou moeten herstellen, niet pas volgend jaar. Behandel het als gepland werk met een echte einddatum, niet als een noodgeval en niet als iets optioneels.

4. Waarom Windows Server zich niet gedraagt als Windows 11

Dit is het belangrijkste operationele verschil, en het is waar algemene richtlijnen serverbeheerders in de steek laten.

Op Windows 11 worden de 2023-certificaten in toenemende mate automatisch geleverd en toegepast via servicing. Op Windows Server, en dus op je Gen 2 Windows Server-guests, zitten ze vanaf 2024 in de cumulatieve updates maar worden ze niet automatisch toegepast. Server vereist een expliciete opt-in, omdat het onbeheerd toepassen van certificaatwijzigingen op server- en virtuele workloads een boot-risico met zich meebrengt dat Microsoft niet namens jou wilde nemen. De behoudende standaardinstelling is een bewuste keuze, en betekent dat er niets gebeurt tot je binnen elke guest in actie komt.

De opt-in is één registerwaarde die Windows opdraagt de 2023-certificaten uit te rollen en de boot manager bij te werken naar de 2023-ondertekende versie, terwijl het oude 2011-certificaat blijft staan in plaats van te worden ingetrokken. Het 2011-certificaat laten staan is precies wat je in dit stadium wilt.

# Inside the guest. Opt in to Secure Boot certificate deployment.
# This adds the 2023 certificates and updates the boot manager.
# It does NOT revoke the 2011 certificate (revocation is a later step).
$p = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
Set-ItemProperty -Path $p -Name AvailableUpdates -Value 0x5944 -Type DWord

Een achtergrondtaak verwerkt de wijziging op zijn eigen cyclus. Trigger hem in plaats van te wachten:

# Inside the guest. Run the servicing task that applies the update now.
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Daarna is een herstart vereist om de boot manager te laten overschakelen naar de 2023-ondertekende versie. Dit alles draait binnen elke guest. Niets ervan wordt voor je gedaan door de host te patchen.

5. De valkuil: bestaande Gen 2-VM's laten de KEK-update mislukken met Event ID 1795

Dit is het stuk dat echt onderbelicht is, en de reden dat dit artikel bestaat.

Nieuwe VM's die worden aangemaakt op een volledig gepatchte host, Windows Server 2025 of een actuele Windows 11 Hyper-V-host, worden bij het aanmaken geïnitialiseerd met zowel de 2011- als de 2023-certificaten, inclusief de 2023-KEK. Zij zijn vanaf dag één in orde.

Bestaande VM's worden niet bijgewerkt wanneer je de host patcht, omdat hun certificaatstatus in hun eigen NVRAM zit. Dus doe je het verstandige: je zet de register-opt-in binnen de guest, precies zoals je dat op fysieke hardware zou doen, draait de taak, herstart, en op een groot deel van de bestaande Server 2019- en Server 2022 Gen 2-VM's mislukt het.

Het kenmerk is Event ID 1795 in het System-log van de guest, met een strekking als: de systeemfirmware gaf een fout terug, de media is schrijfbeveiligd, bij een poging een Secure Boot-variabele KEK 2023 bij te werken. De virtuele UEFI weigert de KEK-schrijfactie. Omdat de 2023-KEK de poort is voor de DB-updates, loopt de hele keten vast. De opt-in lijkt geconfigureerd, de taak draait, en toch verschijnt Windows UEFI CA 2023 nooit in de DB.

Wat dit riskant maakt, is dat er op dat moment niets stuk is. De VM boot en draait. Je merkt het niet tenzij je gaat kijken, of tot een storing na de deadline de zaak afdwingt. Een heel cluster kan in deze staat zitten, opt-in gezet, certificaten niet daadwerkelijk toegepast, en er volledig gezond uitzien op elk dashboard dat je hebt.

6. De werkelijke status in kaart brengen over een cluster

Controleer dit programmatisch vanaf je beheerserver, de machine die al WMI-toegang heeft tot elke clusternode, zoals je VMM-server. Voor de host-zijdige enumeratie hieronder werkt dat schoon. De controles per guest liggen anders: het uitlezen van de firmware-variabelen van een guest vereist remoting naar de guest, dus draai die guest-lokaal waar het kan, of via je bestaande configuratiebeheerkanaal, in plaats van ze uit te waaieren over geneste remoting. Beheerserver naar host naar guest in één hop loopt tegen de Kerberos double-hop- en credential-delegatiegrenzen aan die de meeste omgevingen niet voor ad-hocwerk hebben ingericht, en het faalt doorgaans stilletjes. Loop de VM's niet één voor één na in de GUI, en vertrouw de registerwaarde niet als bewijs, want die legt alleen de intentie vast.

Inventariseer eerst, vanaf de beheerserver, welke VM's binnen scope vallen over alle nodes. Alleen Gen 2-VM's hebben UEFI en Secure Boot; Gen 1-VM's vallen volledig buiten scope.

# From the management server. Gen 2 VMs and their Secure Boot state, all nodes.
Get-ClusterNode -Cluster "HVCLUSTER01" | ForEach-Object {
  Get-VM -ComputerName $_.Name |
    Where-Object Generation -eq 2 |
    Get-VMFirmware |
    Select-Object @{n='Node';e={$_.ComputerName}}, VMName, SecureBoot, SecureBootTemplate
}

De gezaghebbende controle moet binnen de guest draaien, omdat de host niet in de toegepaste DB en KEK van de VM kan kijken. Bevestig in één keer zowel het boot-kritieke DB-certificaat als de KEK-poort:

# Inside the guest. True/True means on track. A False KEK is the 1795 signature.
$db  = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
$kek = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes)
[pscustomobject]@{
  DB_2023  = $db  -match 'Windows UEFI CA 2023'
  KEK_2023 = $kek -match 'KEK 2K CA 2023'
}

Draai die controle guest-lokaal over de omgeving, met de resultaten centraal verzameld, zodat je één tabel krijgt in plaats van een handmatige rondgang. Als je toch met Invoke-Command naar binnen reikt, houd dan rekening met de double-hop-grens die hierboven is genoemd. De VM's waar KEK_2023 op false staat zijn je hersteldoelen. Waar je de oorzaak bevestigd wilt zien in plaats van afgeleid, haal de gebeurtenis dan direct op:

# Inside the guest. Surface the write-protected KEK failure if present.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1795} -MaxEvents 5 -EA SilentlyContinue |
  Select-Object TimeCreated, Message

7. Herstel: de template-toggle, de opt-in, de verificatie

Wanneer een guest tegen de 1795-schrijfbeveiligingsfout aanloopt, zit de oplossing niet binnen de guest. Het is een Secure Boot-template-toggle die op de host wordt uitgevoerd en die de key store van de VM terugzet naar de template-standaarden. Op een actuele host bevatten die standaarden de 2023-certificaten, waarmee de vastgelopen KEK-store wordt vlotgetrokken.

Draai dit met de VM uitgeschakeld, tegen de eigenaarsnode:

# On the owning node. Reset the Secure Boot key store via template defaults.
# Toggle to the open CA template, then straight back to the Windows template.
Stop-VM -Name "VM01"
Set-VMFirmware -VMName "VM01" -SecureBootTemplate MicrosoftUEFICertificateAuthority
Set-VMFirmware -VMName "VM01" -SecureBootTemplate MicrosoftWindows
Start-VM -Name "VM01"

De volledige volgorde die betrouwbaar werkt op bestaande Server 2019- en 2022 Gen 2-VM's is: schakel de VM uit, toggle de template op de host, start de VM, zet de register-opt-in binnen de guest als die er nog niet is, draai de Secure-Boot-Update-taak, herstart de guest, en verifieer dan met de controle uit sectie 6. KEK_2023 zou nu true moeten teruggeven en DB_2023 zou moeten volgen. Het overslaan van de host-zijdige template-toggle is precies waarom de aanpak van alleen binnen de guest op deze VM's faalt.

8. De vTPM-kanttekening en de DBX-intrekvalkuil

Twee waarschuwingen die je een vervelende middag besparen, mogelijk een vervelend kwartaal.

Ten eerste, virtuele TPM. Als een Gen 2-VM een vTPM gebruikt, kun je de certificaten niet ter plekke bijwerken. De TPM-metingen die tijdens de boot worden gedaan nemen de certificaatstatus mee, dus het wijzigen van de certificaten maakt die metingen ongeldig, met directe gevolgen voor BitLocker en elke attestatie die erop steunt. Deze VM's moeten worden geherprovisioneerd naar een actuele image in plaats van getoggled. Identificeer ze op het moment van inventarisatie, want herprovisioning is een geplande activiteit met afhandeling van data en key protectors, geen klusje van vijf minuten. In een geclusterde omgeving is dit doorgaans de grootste afzonderlijke post in het herstelplan, een reden te meer om vroeg met inventarisatie te beginnen.

Ten tweede, haast je niet met de DBX-intrekking. Microsoft documenteert een handmatige procedure die het oude 2011-certificaat intrekt door het toe te voegen aan de DBX, de verboden database. Voer die intrekking niet uit als onderdeel van deze oefening. 2011 voortijdig intrekken kan bestaande bootmedia, WinPE-images, herstelschijven en provisioning-targets onbootbaar maken, omdat die nog tegen 2011 zijn ondertekend. De veilige volgorde is strikt: voeg de 2023-certificaten toe, valideer dat alles boot vanaf zowel de OS als je herstelmedia, en laat de intrekking over aan een veel latere, bewuste fase, zodra de hele omgeving en alle media bevestigd op 2023 zitten. Vertrouwen toevoegen is omkeerbaar en veilig. Het weghalen is waar omgevingen zichzelf onbruikbaar maken.

9. Templates, golden images, en versiespecifiek gedrag

De actie met de meeste hefboomwerking is je templates en golden images herstellen voordat je nog een draaiende VM aanraakt. Een ongepatchte template brengt nieuwe VM's voort die al achterlopen, zodat het probleem zich sneller reproduceert dan je het kunt herstellen.

Breng elke template op een actueel patchniveau, pas de template-toggle- en opt-in-behandeling toe als het Server 2019 of 2022 betreft, bevestig dat Windows UEFI CA 2023 aanwezig is in de DB met de controle uit sectie 6, en re-seal dan en hervat het uitrollen ervan.

Gedrag per versie, in het kort. Windows Server 2025-hosts initialiseren nieuwe VM's bij het aanmaken met beide certificaatsets, dus vers gebouwde VM's zijn schoon, maar bestaande VM's die naar 2025-hosts zijn gemigreerd worden niet met terugwerkende kracht hersteld en hebben nog steeds het werk per guest nodig. Windows Server 2022 en 2019 dragen de certificaten vanaf 2024 in de cumulatieve updates, passen niets automatisch toe, vereisen de opt-in, en zijn de versies die het meest vatbaar zijn voor de 1795-KEK-storing op bestaande VM's. Windows Server 2016 staat er het zwakst voor, met de dunste tooling- en servicingondersteuning voor deze overgang, dus behandel elke 2016 Gen 2-VM als iets dat individuele validatie vereist en, waar het kan, onderdeel van een migratieplan in plaats van een certificaatfix. Generation 1-VM's van welke versie dan ook zijn niet geraakt, zonder uitzondering.

Het patroon achter de lijst

Dit is een bekende vorm. Een langlevend cryptografisch artefact, uitgegeven en vergeten in 2011, bereikt stilletjes het einde van zijn leven en verandert in een omgevingsbrede operationele deadline. Vandaag staat er niets in brand, en juist dat maakt het makkelijk om uit te stellen: de kosten van niets doen blijven onzichtbaar tot precies het moment waarop een VM niet vanaf nieuwe media wil booten, of een bootpad-kwetsbaarheid landt zonder patchpad op een omgeving die de fix niet meer kan opnemen.

De vraag over hostfirmware versterkt het, want die stuurt mensen naar het moederbord terwijl het antwoord zit in patchpariteit en NVRAM-status per VM. In een geclusterde Hyper-V-omgeving zijn dat tientallen of honderden onafhankelijke certificaatopslagplaatsen, die elk stilletjes kunnen falen met de opt-in gezet en de certificaten nog afwezig. Het werk is methodisch in plaats van heldhaftig, en er is tijd om het methodisch te doen: inventariseer elke Gen 2-guest en template vanaf je beheerserver, verifieer de werkelijke DB- en KEK-status in plaats van het register te vertrouwen, herstel bestaande VM's met de template-toggle, plan de vTPM-herprovisioning als een apart traject, en laat de DBX-intrekking voor het laatst.

Plan een kennismaking voor een Hyper-V cluster assessment →