Did you manually update your Secure Boot Keys ?

Buddywh · Oct 25, 2025

Globespy said:
So, if I did this and it said True (after 2 restarts etc), then my certs are updated and the mid 2026 thing is something that I need not worry about anymore?
Hopefully that will resolve the recent issues I've seen in EventViewer about certs and even TPM failing.

It means the "Windows UEFI CA 2023" cert is updated. That's one of the four certs needed to replace those expiring in 2026.

Look back for a post by @Scott, #1104, for two commands that update all four and as well installs 2023 signed boot files. Once successfully completed it also resolves the ID 1801 error.

Or just wait and let Microsoft run the update for you according to the schedule they've put your system on.

PerpetualCycle · Oct 25, 2025

Buddywh said:
Everything I read suggests they will continue to work for launching with Secure Boot so long as they remain in place. But the problem is if you ever reset CMOS, or anything similar which resets all keys to the 2011 defaults, then Windows will have to push new 2023 keys into variables again. If Microsoft stops using the three DB keys signed by the 2011 KEK then it will fail. And future updates to DBX for SVN updates (which they will do periodically) will also fail since they can not be signed with an expired 2011 key. We don't know what Microsoft will do for sure.

Bottom line: since HP has abandoned your system with no BIOS updates to provide 2023 defaults, unless they furnish Microsoft a KEK signed by them then the only way you can be sure of keeping your system running with secure boot is to use MOSBY. It's not really that hard to do... I learned so it can't be.

I reset my CMOS and still have them. I believe they are stored in the management engine storage on the chipset where other keys are.

Buddywh · Oct 25, 2025

PerpetualCycle said:
I reset my CMOS and still have them. I believe they are stored in the management engine storage on the chipset where other keys are.

If you mean you still have the four 2023 keys, or at least Windows UEFI CA 2023 and the Microsoft Corp. KEK 2K CA 2023, then you might have an updated BIOS.

PerpetualCycle · Oct 25, 2025

Buddywh said:
If you mean you still have the four 2023 keys then you might have an updated BIOS.

No I don't have an updated BIOS. They keys are stored in dedicated non-volitile RAM - there is nothing magical the motherboard manufacturers to make it stick, they are stored the same way as everyone is doing here.

I Actually removed my chip for some maintenance. The UEFI detected this as a new CPU and reset everything in CMOS:

Buddywh · Oct 25, 2025

PerpetualCycle said:
No I don't have an updated BIOS. They keys are stored in dedicated non-volitile RAM - there is nothing magical the motherboard manufacturers to make it stick, they are stored the same way as everyone is doing here.

I Actually removed my chip for some maintenance. The UEFI detected this as a new CPU and reset everything in CMOS:

That's good... I reset CMOS on one of systems and all my secure boot settings returned to defaults and I lost keys I added. So it seems motherboards behave differently, but that's not surprising I suppose.

PerpetualCycle · Oct 25, 2025

Buddywh said:
That's good... I reset CMOS on one of systems and all my secure boot settings returned to defaults and I lost keys I added. So it seems motherboards behave differently, but that's not surprising I suppose.

How did you reset CMOS?

Buddywh · Oct 25, 2025

PerpetualCycle said:
How did you reset CMOS?

Shorting pins on motherboard.

I should probably check the other systems to see how they are affected by a CMOS reset.

PerpetualCycle · Oct 25, 2025

That surprises me. I think these CA should be stored the same manner as a bitlocker key which should survive a CMOS reset. I have a dedicated cmos reset button. on my MB.

Buddywh · Oct 25, 2025

PerpetualCycle said:
That surprises me. I think these CA should be stored the same manner as a bitlocker key which should survive a CMOS reset. I have a dedicated cmos reset button. on my MB.

This was my old motherboard. Bitlocker uses the TPM for the key (not sure how exactly) and that requires TPM2.0, that old board only has TPM1.2. That may be part of what's going on. Again, another good reason to check my other systems.

But it will be really nice if my fears of losing keys from something as simple as a CMOS reset are unfounded! Now just have to avoid resetting keys to BIOS defaults or randomly putting Secure Boot into STANDARD mode which does the same.

PerpetualCycle · Oct 25, 2025

Buddywh said:
This was my old motherboard. Bitlocker uses the TPM for the key (not sure how exactly) and that requires TPM2.0, that old board only as TPM1.2. That may be part of what's going on. Again, another good reason to check my other systems.

Ah, yes the TPM (which is the chipset and Management Engine as I mentioned). The TPM stores them in dedicated NVRAM, which may be on the chipset - I am not sure. I suppose this may be one of the reasons Microsoft requires TPM 2.0 if this is the case.

XDarkEnforcerX · Oct 25, 2025

(Asus) Bios Custom/Mode

DB Management - Append Key

Public Key Certificate
Authenticated Variable
EFI PE/COFF Image

When I select Public it locates the OpROM 2023 certificate.der from the fat usb drive when loading it an "Enter GUID owner number pops up already filled I press enter again & append fails. Should I be using the Authenticated Variable instead ?? it's the OpROM certificate directly downloaded directly from Microsoft github.

AK6DN · Oct 25, 2025

Buddywh said:
This was my old motherboard. Bitlocker uses the TPM for the key (not sure how exactly) and that requires TPM2.0, that old board only has TPM1.2. That may be part of what's going on. Again, another good reason to check my other systems.

But it will be really nice if my fears of losing keys from something as simple as a CMOS reset are unfounded! Now just have to avoid resetting keys to BIOS defaults or randomly putting Secure Boot into STANDARD mode which does the same.

Or use Mosby and make a key recovery bootable USB that has all the cert's on it so you can reset and restore at any future time ...

AK6DN · Oct 25, 2025

drminer said:
The option ROM certificate is missing from the default DB. There is nothing you can do about that, since it managed by the motherboard manufacturer when the UEFI is updated. It just means some new add-on cards might not work if you returned the DB to the Default setting--at least until you updated from Windows again. The DBX entries in red just mean that these old DBX updates were never installed. The latest, version 1.6.1, should have been installed by Windows on October 14. The script is out of date and does not even check for version 1.6.1. The script can be easily updated to compare the current DBX with the following file: c:\windows\system32\securebootupdates\dbxupdate.bin. It just needs one line added at the end of the DBX checking section.

Latest Mosby release supports the 2023 Option ROM cert.

drminer · Oct 25, 2025

AK6DN said:
Latest Mosby release supports the 2023 Option ROM cert.

I was writing about the default DB, which is read-only. Mosby updates the current DB only.

Buddywh · Oct 25, 2025

XDarkEnforcerX said:
(Asus) Bios Custom/Mode

DB Management - Append Key

Public Key Certificate
Authenticated Variable
EFI PE/COFF Image

When I select Public it locates the OpROM 2023 certificate.der from the fat usb drive when loading it an "Enter GUID owner number pops up already filled I press enter again & append fails. Should I be using the Authenticated Variable instead ?? it's the OpROM certificate directly downloaded directly from Microsoft github.

I did. But I also had to use a PreSigned certificate binary, also downloaded from the Microsoft github. If I tried to use an unsigned certificate using the "Authenticated Variable" it would fail.

All that went by the wayside, however, once I used MOSBY to populate all the variables at once.

Buddywh · Oct 25, 2025

AK6DN said:
Or use Mosby and make a key recovery bootable USB that has all the cert's on it so you can reset and restore at any future time ...

Which I did!

mort · Oct 25, 2025

Very happy to report... I finally see an 1808 in event viewer !!

I was having trouble (like many others) getting the KEK to update. So I decided to give MOSBY a shot. After making the shell drive I was surprised to read this:

"Releases of UEFI Shell now also include Mosby (GitHub - pbatard/Mosby: Mosby – More Secure Secure Boot)
to help you update your Secure Boot variables as well as generate and install
your own Secure Boot signing key. Just type 'Mosby' to run it."

Here are the results I have now... How does this look to the experts ?????

drminer · Oct 26, 2025

mort said:
Very happy to report... I finally see an 1808 in event viewer !!

I was having trouble (like many others) getting the KEK to update. So I decided to give MOSBY a shot. After making the shell drive I was surprised to read this:

"Releases of UEFI Shell now also include Mosby (GitHub - pbatard/Mosby: Mosby – More Secure Secure Boot)
to help you update your Secure Boot variables as well as generate and install
your own Secure Boot signing key. Just type 'Mosby' to run it."

Here are the results I have now... How does this look to the experts ?????

View attachment 150450

There is obviously a problem; if everything updated correctly, AvailableUpdates would be set to 0x0. It seems that the program cannot validate that the two bootloaders have been updated. (In addition to the file mentioned in the green text, you should check whether X:\boot\bootx64.efi has been updated with the new certificate.) But first, let Windows try to fix the issue. Run the following two commands, one at a time, in an elevated Powershell window:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Wait one minute, then reboot. This command tells Windows to try to update the DB, KEK, and the bootloader. It does not revoke the 2011 certificate. Run the script again to see if AvailableUpdates is set to 0x0, which means success. There should also be a couple of lines at the bottom of the script results attesting that the bootloader has been updated and is currently loaded.

If this does not work, you will need to manually update the two bootloaders in the EFI partition, which is fairly easy to do.

Thierry 83200 · Oct 26, 2025

Hello, this is what mine says, is it correct? Thank you.

mort · Oct 26, 2025

drminer said:
If this does not work, you will need to manually update the two bootloaders in the EFI partition, which is fairly easy to do.

Yes, I was concerned about that 0x4000 result on available updates. I ran these commands:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x100 /f

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Now this is what I see:

Thank you

Did you manually update your Secure Boot Keys ?

Well-known member

My Computers

Syzygy

My Computers

Well-known member

My Computers

Syzygy

My Computers

Well-known member

My Computers

Syzygy

My Computers

Well-known member

My Computers

Syzygy

My Computers

Well-known member

My Computers

Syzygy

My Computers

Member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Member

My Computer

Well-known member

My Computer

Active member

Attachments

My Computer

Member

My Computer

Similar threads