MicrosoftHi Daniel, I agree turning off secure boot would be foolish ... I was being silly, sorry. What I believe is the best is, this should happen automatically from the OEM. Secure certified firmware should be automated and occur when you do the routine firmware updates that should occur on all supported hardware and software. There should never be a one time jump through a ton of Microsoft hoops, keep the hardware current, and supported, keep the software current and supported and this should never happen. All of the hardware and software here is current and supported, I should not have to jump through a series of hoops created by Microsoft just because they say so. That is the real issue I have.
I absolutely agree! It would be wonderful if it were that easy. In an ideal world, OEMs would fully implement the UEFI specifications, and certification updates to PK, KEK, db and dbx would just flow automatically without any special intervention from the user.
Unfortunately, not all firmware manufacturers follow the UEFI standards consistently, and this inconsistency can lead to issues—including potential NVRAM corruption. That's why, even on fully supported and up-to-date hardware, the process sometimes ends up feeling far more complicated than it should be.
You cannot imagine the hoops we had to jump through while updating the Secure Boot certificates on VMware VM's, because their UEFI implementation was lacking. Thankfully, nothing that lead to corruption or unbootable operating systems.
You cannot imagine the hoops we had to jump through while updating the Secure Boot certificates on VMware VM's, because their UEFI implementation was lacking. Thankfully, nothing that lead to corruption or unbootable operating systems.
Hi, regarding this. Could you share some of the steps and hoop-jumping you had to perform to make this work? I've tried a lot of things and from my understanding the availableupdates key is 4000 but I still receive eventid 1801 which complains about the process is not done. Have you found a way to verify 10000% that the new certificates are installed?
The hoops were, that the certificate update did not complete successfully. After a lot of research we found out that the cause was VMware, so here's what we had to do to fix it:
Especially the second part caused a lot of time going into orchestrating the maintenance planning to not cause any downtimes.
Once that was fixed, the certificate update was successful.
Have you found a way to verify 10000% that the new certificates are installed?
Yes, you will see a particular event (which I don't remember from the top of my head) that indicates success, together with AvailableUpdates being set to 0x4000 and the UEFICA2023ErrorEvent being void or 0. But it's best to follow Microsoft guidance. Unfortunately, that guidance is so fragmented, it's a real shame they failed to make it available in a central location. Check this blog, but also https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f#bkmk_certificate_deployment
You'll find the following PowerShell which can be used to check if the certificate as enrolled, but that only tells you half of the truth. Don't trust this alone!
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)) -match "Windows UEFI CA 2023"
There is a powershell command that will check the cert version. Here it is:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)) -match "Windows UEFI CA 2023"
I have two servers that indicate the update is still in process but, this command returns a result of True. indicating they have 2023 Cert. Since I do weekly updates and restarts every Sunday morning, I will just keep restarting them once or twice and monitoring it. All of the other servers have completed the update process.
Additional note: One of the two servers now indicates it has completed the process. Since there is time, just monitor it and restart it when you can.
That command only tells you half the truth. As long as you see Event 1801, the process is not completed.