Did you manually update your Secure Boot Keys ?

Almighty1 · Sep 28, 2025

And this may create a new industry, someone that modifies existing video BIOS files with the CA 2023 either providing them for free or charging everyone for it.

Almighty1 · Sep 28, 2025

Cy_kkm said:
Nope, it doesn't, see my post just above. As long as they put the Microsoft UEFI CA 2011 cert into the untrusted signers list (dbx) after its expiration, it won't recognise the VBIOS in secure mode.

Turning off SB in indeed a solution, but I don't want this solution. UEFI rootkits are extremely nasty. If they recently managed to sneak black lotus into machines with SB on, I'd better keep it on, thanks...

You wrote right after I did, how does the computer tell it's really after July 1, 2026 or not assuming you turned ntp synchronization off though? Since this is part of booting, it's way before it connects to the Internet so it can only use the only time source available, the RTC, where else would it get the current time/date from?

Regardless, let's see what actually happens as we are really speculating. Let's see what NVIDIA actually does as we do not hear about the problem with AMD, Intel, Matrox who also have GPUs unless NVIDIA is the only one who signs their VBIOS with certificates. Is there a way to check what the installed VBIOS is actually signed by?

KevTech · Sep 28, 2025

In the reddit thread there are links to official Nvidia tools to update GOP.
Also have unofficial tools.

Cy_kkm · Sep 28, 2025

garlin said:
some VBIOS'es have signed themselves, in order to allow the UEFI to trust it.

You must be confusing something. You may roll your own security, get the db and dbx out of your UEFI (if you have a second, working video), remove the offending hashes from the dbx, sign with your (second) KEK and upload to the secure variables. The problem is, dbx is pretty large, and keeps growing, so MS will update it from time to time.

If self-signed UEFI binaries worked, so would self-signed rootkits. This makes no sense. Really, only you are the ultimate authority who decides which signers are good and which are untrusted (or, rather, whoever holds the private key of your PK, the platform key). The only thing, you need to construct your UEFI chain of trust such that MS' KEK is valid for updates, too. But really, you're simply delegating MS that authority. Really, the OEM put in their PK, so they delegated a lot of trust to MS. And if you want to run Windows, you probably want it, too, or they won't be able to update their UEFI boot-time stuff.

Almighty1 · Sep 28, 2025

Almighty1 · Sep 28, 2025

Cy_kkm said:
You must be confusing something. You may roll your own security, get the db and dbx out of your UEFI (if you have a second, working video), remove the offending hashes from the dbx, sign with your (second) KEK and upload to the secure variables. The problem is, dbx is pretty large, and keeps growing, so MS will update it from time to time.

If self-signed UEFI binaries worked, so would self-signed rootkits. This makes no sense. Really, only you are the ultimate authority who decides which signers are good and which are untrusted (or, rather, whoever holds the private key of your PK, the platform key). The only thing, you need to construct your UEFI chain of trust such that MS' KEK is valid for updates, too. But really, you're simply delegating MS that authority. Really, the OEM put in their PK, so they delegated a lot of trust to MS. And if you want to run Windows, you probably want it, too, or they won't be able to update their UEFI boot-time stuff.

The problem is with OEM or any PK's known to the public, that's where the root of all evil will come from. That's the reason for Mosby which creates a unique private PK which will be used for everything you personally use that same USB Flash Drive until you delete the Mosby Private Key so it generates a new one for that installation.

garlin · Sep 28, 2025

Cy_kkm said:
You must be confusing something. You may roll your own security, get the db and dbx out of your UEFI (if you have a second, working video), remove the offending hashes from the dbx, sign with your (second) KEK and upload to the secure variables. The problem is, dbx is pretty large, and keeps growing, so MS will update it from time to time.

If self-signed UEFI binaries worked, so would self-signed rootkits. This makes no sense. Really, only you are the ultimate authority who decides which signers are good and which are untrusted (or, rather, whoever holds the private key of your PK, the platform key). The only thing, you need to construct your UEFI chain of trust such that MS' KEK is valid for updates, too. But really, you're simply delegating MS that authority. Really, the OEM put in their PK, so they delegated a lot of trust to MS. And if you want to run Windows, you probably want it, too, or they won't be able to update their UEFI boot-time stuff.

I'm not here to debate the UEFI eco-system, just explaining what a normal user can do.

If you're committed and technical, sure roll your own like Mosby does. For everyone else in the normal world, there's probably a less than perfect solution so everyone can continue using their PC's.

TraderGary · Sep 28, 2025

KevTech said:
Saw this on the Dell site for those who have Dell PC.

Microsoft 2011 Secure Boot Certificate Expiration | Dell US

My Dell XPS 9640 has BIOS 1.17.0.
- This BIOS contains the new 2023 Secure Boot Certificates.

Akeo · Sep 29, 2025

Buddywh said:
So do you think MS will enforce revoking trust in the CA 2011 cert? Won't that wreak havoc with a lot of people's systems that still use 3rd party binaries signed by it?

It will not.

This is because there are TWO main 2011 certificates: Microsoft Windows Production PCA 2011, which Microsoft uses to sign Windows bootloaders exclusively, and which is the only certificate that is being revoked, and Microsoft Corporation UEFI CA 2011 which is used to sign third party bootloaders. So, NO, third party bootloaders are not going to stop working because the 2011 certificate for third party bootloaders is NOT being revoked (and as I explained earlier, even its soon to happen expiration will not make these third party booloaders fail Secure Boot validation after it expires, because Secure Boot does not check the expiration date for validation). Oh and since technically, there also might be third 2011 certificate used for Option ROMs, that third certificate is not being revoked either, so Option ROMs will continue to work just fine, even if you add PCA 2011 to the DBX.

In short: The only UEFI binaries that are going to fail Secure Boot validation once you add the PCA 2011 cert to the DBX are Windows UEFI bootloaders. Option ROMs will be fine. Thirst party UEFI booloaders (like Linux Shim and so on) will be fine. The revocation of PCA 2011 will NOT affect those.

And that is the reason the only thing you need to care about if you add PCA 2011 to your DBX is whether you updated the Windows Bootloaders you are using to launch Windows to the 2023 signed version, as Windows will not boot otherwise. But everything else that is not Windows will be completely unaffected by the revocation.

This is actually by design, because, due to BlackLotus, Microsoft had so many vulnerable UEFI Windows bootloaders to revoke that they decided it was easier to revoke the one certificate they used to sign all these bootloaders (and only these booloaders) than add the hash of hundreds of individual Windows bootloaders to the DBX.

Akeo · Sep 29, 2025

Almighty1 said:
That's the reason for Mosby which creates a unique private PK which will be used for everything you personally use that same USB Flash Drive until you delete the Mosby Private Key so it generates a new one for that installation.

Almost, but not quite. The key you find on the flash drive, and that gets reused, is NOT the PK. The PK is always created from scratch each time you use Mosby, so even if you use the same flash drive on 10 different machines (or the same flash drive 10 times in on one machine), a unique PK will be created each time. There is no sharing/reuse of the PK by Mosby, ever. If you use Mosby, all your PCs will have a completely different and unique PK.

The key that you see being saved to the USB drive and reused if it exists is the key that gets adeed to the DB (a different beast from PK) and that you can use to sign your own UEFI binaries so that they work with Secure Boot (in the same way as Microsoft signs their Windows bootloaders or third party bootloaders for Secure Boot), because, obviously, if you start signing your own bootloaders for Secure Boot, it would be inconvenient if you had to apply a different signature (and therefore use different signed bootloaders) for every machine you own...

In other words: The key being saved by Mosby is a DB key. The PK used by Mosby is always created, every time Mosby runs, and discarded after use (meaning that it cannot be reused... which is the whole point).

Almighty1 · Sep 29, 2025

Akeo said:
Almost, but not quite. The key you find on the flash drive, and that gets reused, is NOT the PK. The PK is always created from scratch each time you use Mosby, so even if you use the same flash drive on 10 different machines (or the same flash drive 10 times in on one machine), a unique PK will be created each time. There is no sharing/reuse of the PK by Mosby, ever. If you use Mosby, all your PCs will have a completely different and unique PK.

The key that you see being saved to the USB drive and reused if it exists is the key that gets adeed to the DB (a different beast from PK) and that you can use to sign your own UEFI binaries so that they work with Secure Boot (in the same way as Microsoft signs their Windows bootloaders or third party bootloaders for Secure Boot), because, obviously, if you start signing your own bootloaders for Secure Boot, it would be inconvenient if you had to apply a different signature (and therefore use different signed bootloaders) for every machine you own...

In other words: The key being saved by Mosby is a DB key. The PK used by Mosby is always created, every time Mosby runs, and discarded after use (meaning that it cannot be reused... which is the whole point).

That's even better. I forgot to screenshot the successful Mosby usage and you are right, it only seems to use the MosbyKey.crt if it exists and the MosbyKey.pem and MosbyKey.pfx. It always will Generate the PK certitifcate.

I did sign two .efi's (bootx64.efi and PowerMonkey.efi to use PowerMoney) with the MosbyKey.pfx successfully yesterday, haven't tried booting with PowerMoney yet to see if it will boot with SecureBoot as the instructions I was given was to use sbctl in Linux except I don't have a Linux installation I can use and this seems to basically do the same thing.

1) Does the MosbyKey.crt, MosbyKey.pem also need to be copied like for example, if I am using Rufus to create a new UEFI Shell including Mosby on a different flash drive, it seems like MosbyKey.crt, MosbyKey.pem, MosbyKey.pfx are the only files I need to backup and restore to the new USB Flash Drive.

2) Does Mosby actually handle installing/enabling the new boot manager 2023 and also enable the SVN for the boot manager 2023 or do one or both of those still need to be done manually?

For the other stuff, I will figure it out from the using it and then update the earlier tutorial.

Akeo · Sep 29, 2025

Almighty1 said:
1) Does the MosbyKey.crt, MosbyKey.pem also need to be copied like for example, if I am using Rufus to create a new UEFI Shell including Mosby on a different flash drive, it seems like MosbyKey.crt, MosbyKey.pem, MosbyKey.pfx are the only files I need to backup and restore to the new USB Flash Drive.

Mosby tells you explicitly that you should keep and copy the MosbyKey files if you want to use the same credentials to sign bootloaders for other machines. So, if you recreate a new Mosby drive, and want your existing signed bootloaders, or sign new ones that work on machines were you already ran Mosby, you should copy the .crt there (only the .crt is actually needed. The .pem and .pfx are used for the actual process of signing the files, but not for the installation of the cert in the DB).

Almighty1 said:
2) Does Mosby actually handle installing/enabling the new boot manager 2023 and also enable the SVN for the boot manager 2023 or do one or both of those still need to be done manually?

Once you know that SVN stands for Secure Version Number, your screenshot gives you the answer to that.

Code:

Installing DBX:  'Microsoft's 'Secure Version Number' DBX entries [2025.01]'

Mosby always install the most recent elements related to Secure Boot, as they were defined at the time Mosby was compiled. That includes the SVN (and as an asside, that includes SBAT too). Note however that there has been SVN updates since 2025.01, but, if you run Windows of you have a Linux system that takes security seriously and applies DBX updates as they appear, the OS will take care of updating the SVN for you, as SVN is part of regular DBX updates (except Microsoft is once again treating security for people who don't use Windows as a joke, which means that they did not push the public DBX SVN update to their secureboot_ojbjects repo as they should have done the minute they pushed that update in Windows, and I had to, yet again, report that they are doing a lousy job with that (which they still haven't fixed even though I opened that issue 3 weeks ago).

Currently, the SVN installed by Mosby would be 3.0.
The SVN that should be updated by Linux and third party OSes that are Secure Boot aware, and that rely on the Secure Boot objects published by Microsoft would be 5.0.
And the SVN that gets updated by Windows 11is currently 7.0.

But again, if you have a competent OS, it shouldn't matter that the SVN installed by Mosby is a little behind, as the OS should detect and fix that automatically (since it's a run of the mill standard DBX updates, that modern OSes perform for you all the time... provided Microsoft does publish up to date DBX signed packages, which they currently don't).

Oh, and I thought it would become clear at this point that the 2023 certs that get installed as part as running Mobsy are to handle the new 2023 boot managers...

Buddywh · Sep 29, 2025

Akeo said:
It will not.

This is because there are TWO main 2011 certificates: Microsoft Windows Production PCA 2011, which Microsoft uses to sign Windows bootloaders exclusively, and which is the only certificate that is being revoked, and Microsoft Corporation UEFI CA 2011 ...

I knew that... and forgot it when I asked the question. Idiot me.

Thanks... that explains a lot.

Buddywh · Sep 29, 2025

garlin said:
....

The choice will be to run with Secure Boot disabled, or to delete CA 2011 from the DBX. Neither is ideal because the whole point of this exercise was to improve system security. It's like the industry spent all this time talking to PC/mobo makers, but left out the video OEM's. I'm just wonder what about the NIC vendors (if you do network boot)...

I'm going to ensure CA 2011 never gets added to the DBX. That's one good aspect of MOSBY in that it's an option you have to conciously exercise (-x) to do so.

I don't feel Black Lotus is a serious threat to me as an average home PC user. But I can definitely see the issues confronting corporate and other high-risk networks if the mfrs of the systems they purchase don't support them with BIOS and vBIOS updates where needed.

A system BIOS update should update integrated NIC certificates too... it would be the discrete NIC's I think at risk for network boots.

FIREMEDIC2700 · Sep 29, 2025

can someone please make this code into a reg file so all i have to do is click to add to the registry . i am not to savy with trying to edit the registry

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x100 /f<br>Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Sheikh · Sep 29, 2025

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

You can't convert this part to a .reg file

FIREMEDIC2700 · Sep 29, 2025

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" should this be ran in a command prompt or power shell command ?

Buddywh · Sep 29, 2025

FIREMEDIC2700 said:
reg add ..... REG_DWORD /d 0x100 /f

I think you just type that part (or copy/paste) into a powershell session (with admin priv.) It does the necessary registry editing for you, or at least it did for me.

(btw... copy it from the Microsoft KB article. I've no idea if what you put in your post is valid or what it would add to the registry, hence the elipses.)

Then run the "start-scheduled task...." part (also in the powershell session), it starts the task and does whatever that registry entry is telling it to do (also copy/paste the full line from the KB article ONLY).

FIREMEDIC2700 · Sep 29, 2025

Buddywh said:
I think you just type that part (or copy/paste) into a powershell session (with admin priv.) It does the necessary registry editing for you, or at least it did for me.

(btw... copy it from the Microsoft KB article. I've know idea if what you put in your post is valid or what it would add to the registry.)

Then run the "start-scheduled task...." part (also in the powershell session), it starts the task and does whatever that registry entry is telling it to do.

thanks i just got it figured out after trial and error

garlin · Sep 29, 2025

FIREMEDIC2700 said:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" should this be ran in a command prompt or power shell command ?

This is a PowerShell command. If you're running or scripting it in CMD:

Code:

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

Did you manually update your Secure Boot Keys ?

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Stock Market Wizard

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computer

Software Developer

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Similar threads