Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines

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

• VMware ESXi 7.x
• VMware ESXi 8.x
• VMware ESX 9.x
• Virtual machines with UEFI firmware and Secure Boot enabled

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 (MS KB ID: 5062713).

Workaround (Manual Method)

1. Verify the existing Platform Key Certificate.
   
   
   1. Linux
      
      
      1. Execute the following command
         
         mokutil --pk
         
         
      2. If the command does not return any output (blank result), the Platform Key (PK) needs to be updated.
         
         
   2. Windows
      
      
      1. Open Windows PowerShell console
      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
      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.

If Secure Boot updates continue to fail after the required KEK is installed, contact Broadcom Support for further assistance.

Additional Information

Microsoft guidance - Secure Boot Certificate updates: Guidance for IT professionals and organizations