Event details
The behaviour is exactly the same on servers as on clients:
- For hardware vendors (Dell) to push the new certificate to the active db, a manual step is required within the firmware (followed by possibly additional steps in the OS like Bitlocker recovery). The reason for this is that TPM's PCR7 register will seal keys against the content of those certificates in the active db. Which means whenever this value changes outside of the control of the OS, the TPM will deny access and keys in there (e.g. used for Bitlocker) will be unusable, triggering Bitlocker recovery.
- Operating system vendors (Microsoft) can push new certificates to the active DB if they receive a signed Variable Update for the new KEK that is signed by the hardware vendor's platform key. This has happened for many different devices (probably also for the server from Dell) and it can be applied later in a LCU if the hardware is in the low-risk bucket, or by various ways of the sysadmin by pushing registry keys, group policies, Intune etc. This update is possible since the OS will at that moment have access to the keys in TPM and can reseal them to the new PCR7 value. So it will change the active DB and the TPM at the same time. Which the hardware vendor cannot do as the TPM will only allow access in very specific stages of the boot process where no firmware of the vendor is still running.
- The only difference between client and server SKUs is that on clients, Microsoft will use Controlled Feature Rollout to update the certificates earlier, while on servers they will only come with cumulative updates and only for hardware that is known to not show any issues with installing them.
My questions:
- Did you try setting the AvailableUpdates registry key on such a machine and verify that it will indeed not update the certificates? If yes, what error is in event log? I would assume it does update them by now.
- What is the thumbprint of the Platform Key? You can find it via PowerShell UEFIv2 module:
(Get-UEFISecureBootCerts pk).Signature | Format-List Subject,Thumbprint
Arden_White
Microsoft
Microsoftmihi provided an excellent explanation. I will only add a bit more context on why hardware vendors sometimes release new firmware during the Secure Boot certificate updates.
- Defaults: Vendors may update the default Secure Boot variables, such as DBDefault, so the new certificates are included as part of the platform defaults. This matters if someone resets the Secure Boot configuration, because the reset will then load the updated defaults and ensure the active database contains the newer certificates.
- Firmware behavior: In a small number of cases, a platform may have a firmware issue that prevents the active Secure Boot variables from updating correctly. A firmware update addresses this so the device can accept and apply the new certificates.
Both of these situations are examples of the hardware vendor looking out for customers and making sure the Secure Boot update process is reliable on their platforms.