MicrosoftGDennis Updating secure boot certificates is not a simple topic, that's why there are no simple guides for it. There's a lot that can go wrong, which can cause your server to no longer boot.
Having said that, a simple way of updating the secure boot certificate is to follow Step 4, Option 1, and set the AvailableUpdates key to 0x5944. Reboot it a couple of times and the key should finally reach 0x4000, when all updates are applied.
I strongly recommend taking this as the key information and re-read the guide again to really understand how to understand the process, what to prepare and how to diagnose issues.
Hi Daniel, thanks for the update, and the information. Personally I believe if secure boot is that complex and dangerous then simply turning off secure boot off sounds like the best route. Things simply do not need to be that complex, in the 40 years I have worked in IT, keeping it short and simple is normally the best. Also, Copilot gave me different information than what this indicates and what was in the article (yes I know AI is often wrong). It's a shame that we live in a world where nothing is trusted. Sometimes I long for the days of green screens on an IBM mainframe writing COBOL and assembler and not having to worry about some evil character attacking the firmware I wrote myself. Sigh .... guess I'm showing my age.
Just to clarify a few points: Secure Boot itself isn't the problem, and it's not inherently complex. What is complex is the one-time certificate rotation because Microsoft is revoking old bootloaders. Turning Secure Boot off doesn’t simplify anything. It just removes protection from a class of attacks that now target exactly these outdated bootloaders. You have the freedom to disable secure boot entirely if you prefer, but I would strongly advise against it.
Hi 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.
