Did you manually update your Secure Boot Keys ?

SlicEnDicE · Oct 16, 2025

Steve C said:
If Microsoft don't figure out how to fix the issue via Windows Update then there are going to be millions of non-bootable PCs leaving the average user clueless what to do and a public relations disaster for Microsoft! I still intend to do nothing and see what happens.

The final nail in the coffin is when, EU slaps a 1B€ fine to MS for breaking millions of computers for no apparent reason.

bo elam · Oct 16, 2025

SlicEnDicE said:
The final nail in the coffin is when, EU slaps a 1B€ fine to MS for breaking millions of computers for no apparent reason.

If that happens (breaking the computers), I hope they do get fined. I am not in Europe but good for the EU.

Bo

Cameraman1955 · Oct 16, 2025

Can anyone explane me abit, I run the script on my laptop and the output gives ,
UEFI KEK Certs
----------------
Microsoft Corporation KEK CA 2011

UEFI DB Certs
---------------
Windows UEFI CA 2023

What is the differtents between KEK and DB certs, am I ok with only the DB cert ?

kelper · Oct 16, 2025

Stigg said:
No.

Who are you replying to???

kelper · Oct 16, 2025

Khoaimi said:
My laptop is quite old (since 2020), the last bios update was 2021, I don't think the manufacturer will release a new bios update just to fix this error.
Luckily I read on the forum and manually updated successfully. It seems the problem has been solved.
Thank you for your feedback.

I see Microsoft Windows Production PCA 2011 is in DB and DBX!

It won't matter because DBX entries take precedence over DB entries.

Buddywh · Oct 16, 2025

Khoaimi said:
My laptop is quite old (since 2020), the last bios update was 2021, I don't think the manufacturer will release a new bios update just to fix this error.
Luckily I read on the forum and manually updated successfully. It seems the problem has been solved.
Thank you for your feedback.

Just be aware of the effect of putting the 2011 certificate in DBX.

It revokes trust in the 2011 certificate so your system can only use 2023 signed boot files to start in Secure Boot. Be sure to make a recovery USB stick that uses 2023 boot files. It's only a concern until the 2011 certificate is expired (this time next year when it can no longer be used to sign boot files) or when Microsoft starts using only 2023 signed boot files in their updates and distributions that need it (nobody knows...or is telling...exactly when that will be).

Buddywh · Oct 16, 2025

Cameraman1955 said:
Can anyone explane me abit, I run the script on my laptop and the output gives ,
UEFI KEK Certs
----------------
Microsoft Corporation KEK CA 2011

UEFI DB Certs
---------------
Windows UEFI CA 2023

What is the differtents between KEK and DB certs, am I ok with only the DB cert ?

As I understand it, the KEK (Key Exchange Key) is used to authorize (or validate) changes going into DB. So it makes sense to me the 2011 KEK had to validate the 2023 UEFI CA for it to be loaded into DB (therefore I also assume it was signed with both the 2023 KEK and the 2011 KEK by it's authors, Microsoft). Again to my understanding, it would be perfectly logical now since the 2011 KEK is not expired.

My concern was what happens after the KEK expires in June of 2026. Is the same as with boot file binaries signed by the 2011 certificates before they expired which will still validate and function (so long as the 2011 certificate hasn't had trust revoked).... or will you need a 2023 KEK put in place to continue using the 2023 CA in DB? Not knowing the answers to that is what prompted me to use MOSBY to get the complete array of 2023 keys, especially for my unsupported antique computer.

kelper · Oct 16, 2025

Buddywh said:
Just be aware of the effect of putting the 2011 certificate in DBX.

It revokes trust in the 2011 certificate so your system can only use 2023 signed boot files to start in Secure Boot. Be sure to make a recovery USB stick that uses 2023 boot files. It's only a concern until the 2011 certificate is expired (this time next year when it can no longer be used to sign boot files) or when Microsoft starts using only 2023 signed boot files in their updates and distributions that need it (nobody knows...or is telling...exactly when that will be).

So, do advise just leaving certs in DB?

Buddywh · Oct 16, 2025

kelper said:
So, do advise just leaving certs in DB?

I'm no expert on this, just a user who got the bug and wanted to keep some old computers running after all this. I'd suggest it depends entirely on your situation... I chose to not revoke trust and leave DBX empty. But there is a good reason to revoke trust if your situation requires it since that locks the door to any possible Black Lotus attacks.

You just have to be aware of what the effects are and what you might do if anything happens. And it's only temporary since Microsoft is going to do it any way at some point for systems that have the updated 2023 keys in DB. At that point they know they have to always provide updates and distributions with 2023 boot files, so no problem.

Margarita · Oct 16, 2025

Buddywh said:
Depends entirely on your situation... I chose to not revoke trust and leave DBX empty. There is a good reason to revoke trust if your situation needs it since that locks the door to any possible Black Lotus attacks.

You should be able to undo the cancellation of PCA 2011 cert and put it in DBX by resetting the secure boot settings in BIOS at any time.

Buddywh · Oct 16, 2025

Margarita said:
You should be able to undo the cancellation of PCA 2011 cert and put it in DBX by resetting the secure boot settings in BIOS at any time.

That's true... just load default keys in your BIOS' Secure Boot settings section does it, then re-run the scripts for loading the 2023 key into DB and don't run the Revoke Trust scripts this time. But also, some of these pre-built systems and laptops (like Dell, HP, Lenovo) don't have all the controls exposed in their BIOS settings, they might have to get more aggressive with something like a complete CMOS reset.

If you do this after Microsoft is in their enforcement phase though (when Microsoft revokes trust in the 2011 CA key) I assume Windows will just re-load the key back into DBX at the next re-start. That would be the logical thing.

gunrunnerjohn · Oct 16, 2025

Buddywh said:
Just be aware of the effect of putting the 2011 certificate in DBX.

It revokes trust in the 2011 certificate so your system can only use 2023 signed boot files to start in Secure Boot. Be sure to make a recovery USB stick that uses 2023 boot files. It's only a concern until the 2011 certificate is expired (this time next year when it can no longer be used to sign boot files) or when Microsoft starts using only 2023 signed boot files in their updates and distributions that need it (nobody knows...or is telling...exactly when that will be).

Microsoft is already using the 2023 cert in new distributions. I've already revoked the 2011 cert on all my systems, and any USB recovery drive that wouldn't boot got the simple fix below.

If you have a USB drive that needs the new 2023 cert, @garlin posted a simple batch file to fix it. So, this is really a non-problem, just plug in any bootable USB drive, run this batch file and enter the drive letter of the connected USB drive, problem solved.

Contents of: Copy Key to Boot USB.BAT

Code:

set /p id=Enter Destination Drive Letter with a colon:
echo %id%
pause

COPY %id%\EFI\MICROSOFT\BOOT\BCD %id%\EFI\MICROSOFT\BOOT\BCD.BAK
pause

bcdboot c:\windows /f UEFI /s %id% /bootex
pause

COPY %id%\EFI\MICROSOFT\BOOT\BCD.BAK %id%\EFI\MICROSOFT\BOOT\BCD
pause

Buddywh · Oct 16, 2025

gunrunnerjohn said:
Microsoft is already using the 2023 cert in new distributions. ....

THAT is certainly good to know!

We're just not getting a lot of this information. It might be said, with some validity, we wouldn't know what to do with it anyway, but then not knowing things also contributes to taking a very cautious approach.

gunrunnerjohn · Oct 16, 2025

Buddywh said:
THAT is certainly good to know!

We're just not getting a lot of this information. It might be said, with some validity, we wouldn't know what to do with it anyway, but then not knowing things also contributes to taking a very cautious approach.

And rightly so! Nothing is going to happen fast, so not enabling Secure Boot unless you're sure you have your ducks in a row is not a bad plan.

Buddywh · Oct 16, 2025

gunrunnerjohn said:
And rightly so! Nothing is going to happen fast, so not enabling Secure Boot unless you're sure you have your ducks in a row is not a bad plan.

I see a lot of people devoutly refuse to use it and don't understand why. I'd feel like operating that way is one of the least cautious things to do, based on my experiences.

If I do disable SB, it's only to "fix" whatever prevents booting with it.

(EDIT: I just TLDR'd it)

gunrunnerjohn · Oct 16, 2025

Well, I figured it was only a matter of time before MSC was going to get more pushy about Secure Boot, so I decided to move ahead and get it done. Turns out with the great tools provided here, it's not that difficult to get everything lying flat and working.

I have to give kudos to folks like @Akeo and @garlin as well as others not mentioned for tolerating my many questions and assumptions during the process. Hopefully the great assistance received here has helped a bunch of people through this process.

RJARRRPCGP · Oct 16, 2025

Just updated the BIOS on my ASRock B550 PG Velocita to 3.90, and it has the 2023 KEK.

Buddywh · Oct 16, 2025

gunrunnerjohn said:
folks like @Akeo and @garlin as well as others not mentioned

Definitely... I do not believe I'd have gotten my "unsupported" antique PC in particular running with updated keys without the tools and, especially, information they've patiently provided here.

And to be clear, MOSBY has value well beyond simply working through key expirations. It's a type of tool we should have had available, and/or been more widely discussed, from the very launch of UEFI.

RJARRRPCGP · Oct 16, 2025

RJARRRPCGP said:
Just updated the BIOS on my ASRock B550 PG Velocita to 3.90, and it has the 2023 KEK.

https://pg.asrock.com/mb/AMD/B550 PG Velocita/index.us.asp#BIOS

Buddywh · Oct 16, 2025

RJARRRPCGP said:
https://pg.asrock.com/mb/AMD/B550 PG Velocita/index.us.asp#BIOS

I understand Asrock MB's can be a PITA to update BIOS... it's great to know you got yours done!

One thing to do is look in the SecureBoot variables (PK, KEK, DB and DBX in particular) in BIOS and click on one to see if you can see if there's a "DETAILS" line. Clicking on that shows me all the keys loaded in each of the variables in my MSI and Gigabyte BIOS's.

When I did that on my just-updated BIOS's for my new(er) systems (an MSI B450m Mortar and Gigabyte B550m Aorus Pro) I was dismayed to find that both of those MFR's had put in a complete chain of trust for themselves: MSI KEK and MSI DB keys, Gigabyte did the same.

I knew they'd own PK and it was not unique to my computer from information in MOSBY and here. I did not know they'd do that though and don't know what it gives them but don't want it on principle. I went back to MOSBY to create a completely unique chain of trust that I have full control of, all the way back to the PK.

It may not be needed, but I have the level of experience with this (now) to do it and it just seemed silly to leave a potential back-door wide open to exploitation by authoritarian regimes for their data gathering.

Did you manually update your Secure Boot Keys ?

Well-known member

My Computers

Active member

My Computer

Active member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Active member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

​

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Similar threads