Did you manually update your Secure Boot Keys ?

FIREMEDIC2700 said:

garlin​

ok can u explain this please when changing the convertconfig on a iso . which i did and saved it. but i dont know what this means can u explain
5. Run the Windows cmd script likely you normally would do.

Click to expand...

You are overthinking. Remember how you normally build a ISO from UUPDump which is what 5. Run the Windows cmd script likely you normally would do. means. It means just do it like normally.

1) Extract ZIP archive
2) Run uup_download_windows.cmd

All you do is add one extra step:
1) Extract ZIP archive
2) Edit the ConvertConfig.ini change UpdtBootFiles=0 to UpdtBootFiles=1 and save
3) Run uup_download_windows.cmd

It's similar to this, how to open door lock for tomorrow only. You need to turn your head to the left once and right once before inserting key like you do normally.

Remember your normal procedure is:
1) Walk to door
2) Insert key into lock and turn

so the above would become:
1) Walk to door
2) Turn your head to the left once and right once
3) Insert key into lock and turn

Almighty1 said:

It could be MS and/or HP since remember HP may decide to put the 2023 security stuff in a new BIOS and then it's already blocked by default.

Click to expand...

So, I get that if HP does the update and the blocking via a new BIOS update, the computer will be OK after June 2026 (regardless of any event).

To finish this up and not take more of your time. If my certs remain as they are, and MS does not pushes blocking the PCA 2011 cert in Oct, my W11 will be OK. You don't need to answer, unless the answer is No. Greets.

Bo

bo elam said:

So, I get that if HP does the update and the blocking via a new BIOS update, the computer will be OK after June 2026 (regardless of any event).

To finish this up and not take more of your time. If my certs remain as they are, and MS does not pushes blocking the PCA 2011 cert in Oct, my W11 will be OK. You don't need to answer, unless the answer is No. Greets.

Bo

Click to expand...

Yes, you have it correct. LOL. The messages are coming in faster than I can answer as my regular secure boot machine is being slowly updated with eveerything since May 28, 2025 until now so a few hundred things to push so I am using a machine from 2011 that does not use Secure Boot and still MBR and not GPT.

Almighty1 said:

Yes, you have it correct. LOL. The messages are coming in faster than I can answer as .........

Click to expand...

That's why you are @Almighty1 .........

Bo

Almighty1 said:

Microsoft's instructions will only get you one key, the Windows UEFI 2023 CA, you will still be missing the other three keys as Step 1 only does Windows UEFI 2023 CA. Step 2 does the bootmanager 2023, step 3 is for the DBX and step 4 is to enable the SVN.
...

Click to expand...

That's what I was seeing after running through Microsoft's instruction, I was getting only the one key loaded while others seemed to be getting all of them. And reading how MS was experiencing "issues" with some of their OEM "partners" got me concerned my boards might be some of them and I'd be left with problems no matter what. For all I knew Microsoft might simply end up telling a bunch of us to "disable Secure Boot" and consider replacing our devices for better security (one is unsupported on Win11 anyway).

I figured getting experience with MOSBY now, and loading all the keys well ahead of expiration was the better way to go if no other reason than just to know it can be done.

Almighty1 said:

Yes, it is 4 commands or 2 sets... so it's basically this which you need to do in PowerShell in elevated Adminstrator mode:
Set #1 which consists of:

This is to add the 2023 boot manager:
#1

Code:

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

#2

Code:

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

I do not know if you need to reboot before you do the following or not.

This is Set #2:
This is to enable the SVN (Secure Version Number) which Microsoft describes as follows:
"The Boot Manager deployed above has a new self-revocation feature built-in. When the Boot Manager starts to run, it performs a self-check by comparing the Secure Version Number (SVN) that is stored in the firmware, with the SVN built into the Boot Manager. If the Boot Manager SVN is lower than the SVN stored in the firmware, the Boot Manager will refuse to run. This feature prevents an attacker from rolling back the Boot Manager to an older, non-updated version."
which is done with these two commands in PowerShell:

#1

Code:

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

#2

Code:

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

Remember Microsoft's instructions wants people to add the PCA 2011 blocking to the DBX (forbidden booting list) so while you don't show a PCA 2011 in the DBX yet, if Microsoft pushes the update for the PCA 2011 blocking and somehow you don't get updated to the 2023 Boot Manager, then you will not be able to boot.

Click to expand...

that is a option simply because unless u have made iso files and installed them with a 2023 certs. the 2011 os will not boot if 2011 ca is removed . just like the svn is a option . Go back and read post 793-797. Garlin pretty much gives u a break down of how certs will boot . And you can always turn off secure boot and all of this is simply as they say a fart in the wind.

FIREMEDIC2700 said:

...
And you can always turn off secure boot and all of this is simply as they say a fart in the wind.

Click to expand...

Hmm... yeah but the stink's still really bad if you're in an outhouse.

Buddywh said:

That's what I was seeing after running through Microsoft's instruction, I was getting only the one key loaded while others seemed to be getting all of them. And reading how MS was experiencing "issues" with some of their OEM "partners" got me concerned my boards might be some of them and I'd be left with problems no matter what. For all I knew Microsoft might simply end up telling a bunch of us to "disable Secure Boot" and consider replacing our devices for better security (one is unsupported on Win11 anyway).

I figured getting experience with MOSBY now, and loading all the keys well ahead of expiration was the better way to go if no other reason than just to know that it can be done.

Click to expand...

Step 1 only tells you to check for "Windows UEFI 2023 CA" so if it really did 4, it will tell you to check for all 4 and not just that first one. They seem to prioritize October 2026 over the June 2026 secure boot keys.

Buddywh said:

That's what I was seeing after running through Microsoft's instruction, I was getting only the one key loaded while others seemed to be getting all of them. And reading how MS was experiencing "issues" with some of their OEM "partners" got me concerned my boards might be some of them and I'd be left with problems no matter what. For all I knew Microsoft might simply end up telling a bunch of us to "disable Secure Boot" and consider replacing our devices for better security (one is unsupported on Win11 anyway).

I figured getting experience with MOSBY now, and loading all the keys well ahead of expiration was the better way to go if no other reason than just to know it can be done.

Click to expand...

The instruction specifically tells you it is only for the Windows 2023 UEFI only.



Yes, having Mosby experience is better than having no Mosby experience.

FIREMEDIC2700 said:

that is a option simply because unless u have made iso files and installed them with a 2023 certs. the 2011 os will not boot if 2011 ca is removed . just like the svn is a option . Go back and read post 793-797. Garlin pretty much gives u a break down of how certs will boot . And you can always turn off secure boot and all of this is simply as they say a fart in the wind.

Click to expand...

I wouldn't even worry about Secure Boot booting as the motherboard that died will boot all WinPE fine with Secure Boot off using Ventoy. The replacement motherboard for the notebook works for everything and the only ISOs that boot with Secure Boot off is Hiren's BootCD, Minitool Partition Wizard 13.0, Windows 11 24H2 Beta Insiders ISO with 2011 and 2023 bootmanager but everything else like Macrium Reflect 8, DiskGenius, AOMEI Partition Partition Assistant will all end up with a BSOD Kernel Security Check Failure. Maybe the issue is in the BIOS itself.

FIREMEDIC2700 said:

that is a option simply because unless u have made iso files and installed them with a 2023 certs. the 2011 os will not boot if 2011 ca is removed . just like the svn is a option . Go back and read post 793-797. Garlin pretty much gives u a break down of how certs will boot . And you can always turn off secure boot and all of this is simply as they say a fart in the wind.

Click to expand...

The answer is in #793 itself which already summarizes everything in a nutshell.

Almighty1 said:

...

The instruction specifically tells you it is only for the Windows 2023 UEFI only.
...

Click to expand...

Yeah I did read that, but I was still concerned since I was seeing several others were getting more of the keys (still not exactly sure why, that) and after reading Microsoft's comments.

I'm perfectly aware that things are always going just great and to trust Microsoft to figure it out, right up to the point they're not.

Almighty1 said:

So at least it seems that if what Microsoft said is correct, the Mosby SVN 3.0 because I did step 4 manually would cause a failure since it would be expecting 7.0.

Click to expand...

That's not how SVN works. It's not "The SVN from the bootloader must be the same as the SVN from the Secure Boot database else it will not boot".

Instead it's "As long as the SVN from the bootloader is greater than the SVN from the Secure Boot database, let it through". In other words, the SVN is a minimum allowed version number.

Therefore, Mosby (currently) installing a 3.0 SVN in the Secure Boot database is no issue at all, even if you applied the latest Windows updates and have Windows bootloaders that use a 7.0 SVN because 7.0 > 3.0.

Instead, once Microsoft pushes the 7.0 Secure Boot database SVN update, and I include it in Mosby, and you use that newer version of Mosby, it will become a problem to, say, boot 24H2 Windows installation media on that platform created from the public 24H2 ISO, because the 24H2 installation media bootloaders use SVN 3.0, and 3.0 < 7.0 so you will get this kind of screen (albeit with Minimum allowed version saying 7.0):



So that's what SVN does. It simply checks if the SVN number (yeah, I know, just like PIN number) in the Windows UEFI bootloader you are trying to boot (it doesn't apply to anything else, only Windows bootloaders) is greater than the SVN number in your Secure Boot database, and prevents boot if that is not the case. For those who are familiar with Linux/Shim SBAT, that's basically SBAT, but for Windows instead of Linux.

Oh, and of course, this only applies when Secure Boot is active, so you can still turn Secure Boot off and let Windows fix itself if that happens, because, as far as I know, Microsoft designed the versions of Windows that support SVN to always check if the installed bootloader uses an obsolete SVN (which basically means that it's a an old, not up to date Windows bootloader) and update it through Windows Update if that is the case. So a Windows system should automatically "fix itself" if you encounter SVN validation issues. But of course, that only works for fully installed systems, and not when you are trying to install Windows itself, hence why you will encounter issue with a fully up to date Secure Boot system, with SVN updated to 7.0 if you attempt to boot a 24H2 Windows installation media there (the fault being with Microsoft, who refuse to follow common security best practices and release refreshes of their public Windows 11 installation ISOs, like Linux distros do, when they find and fix security issue in their bootloaders).

And now that I've thrown more information into the mix, have a ball.

Akeo said:

....

And now that I've thrown more information into the mix, have a ball.

Click to expand...

A few questions... how will having used MOSBY interact with future Win11 security updates if (or as, since I assume they will since that's what it's for) Microsoft rolls minimum allowed SVN's?

Do you foresee a scenario where we'd have to update our MOSBY USB and run it again to stay consistent?

Will doing the "turn Secure Boot off and letting Windows fix itself" route still work correctly (for a fully installed Windows system) with MOSBY populated secure boot variables?

I ask all this because I'm not confident that the post was written in a context inclusive of a MOSBY populated system.

well hell i just updated the svn via ms instructions i sure hope i did not screw anything up .
how can u check your svn if u followed the microsoft instructions ?
I did not have a computer when we hit 2000 i wonder how this compares to the y2k cluster

well here goes nothing after my modified windows 10 iso goes in ventory i will try to reboot after updating my svn manually.

FIREMEDIC2700 said:

...
how can u check your svn if u followed the microsoft instructions ?
...

Click to expand...

And at any point in the future. It might be a good thing to know since it sounds like MS will be rolling this as needed in security updates going forward.

Buddywh said:

Do you foresee a scenario where we'd have to update our MOSBY USB and run it again to stay consistent?

Click to expand...

Nope. Because Mobsy install the Microsoft KEKs (2011 and 2023), which is all that's needed for any OS (or even third parties) to install the signed SVN update packages published in secureboot_objects/PostSignedObjects/DBX at main · microsoft/secureboot_objects. This means Windows, Linux or whatever Secure Boot aware OS you are using will have no issue whatsoever updating the DBX (and the SVN, which is part of your run-of-the-mill DBX updates).

The temporarily turn Secure Boot off and let Windows fix itself only applies if you manually updated your SVN and find out that your Windows bootloader was using a lower version than the one you just installed (in which case Windows Updates should fix it for you because, of course, Microsoft always has UEFI bootloaders, with a version at least equal to the latest SVN update they pushed, as part of Windows Updates).

FIREMEDIC2700 said:

how can u check your svn if u followed the microsoft instructions ?

Click to expand...

Yeah... It would be nice if the PowerShell script also reported the current SVN of the platform it's running on (hint, hint ).

Basically, you just need to look at the DBX for a revocation entry that starts with a specific GUID, and then you will find the current SVN of the platform after that GUID. See this specific post for more details.

Akeo said:

Nope. ...

Click to expand...

Great to know...

But one last... should we make a practice of always updating our MOSBY USB should we need to repopulate the secure boot variables (illogical perhaps, but lets just say) at some future date? That's to avoid any issues should MS have rolled up SVN's that leave whatever SVN is in the current USB invalid.

Buddywh said:

MOSBY has you first put UEFI in SETUP mode... or delete all the secure boot keys which does the same thing in my BIOS'. That forces it to boot with Secure Boot off, and boot to the MOSBY USB recovery, whereupon you run MOSBY to repopulate all the keys including the 2023 keys. It may have to either be in SETUP mode or booting with Secure Boot if doing it in the OS (pure speculation on my part).

I haven't tried the Microsoft Method. Can't now because Windows won't create a recovery USB for me. I can create a MOSBY recovery USB at any time using RUFUS.

Click to expand...

I didn't try the Microsoft Method simply because I read the enormous multi-step procedure they posted that ran on for pages! MOSBY was way simpler to do this job.