Solved Secure boot update HowTo

SIW2 said:

I have switched back to csm now.

In this bios just changing csm to enabled in bios tab main screen makes the secure boot label disappear. But in spite of Save and exit, it doesnt stick.

Need to go into secure boot menu , disable it. Then back to main bios screen csm enable. Save and exit

Click to expand...

Why back to CSM after all the trouble to update Secure Boot CAs?
Looks like you are not using Secure Boot after all.

No I dont have it on normally. There are other os on this machine which I am posting from now

SIW2 said:

No I dont have it on normally. There are other os on this machine which I am posting from now

Click to expand...

Is that since that other OS can't start with secure boot enabled?

Doesn't that create a big security hole?

Well bummer. My BIOS can see the fat32 drive and the KEK for CA 2023 but after selecting the file, to append the key in the Secure Boot menu, it gives me a generic fail message.
System still boots just fine.

Does the menu specify an alternative file format? .crt, .der, etc? Someone else said their UEFI was picky about the file extension.

garlin said:

Does the menu specify an alternative file format? .crt, .der, etc? Someone else said their UEFI was picky about the file extension.

Click to expand...

It doesn't ask. I could try changing the extension to cer and see what happens. Be back shortly... hopefully.

Success. I said screw it, and told it to just add the new key as .crt and voila:



Too be clear, trying to append in my AMI BIOS from EVGA would fail regardless of which file extension I tried.

HeavyHemi said:

Success. I said screw it, and told it to just add the the new key as .crt and voila:


View attachment 156760

Click to expand...

mmm.... what happened to the 2011 KEK?

There are normally two modes in the custom setup:

1. You can replace any of the UEFI variables (PK, KEK, DB, DBX) with a single file. This effectively erases whatever existing values were present before.

2. You can append changes to any of the UEFI variables, preserving the original values.

Evidently you chose the replace, and not append mode. Wiping out the KEK 2011 entry.

Technically this config will still work. You have a KEK 2023, which signs the two UEFI 2023 DB keys. It looks ugly, but it's valid. If there was ever a need to really, really boot from a CA 2011-signed disk or boot media, then you can temporarily disable Secure Boot and do your work.

Buddywh said:

mmm.... what happened to the 2011 KEK?

Click to expand...

It's apparently not needed by any hardware I'm running.
I did't append a key. I added the new key which deletes the default key. I can revert if I need to by installing the default keys if needed.

HeavyHemi said:

It's apparently not needed by any hardware I'm running.
I did't append a key. I added the new key which deletes the default key. I can revert if I need to by installing the default keys if needed.

Click to expand...

Yeah... you're fully transitioned to the 2023 keys (running on 2023 Boot Manager even) so it probably won't matter. It's just weird to see the 2001 keys in DB and no 2011 KEK... kind of like seeing 2023 DB keys and no 2023 KEK. Only not really since there's no potential for long-term issues.

It's also good to understand how the situation can come about.

MS has informed the OEM's it's acceptable to ship a 24H2 or 25H2-only Windows system with only the 2023 certs from the factory. 2011 certs are not in the firmware. Other OEM's will elect to ship both sets of certs, because they're afraid someone will complain they absolutely need to run some legacy OS.

It's just when you have a weird setup, it takes a little longer to eye ball the results as correct.

garlin said:

There are normally two modes in the custom setup:

1. You can replace any of the UEFI variables (PK, KEK, DB, DBX) with a single file. This effectively erases whatever existing values were present before.

2. You can append changes to any of the UEFI variables, preserving the original values.

Evidently you chose the replace, and not append mode. Wiping out the KEK 2011 entry.

Technically this config will still work. You have a KEK 2023, which signs the two UEFI 2023 DB keys. It looks ugly, but it's valid. If there was ever a need to really, really boot from a CA 2011-signed disk or boot media, then you can temporarily disable Secure Boot and do your work.

Click to expand...

Yup, no matter what method I tried, append, would result in a fail. I took a calculated risk, because I was already booting from the 2023 boot manager, that the risk was mimimal and reverting was trivial. Lucky me I guess.

Buddywh said:

Yeah... you're fully transitioned to the 2023 keys (running on 2023 Boot Manager even) so it probably won't matter. It's just weird to see the 2001 keys in DB and no 2011 KEK... kind of like seeing 2023 DB keys and no 2023 KEK. Only not really since there's no potential for long-term issues.

It's also good to understand how the situation can come about.

Click to expand...

That's probably a key point. If I wasn't already booting from a 2023 boot manager, I wouldn't have attempted it. Anyway, it's a fairly easy method to update on boards similar to my X99 with an AMI BIOS. I believe as long as they get to the state where they are booting from the 2023 boot manager, it should be safe to update the KEK in this manner as a last resort if they cannot get it to update otherwise. As was mentioned, needing to boot from media that isn't signed might be an issue. I didn't test out whether using a different file extension other than .crt would work. Don't look a gift horse in the mouth.

Edit.

For giggles I ran the script and task to trigger Windows update. For the first time, I got the correct updating status in the registry. Rebooted twice.
Half hour later, rebooted again and this annoying error at every boot is gone.
Log Name: System
Source: Microsoft-Windows-TPM-WMI
Date: 12/12/2025 5:46:59 PM
Event ID: 1801
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: DESKTOP-XXXXXXX
Description:
Secure Boot certificates have been updated but are not yet applied to the device firmware. Review the published guidance to complete the update and ensure full protection. This device signature information is included here.

HeavyHemi said:

Yup, no matter what method I tried, append, would result in a fail. I took a calculated risk, because I was already booting from the 2023 boot manager, that the risk was mimimal and reverting was trivial. Lucky me I guess.



That's probably a key point. If I wasn't already booting from a 2023 boot manager, I wouldn't have attempted it. Anyway, it's a fairly easy method to update on boards similar to my X99 with an AMI BIOS. I believe as long as they get to the state where they are booting from the 2023 boot manager, it should be safe to update the KEK in this manner as a last resort if they cannot get it to update otherwise. As was mentioned, needing to boot from media that isn't signed might be an issue. I didn't test out whether using a different file extension other than .crt would work. Don't look a gift horse in the mouth.

Click to expand...

A .crt and a .def file are completely different things and just changing the suffix won't change that. If what you have is a .cer changing it to .crt might have made the difference.

I downloaded a pre-signed .bin file from Microsoft's github and used that to append the 2023 KEK onto my older motherboard. That might would work if your firmware accepts it, but it's quite likely also a non-compliant way of doing it which my motherboard should have rejected. It could also be that even though it had the KEK it wouldn't be capable of approving a new DB key signed by it (since it is unsigned itself). I later went ahead and used MOSBY to build a complete chain of trust the right way just because I didn't have confidence it would work later on.

Buddywh said:

A .crt and a .def file are completely different things and just changing the suffix won't change that. If what you have is a .cer changing it to .crt might have made the difference.

I downloaded a pre-signed .bin file from Microsoft's github and used that to append the 2023 KEK onto my older motherboard. That might would work if your firmware accepts it, but it's quite likely also a non-compliant way of doing it which my motherboard should have rejected. It could also be that even though it had the KEK it wouldn't be capable of approving a new DB key signed by it (since it is unsigned itself). I later went ahead and used MOSBY to build a complete chain of trust the right way just because I didn't have confidence it would work later on.

Click to expand...

What I downloaded from github was the official microsoft corporation kek 2k ca 2023.der. Stuck it on a FAT32 thumb drive... I'm not sure where you got 'def' from. I changed the extension to .crt while initially experimenting with trying to update the KEK key. It may have also worked not changing the extension from der. I didn't experiment once I was sucessful inserting the 2023 KEK key. What I know would not work is any version of KEK key install with the default 2011 KEK keys installed.
Secure boot is kinda now the least of my worries. This board has no provision for any form of TPM. There are already a few new games I'm locked out of.

HeavyHemi said:

not sure where you got 'def' from

Click to expand...

From my fat fingers :) My understanding is a .der and a .cer/.crt can use different encodings so if a .der is rejected it seems unlikely to be any more useful to the firmware with just a suffix change if the file type (encoding) was the reason for rejection.

Do you know if it was post-signed or pre-signed? I was told that pre-signed objects are provided for developers who can sign them with a custom PK before enrolling in a firmware (I assume that's exactly what MOSBY does). When I got one to enroll I wasn't confident it would work for validating DBX revocation updates (in particular since DB variable updates are exceedingly rare) so just went to using MOSBY.

I suppose your firmware could sign KEK before enrolling it while in USER mode but I wonder how many machine BIOS have that capability; and I can't imagine that's UEFI compliant either since it kind of creates a great big security hole. If unsure if yours is working you could watch for revocations to roll-in to DBX as Microsoft sends them out.

Buddywh said:

From my fat fingers :) My understanding is a .der and a .cer/.crt can use different encodings so if a .der is rejected it seems unlikely to be any more useful to the firmware with just a suffix change if the file type (encoding) was the reason for rejection.

Do you know if it was post-signed or pre-signed? I was told that pre-signed objects are provided for developers who can sign them with a custom PK before enrolling in a firmware (I assume that's exactly what MOSBY does). When I got one to enroll I wasn't confident it would work for validating DBX revocation updates (in particular since DB variable updates are exceedingly rare) so just went to using MOSBY.

I suppose your firmware could sign KEK before enrolling it while in USER mode but I wonder how many machine BIOS have that capability; and I can't imagine that's UEFI compliant either since it kind of creates a great big security hole. If unsure if yours is working you could watch for revocations to roll-in to DBX as Microsoft sends them out.

Click to expand...

I obtained the signed official Microsoft cert from github as I posted. As I indicated it did not matter what method I used, I could not append or insert a new KEK key with the old key in place. It would fail regardless of which cert type was used. Der, cer or crt. Just for the sake of experimentation the same cert file will install whether it has the extension of .der or .crt. I don't believe my relatively standard AMI UEFI BIOS has any unique feature that self-signs a KEK. You seem to be over thinking this a bit.

HeavyHemi said:

You seem to be over thinking this a bit.

Click to expand...

Or under-thinking it in the area that might matter more if I only realized it. It's a pretty darn complicated interaction of things that go to make this all work, with unclear explanations and as often as not innacuracies wherever I turn.

Buddywh said:

Or under-thinking it in the area that might matter more if I only realized it. It's a pretty darn complicated interaction of things that go to make this all work, with unclear explanations and as often as not innacuracies wherever I turn.

Click to expand...

What also makes it difficult is everyone's device may be different that the procedures, methods and solutions discussed may not apply. It can lead to confusion and frustration.

Dirtyflash said:

What also makes it difficult is everyone's device may be different that the procedures, methods and solutions discussed may not apply. It can lead to confusion and frustration.

Click to expand...

Exactly right! That's when being aware of possible outcomes for given actions can be especially helpful.