Alarm: “The new host TPM endorsement key doesn't match the one stored in the DB”

Products

• VMware vCenter Server

Issue/Introduction

This article addresses frequently asked questions concerning the alarm "The new host TPM endorsement key doesn't match the one stored in the DB" observed in vSAN and VMware Cloud Foundation (VCF) environments

Background: 
After changing the mother board with TPM, the following message may appear within the vSphere Client or host summary page
Alarm: “The new host TPM endorsement key doesn't match the one stored in the DB”

This alarm typically appears in the vSphere Client or on the host summary page following a system board replacement that includes a Trusted Platform Module (TPM). The underlying cause is a mismatch between the endorsement key generated by the new TPM and the corresponding key value previously stored within the vCenter Server database's (VPX_HOST) table for that specific host.

Environment

vCenter Server 

Cause

The 'Endorsement Key' is something that is hardcoded by the manufacturer and used to uniquely identify a TPM device. This is different from other keys used by Broadcom to encrypt/decrypt configuration and something we cannot recover upon motherboard replacement. This is the reason vCenter doesn't automatically update the TPM endorsement key after the ESXi host configuration is restored.

Resolution

• The workaround to remove & add host to vCenter as mentioned in the KB article ie Alert : The new host TPM endorsement key doesn't match the one stored in the DB has certain restrictions in vSAN/VCF environment. Removing from inventory and re-adding would resolve the alarm, but that might have potential vSAN shuffling on data. Specifically, whether it will be time consuming shuffling or not, depends on vSAN policies configured.
• Available options to resolve the alarm in vSAN/VCF environment
  
  • Option 1:
    • Remove and re-add the host to the VC's inventory
    • When the host is re-added to vCenter, it saves the new endorsement key and will attest with the new TPM.
    • This cannot be readily done if the host belongs to vSAN cluster, since moving a host out of inventory puts vSAN data to be shuffled around and could at times be very extreme vSAN workflow-wise depending on vSAN configuration of object policies.
  • Option 2:
    • This steps involves modifying the vCenter database, please ensure we have latest vCenter backup or snapshots before preceding.
    • Edit the Center database (VPX_HOST table) for the impacted host.
    • For details on editing the VCDB, please refer the KB Alert : The new host TPM endorsement key doesn't match the one stored in the DB
  • Option 3:
    • The other options is ignore the alarm either by "acknowledging" or "reset to green".
    • If we "reset to green", the alarm will come back once host gets reconnected or when it takes a reboot.
    • If we "acknowledge", the alarm will be permanently muted.
    • The situation will map down to a scenario where host never had TPM and things will functionally work.
    • Here one will not have guarantee of VC attesting that VIBs are genuinely from Broadcom.  But if we already have UEFI secure boot enabled on the host and sealing configuration to the TPM, we already have good defense to begin with on the host, but just not provable to the VC.

Additional Information

Alert : The new host TPM endorsement key doesn't match the one stored in the DB