Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines
search cancel

Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines

book

Article ID: 423893

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

Secure Boot certificate update failures or warnings in VMware virtual machines as Microsoft Secure Boot certificates approach expiration.

One or more of the following symptoms may be present:

  • Windows Event Viewer logs Event ID 1801, indicating unsuccessful Secure Boot certificate update attempts.
    "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware. Review the published guidance to complete the update and maintain full protection. This device signature information is included here."
  • Microsoft Secure Boot automated updates fail to install new 2023 certificates.
  • Missing Microsoft Corporation KEK 2K CA 2023 in the virtual machine Secure Boot KEK database.
  • Failure to install updated DB, DBX, or Option ROM certificates.
  • Unable to update the Microsoft UEFI certificate because the following error message is returned for Event 1769:
    The Secure Boot updated failed to update KEK 2023 with error invalid access to memory location.
  • Secure Boot updates succeed on some VMs but fail on others with different ESXi or virtual hardware versions.
  • Secure Boot continues to function, but future DB/DBX revocation updates cannot be applied.

Important Note:

  • The virtual machines will continue to boot even after the certificate expiry and boot will be impacted only when the expired certificates are revoked by the issuer (Microsoft).
  • An expired KEK certificate impacts the ability to update Secure Boot databases rather than immediate boot functionality.

Environment

  • ESXi: 7.x, 8.x, 9.x
  • VCF: 4.5, 5.x, 9.x
  • TCP: 3.0, 3.1, 4.0, 5.0, 5.0.1, 5.0.2, 5.1
  • TCI: 2.7, 3.0

Cause

  1. Key Exchange Key (KEK) is expired or missing newer Microsoft KEK certificates

    In this case, the platform cannot authorize Secure Boot updates, including DB updates and DBX revocations, and Windows may log Event ID 1801 during attempted Secure Boot remediation.

  2. Invalid Platform Key (PK)

    On virtual machines created on ESXi versions earlier than 9.0, the PK is configured with a NULL signature by default due to previous design considerations. In this case, the platform cannot authorize updates to the KEK, which in turn prevents subsequent DB and DBX updates.

Resolution

There is no automated resolution available at this time. In coordination with Microsoft, Broadcom Engineering Team is actively working towards implementing an automated solution in a future release to update the Platform Key (PK) on the affected VMs which will facilitate the certificate rollout as outlined in Microsoft Guideline (Secure Boot Certificate updates: Guidance for IT professionals and organizations - 5062713 ).

Workaround (Manual Method)

  1. Verify the existing Platform Key Certificate.

    1. Linux

      1. Execute the following command and if the command does not return any output (blank result), the Platform Key (PK) needs to be updated.
        mokutil --pk
    2. Windows

      1. Open Windows PowerShell console as Administrator.
      2. Execute below commands:
        $pk = Get-SecureBootUEFI -Name PK
$bytes = $pk.Bytes
$cert = $bytes[44..($bytes.Length-1)]
[IO.File]::WriteAllBytes("PK.der", $cert)
certutil -dump PK.der
      3. The Platform Key (PK) needs to be updated if the above command fails with below error, which means the Certificate is Invalid:
        PS C:\> $pk = Get-SecureBootUEFI -Name PK
PS C:\> $bytes = $pk.Bytes
PS C:\> $cert[44..($bytes.Length-1)]
Cannot index into a null array.
At line:1 char:1
+ $cert[44..($bytes.Length-1)]
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

        Note: In some Windows versions, the certutil command will show the result as "00" as below, which also means that the Platform Key (PK) is invalid.
        PS C:\> certutil -dump PK.der
 00                                                 .
 CertUtil: -dump command completed successfully.
PS C:\>$bytes.Length
 45
  2. Verify the existing Key Exchange Key (KEK) Certificate.

    1. Linux

      1. Execute the following command which will list all the KEK certificates.
        mokutil --kek
      2. Check if Microsoft Corporation KEK 2K CA 2023 is present in the certificate list.
         
    2. Windows

      1. Open Windows PowerShell console as Administrator.

      2. Execute below command:
        [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
      3. If above command returns True, Microsoft Corporation KEK 2K CA 2023 is present in the certificate list.

  3. Update the Platform Key (PK) by following the procedure described in Manual Update of the Secure Boot Platform Key in Virtual Machines if the following criterias are met:

    1. Microsoft Corporation KEK 2K CA 2023 certificate is missing as per Step 2.
    2. Platform Key (PK) is Invalid as per Step 1.

  4. After verifying the Platform Key is Windows OEM Devices PK, follow Microsoft’s Secure Boot update guidance to complete DB, DBX, KEK, and bootloader updates.
  5. For Linux virtual machines, use VMware-supported Secure Boot update mechanisms, as Microsoft’s automated workflow does not apply.

Additional Information

Secure Boot Certificate Expiration FAQs.

Q: What is UEFI Secure Boot, and how does it work in vSphere VMs?

UEFI Secure Boot is a firmware-based security feature that ensures a virtual machine boots only with trusted, digitally signed software by enforcing a cryptographic chain of trust from firmware to OS loader. In VMware vSphere VMs, this is implemented in the virtual UEFI (vUEFI) firmware, which validates each boot component using Secure Boot databases stored in virtual NVRAM: the Platform Key (PK) establishes the root of trust, the Key Exchange Key (KEK) authorizes updates, the DB contains allowed signatures, and the DBX lists revoked ones. During boot, the firmware verifies the bootloader (e.g., Windows Boot Manager), which in turn verifies subsequent components, preventing execution of untrusted code. The Secure Boot state persists with the VM (including across vMotion), integrates with vTPM for measured boot (e.g., PCR7 for BitLocker and VBS), and supports authenticated updates—often delivered via OS-Driven authenticated writes or firmware update capsules —to maintain trust over time.

SecureBoot Trust Delegation Model

Platform Ownership (PK)

            │

           ▼

Delegated Update Authority (KEK)

           │

          ▼

Operational Trust Lists (DB / DBX)

  • PK defines who controls trust.
  • KEKs define who may update trust.
  • DB/DBX define what is trusted or revoked.

Q: What are the original certificates stored in vUEFI PK, KEK and DB databases?

For vSphere VMs, Secure Boot certificates are initialized by the host at the first VM power-on and remain static for the life of the VM unless updated. The following table outlines the default certificate set based on the ESX version and VM HW Version used at the time of VM creation.

ESX Version and VM HW Version at VM creation

vUEFI database

Certificate

Expiration date

9.x.x.x releases  AND VM HW Version 14 or newer

PK

Windows OEM Devices PK

Sep 2038

KEK

Microsoft Corporation KEK 2K CA 2023

Mar 2038

Microsoft Corporation KEK CA 2011

Jun 2026

DB

 

 

 

Windows UEFI CA 2023

Jun 2035

Microsoft UEFI CA 2023

Jun 2038

Microsoft Windows Production PCA 2011

Oct 2026

Microsoft Corporation UEFI CA 2011

Jun 2026

VMware Certificate 

Dec 2019

VMware Secure Boot Signing

Oct 2037

8.0 U2 and 8.0 U3, up to current 8.x release AND VM HW Version 14 or newer

PK

VMW.NULLPK

N/A

KEK

Microsoft Corporation KEK 2K CA 2023

Mar 2038

Microsoft Corporation KEK CA 2011

Jun 2026

DB

Windows UEFI CA 2023

Jun 2035

Microsoft UEFI CA 2023

Jun 2038

Microsoft Windows Production PCA 2011

Oct 2026

Microsoft Corporation UEFI CA 2011

Jun 2026

VMware Certificate 

Dec 2019

VMware Secure Boot Signing

Oct 2037

  • Earlier ESX versions, OR
  • HW Version 13 VMs

Note: Secure Boot support for vSphere VMs was introduced starting with HW Version 13.

PK

VMW.NULLPK

N/A

KEK

Microsoft Corporation KEK CA 2011

Jun 2026

DB

Microsoft Windows Production PCA 2011

Oct 2026

Microsoft Corporation UEFI CA 2011

Jun 2026

VMware Certificate

Dec 2019

VMware Secure Boot Signing
(Note: Starting from ESXi670-202004002)

Oct 2037

Note: Starting from a planned 8.0 U3 patch release, the Windows OEM Devices PK certificate will be automatically initialized in the PK for newly created VMs (HW Version >= 14). We will update this KB once that patch becomes available. 

Q: What is the Microsoft Secure Boot Certificates expiration and transition?

Please refer to the official Microsoft documentation: Secure Boot Certificate Updates Guidance

Q: What vSphere VMs are affected by this transition, and how?

  • All vSphere VMs with Secure Boot enabled that currently lack the Microsoft 2023 certificates are affected, regardless of the Guest OS (Windows or Linux).
  • Ultimately, it is recommended that all Secure Boot-enabled VMs shift to use the Microsoft 2023 certificates to maintain long-term guest OS boot compatibility and security compliance.
  • To authorize a Key Exchange Key (KEK) update via the Guest OS, the VM must contain the Windows OEM Devices PK certificate. Currently, there are vSphere VMs (PK mentioned as VMW.NULLPK in above table) lacking this certificate, thus cannot process OS-driven KEK updates to these VMs.

Q: What will happen to my Secure Boot-enabled VMs if I cannot update KEK and DB certificates prior to their expiration?

  • After expiration of the certificates, the keys are no longer valid for signing new payloads. Specifically, new DB and DBX update payloads will not be signed using the 2011 KEK, and new OS boot components (such as bootloaders) will not be signed using the 2011 DB keys. However, the Secure Boot verification process does not check certificate expiration, which means the 2011 certificates can still verify the integrity and authenticity of payloads that were signed with the 2011 keys, regardless of certificate expiration.
  • OS Boot: Existing guest OSes will continue to boot normally.
  • OS Updates:
    • OS update payloads unrelated to Secure Boot (KEK, DB/DBX, and bootloaders) are completely unaffected.
    • DB/DBX update payloads signed by the 2011 KEK (during its valid period) can be successfully applied even after the 2011 KEK certificate expiration, as long as the 2011 KEK certificate remains in the vUEFI KEK database.
    • New DB/DBX update payloads that are signed solely by, and thus rely solely on, the 2023 KEK for verification will fail if the 2023 KEK certificate is missing from the vUEFI KEK database.
    • Payloads intended to update KEK will always fail if the Windows OEM Devices PK certificate is missing from the vUEFI PK database, regardless of the Microsoft Corporation KEK CA 2011 expiration.
    • KEK update payloads can be successfully applied as long as the Windows OEM Devices PK certificate is present in the vUEFI PK database, regardless of the Microsoft Corporation KEK CA 2011 expiration.
  • OS Installation: VMs lacking the 2023 DB certificates will be unable to boot or install future operating systems that rely solely on these new certificates for verification. Please consult your guest OS vendor to determine which new OS releases require the 2023 DB certificates for fresh installations. This ensures you can properly coordinate vUEFI database updates (PK, KEK, and DB) prior to deploying new OSes.

Q: Who is responsible for updating PK, KEK, and DB for Secure Boot-enabled VMs?

VMware's Responsibility:

VMware is taking the lead on ensuring the presence of the Windows OEM Devices PK certificate in the virtual firmware to facilitate KEK update. Our goal is to minimize operational overhead through automated delivery mechanisms for VMs running on major ESX versions currently under General Support.

  • For newly created VMs: The Windows OEM Devices PK certificate is initialized automatically on ESX 9.x hosts. For ESX 8.x hosts, this will be initialized automatically after a planned vSphere 8.0 U3 patch is applied. (Note: This KB will be updated once that patch is available). The Microsoft 2023 KEK and DB certificates are initialized automatically on ESX 8.2 or newer hosts. (See the table above for more details).
  • For existing VMs: VMware is delivering a comprehensive solution to add the Windows OEM Devices PK certificate into the vUEFI if it is detected as missing from VMs running on ESX 8.x and 9.x hosts (starting from planned future patches). While this solution utilizes automated delivery mechanisms to minimize overhead, it will still require customer actions. (Note: This KB will be updated once the patches are available.)

Customer's Responsibility:

  • For PK updates:  Customers should execute PK update based on VMware guidance.
  • For KEK and DB updates: Customers should follow their respective OS vendor's guidance to update them natively from within the guest OS.
    • Important Risk Note: VMware's KEK/DB update methods (via the vUEFI interface or VMX configuration) can serve as a fallback. However, updating these from outside the guest OS carries the risk of breaking applications (such as triggering BitLocker recovery) for vTPM-enabled VMs, as it alters Secure Boot variables and vTPM measurements without the OS's awareness.

Q: How can I update PK?

You should always update PK using VMware-supported methods. All methods below require VM Hardware Version 14 or newer. (Note: Secure Boot support was introduced in Hardware Version 13, but updating PK requires the virtual NVRAM capabilities of Hardware Version 14+). VMware currently provides, or plans to provide, the following four update methods:

  1. Manual Update from the vUEFI interface: Applies to ESX 7, 8, and 9. (Refer to KB: Manual Update of the Secure Boot Platform Key in Virtual Machines).
  2. Manual Update from VMX configuration: Supports ESX 9.0+ (Refer to KB: Secure Boot Custom Certificates) and will support ESX 8.x in a planned future patch.  
  3. Silent PK update for vTPM-disabled VMs: vSphere will silently add the missing Windows OEM Devices PK certificate to the PK database for vTPM-disabled VMs during guest reboots or VM power cycles. This capability will be added to ESX 8.x and 9.x in future patches.
  4. Capsule PK update for vTPM-enabled Windows VMs: This method depends on planned Microsoft Windows patches. For supported Windows versions with the required patch installed, the missing Windows OEM Devices PK certificate will be automatically added to the PK database upon a guest reboot following a reboot prompt. This capability will be added to ESXi 8.x and 9.x in future patches.

We will update this KB when the planned patches become available.

Q: How can I identify VMs that are lacking the Windows OEM Devices PK certificate?

  • You can manually check the PK certificate by following the certificate verification steps in KB Manual Update of the Secure Boot Platform Key in Virtual Machines.
  • You will be able to easily identify VMs lacking the Windows OEM Devices PK certificate across your environment at scale using one of the following upcoming methods:
    • vCenter Alarms: Using the planned "Out-of-date Platform Key Alarm" feature in upcoming vSphere 8 and 9 releases (requires patching both vCenter and ESX).
    • PowerCLI Script: Once ESX is patched (even without patching vCenter), a VMware-provided PowerCLI sample script can be used to inventory VMs lacking the Windows OEM Devices PK certificate.

We will update this KB when the planned patches become available and will also provide the sample script here.

Q: What are the VMware-recommended PK update workflow and detailed steps for vSphere 8.x and 9.x?

To minimize operational effort for PK update for Secure Boot-enabled VMs across a cluster containing various VM types, we recommend proceeding in the following order:

  • Step 1: Perform Silent PK Update for vTPM-disabled VMs (HW Version >= 14)
  • Step 2: Perform Capsule PK Update for vTPM-enabled Windows VMs (HW Version >= 14) 
  • Step 3: Manual PK Update for vTPM-enabled Legacy Windows & Linux VMs (HW Version >= 14)
    • Important Risk Note: Manual PK update methods (via the vUEFI interface or VMX configuration) update the PK from outside the guest OS. This carries a risk of breaking applications (such as triggering BitLocker recovery) on vTPM-enabled VMs, as it alters Secure Boot variables and vTPM measurements without the guest OS's awareness.
  • Final Step: Address Hardware Version 13 VMs. For VMs running Hardware Version 13, you must first upgrade the Hardware Version to 14 or newer. Once upgraded, perform the PK update following the three steps above based on the VM's specific configuration.

We will update this KB with detailed steps for each workflow when the planned patches delivering these PK update methods become available.

Q: Will there be future patch for vSphere 7.x version?

As vSphere 7 is beyond its End of General Support date, no automated update tools will be available. Customers remaining on vSphere 7 must perform manual updates for existing and newly created VMs referencing Manual Update of the Secure Boot Platform Key in Virtual Machines or upgrade to a supported version of vSphere to utilize the automation methods.

Q: When can I update PK?

After reviewing the answers to the above questions, you should decide on your update window based on the specific tools you choose to use and the availability of the required patches, as described above.

Q: How can I update KEK and DB?

  • It is always recommended that you follow the OS vendor's guidance to update KEK and DB.
  • As a contingency, VMware provides two supported manual methods: the vUEFI interface (ESX 7, 8, 9) method or the VMX configuration method (ESX 9.0+ and planned 8.x patches).  
    • Important Risk Note: VMware's KEK/DB update methods (via the vUEFI interface or VMX configuration) can serve as a fallback. However, updating these from outside the guest OS carries the risk of breaking applications (such as triggering BitLocker recovery) for vTPM-enabled VMs, as it alters Secure Boot variables and vTPM measurements without the OS's awareness.
    • For KEK/DB update via the vUEFI interface for ESX 7, 8, 9, please refer to KB Manual Update of the Secure Boot Platform Key in Virtual Machines.
    • For KEK/DB update via the VMX configuration, refer to KB: Secure Boot Custom Certificates.  (Note: This capability currently exists on ESX 9.x hosts and will be delivered to ESX 8.x hosts in a planned patch. Once the ESX 8.x patch becomes available, we will update both that KB and this current KB.)

Q: When can I update KEK?

  • Via OS Methods: You must update PK first if the Windows OEM Devices PK certificate is missing from your VM's UEFI.  A KEK update initiated from within the Guest OS will always fail if a valid Platform Key is not present to authorize the change. Once the Windows OEM Devices PK certificate is present, you can update KEK at any time following your OS vendor's guidance.
  • Via VMware Methods: If using the manual vUEFI or VMX methods, you can update based on tool availability.

Q: When can I update DB?

  • Via OS Methods: You can update DB at any time per the OS vendor's guidance. Specifically, for Windows VMs, Microsoft has delivered DB update payloads via Windows Update for this certificate transition. Because these payloads were signed by the 2011 KEK, they can be applied anytime (even after the 2011 KEK certificate expires), as long as the 2011 KEK certificate remains present in the virtual firmware.
  • Via VMware Methods: If using the manual vUEFI interface or VMX configuration methods, you can update based on tool availability.

Q: When will the Microsoft 2011 DB certificates be forced into revocation?

Certificate revocation means it is explicitly removed from the DB or added to the DBX . We are not currently aware of any near-term timeline for a forced revocation from our OS partners. Please consult your OS vendor for this.

Q: How does the omission of the Microsoft Option ROM UEFI CA 2023 from vSphere VMs affect the Secure Boot certificate transition?

Currently, the Microsoft Option ROM UEFI CA 2023 certificate is not automatically initialized into the vUEFI DB during VM creation.

  • For VMs without passthrough devices, this certificate is not required for boot..
  • For VMs that do utilize passthrough devices, this certificate might be required if the passthrough device relies on Option ROM firmware to boot.

If you plan to upgrade the firmware of your passthrough device, you must first consult your hardware vendor to understand if the new device firmware solely relies on the Microsoft Option ROM UEFI CA 2023 certificate for Secure Boot verification. If so, this certificate must be present in the VM’s vUEFI DB before the firmware upgrade is performed.

For VMs that require this certificate, we recommend the following steps to add the Microsoft Option ROM UEFI CA 2023 certificate to the vUEFI DB prior to a passthrough device firmware upgrade:

  • For Windows VMs: The Windows OS handles the transition natively by automatically adding the missing Microsoft Option ROM UEFI CA 2023 certificate to the DB, as long as the already-trusted Microsoft Corporation KEK CA 2011 is present in the vUEFI KEK database and the Microsoft Corporation UEFI CA 2011 is present in the vUEFI DB. You should perform the DB update following Microsoft's guidance, verify the certificate is in place, and then perform the physical device firmware upgrade.
  • For Linux VMs: Linux guest OS native update tools (such as fwupd) do not automatically install the Microsoft Option ROM UEFI CA 2023 certificate. Before upgrading the passthrough device firmware, you must manually import the Microsoft Option ROM UEFI CA 2023 certificate into the VM’s vUEFI DB using VMware-supported methods (such as the manual vUEFI interface or VMX configuration methods as outlined above) or with authenticated writes from the Linux shell prompt. Confirm the certificate is successfully enrolled in the DB, and then proceed with the device firmware upgrade.
Powered by Wolken Software