Did you manually update your Secure Boot Keys ?

neves · Sep 28, 2025

IF OEMs do their job - will be a simple as a typical Windows Update. Tho, old unsupported systems - which probably won't get an update - is a whole different story. But when it comes to them - it's intentional - since there's no profit to be made from them - so it's both in OEMs and Microsoft interest - for them to buy a new PC - and for this reason, it's possible they'll be left out.

Almighty1 · Sep 28, 2025

gunrunnerjohn said:
I'm not quite there yet, but I'll keep watching this space for updates. I am booting with secure boot with the 2023 certificate and have the Windows 2011 certificate revoked, so I'm good with Windows. I'm missing the Option 2023 CA cert.

I am at a loss as to how your script would update the BIOS tables.

In the other thread - weren't you the one who actually had the Option 2023 CA Certificate originally and asked about it? If so, what happened to it? I actually learned about Mosby and how to get it working from the questions you were asking @Akeo

Almighty1 · Sep 28, 2025

gunrunnerjohn said:
That's where I find myself for two of the four systems I was updating, hence my interest in figuring out Mosby and some of the in's-n-out's of the secure boot environment. I figured I'm about 30% of the way to understanding all of it, a long ways to go.

The understanding part isn't that hard after @Akeo and the PDF document at my earlier comment at Did you manually update your Secure Boot Keys ? did a pretty good explanation.

Almighty1 · Sep 28, 2025

neves said:
IF OEMs do their job - will be a simple as a typical Windows Update. Tho, old unsupported systems - which probably won't get an update - is a whole different story. But when it comes to them - it's intentional - since there's no profit to made from them - so it's both in OEMs and Microsoft interest - for them to buy a new PC - and for this reason, it's possible they'll be left out.

100% in agreement with everything said since it's about the bottom line as neither Microsoft nor the hardware manufacturers want to put money into supporting older systems when their business model is new sales coming in as it will not benefit the industry which includes Intel and AMD.

Buddywh · Sep 28, 2025

garlin said:
....

If correctly scripted, you can arrive at one of MS's recommended vendor outcomes for the UEFI which includes 2 KEK certs, 2 DB CA 2011 certs, 3 DB CA 2023 certs, and 1 DBX CA 2011 cert. And update the boot manager on the system drive's EFI, and update your bootable USB drives.

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?

Will MS at least give us an option to not revoke trust... although almost nobody (who's not followed this thread LOL) will understand the ramifications either way.

I'm thinking here especially of GPU vBIOS binaries. I don't really know if, or how, they are signed, only that a GPU has to be UEFI aware to run in UEFI mode so assumed that's the case.

neves · Sep 28, 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?

Revoking a CA doesn't automatically “brick” all binaries ever signed by it in all contexts. Trust enforcement varies between kernel-mode code, user-mode code, UEFI firmware checks, Secure Boot DB, Authenticode verification, etc.

Buddywh said:
I'm thinking here especially of GPU vBIOS binaries. I don't really know if, or how, they are signed, only that a GPU has to be UEFI aware to run in UEFI mode so assumed that's the case.

GPU vBIOS / Option ROMs don’t use Windows authenticode signing. They’re validated (if at all) via UEFI Secure Boot databases - which use UEFI keys, not general-purpose Microsoft or third party CAs like CA 2011. That being said, revoking a Windows code-signing CA won’t affect GPU firmware loading.

Historically, when Microsoft has retired CAs (like the SHA-1 deprecation), they’ve implemented phased rollouts and compatibility fixes. The idea that they’d just flip a switch and "wreak havoc" is rather unrealistic.

Buddywh · Sep 28, 2025

neves said:
...

GPU vBIOS / Option ROMs don’t use Windows authenticode signing. They’re validated (if at all) via UEFI Secure Boot databases - which use UEFI keys, not general-purpose Microsoft or third party CAs like CA 2011. That being said, revoking a Windows code-signing CA won’t affect GPU firmware loading.
...

So do you think the concerns about GPU's being rendered incapable of supporting secure boot (by the Microsoft certificates expiring) if they don't get vBIOS updates is... let's say over-hyped?

There are always exceptions, and that would doubtless be the case here too, but I certainly do hope the "sky is falling" perspective isn't deserved.

gunrunnerjohn · Sep 28, 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?

Will MS at least give us an option to not revoke trust... although almost nobody (who's not followed this thread LOL) will understand the ramifications either way.

I'm thinking here especially of GPU vBIOS binaries. I don't really know if, or how, they are signed, only that a GPU has to be UEFI aware to run in UEFI mode so assumed that's the case.

Are you talking about 3rd party bootable USB or the like? Plain applications shouldn't be affected by the secure boot process. I have secure boot enabled and the CA 2011 certificate revoked, my ancient applications still run fine. As for the bootable 3rd party applications, garlin posted a simple fix for those.

Margarita · Sep 28, 2025

@Akeo Thanks
@gunrunnerjohn Thanks

garlin · Sep 28, 2025

The GPU signing problem is legitimate and serious. Normally the UEFI communicates with the primary GPU, and has to trust it. The GPU gets its own firmware CA 2011 certificate to present to UEFI. As soon as you add CA 2011 to DBX, the GPU is no longer trusted.

Well, now you don't have video for UEFI. Or maybe the UEFI won't pass HW checks and boot up.

For newer GPU's, the vendors will probably rush out new firmware with a CA 2023 cert added on. For older GPU's, you're screwed.

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)...

gunrunnerjohn · Sep 28, 2025

I didn't do anything to my GPU, I've revoked the 2011 certificate, and the machine boots fine. I never even though about the GPU...

Almighty1 · Sep 28, 2025

gunrunnerjohn said:
I didn't do anything to my GPU, I've revoked the 2011 certificate, and the machine boots fine. I never even though about the GPU...

It's in the link in the comment in this thread:

Did you manually update your Secure Boot Keys ?

I'll address the elephant in the room since I don't see any of these threads mention it, i.e., those of us who have unsupported Windows 11 systems, machines that are too old to have the manufacturer supply a BIOS fix. It looks like to me Microsoft's own fix will not work with our machines, and...

www.elevenforum.com

From reading, I will not be affected as the notebook uses the built in Intel CPU for the graphics and the NVIDIA GPU is really secondary and that feeds via the Intel CPU's built-in GPU.

gunrunnerjohn · Sep 28, 2025

I am not using the Intel built-in graphics, I have an RTX-4060 that's much more suitable for 3D design work.

Almighty1 · Sep 28, 2025

gunrunnerjohn said:
I am not using the Intel built-in graphics, I have an RTX-4060 that's much more suitable for 3D design work.

Time will tell since it's NVIDIA that needs to throw you a bone as the video bios is in their court.... I'll probably have a new current machine when that time comes....

Some Older NVIDIA Graphics Cards May Not Boot Correctly with Windows Secure Boot After June 2026

A Redditor who goes by gaseousgalaxy, in a detailed post, claims that some of the older NVIDIA GeForce GPUs with UEFI-capable video BIOS could face problems booting with Windows Secure Boot enabled, as their UEFI GOP (graphics output protocol) security certificate expires in June 2026. UEFI GOP...

www.techpowerup.com

KevTech · Sep 28, 2025

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

Microsoft 2011 Secure Boot Certificate Expiration | Dell US

AK6DN · Sep 28, 2025

garlin said:
The GPU signing problem is legitimate and serious. Normally the UEFI communicates with the primary GPU, and has to trust it. The GPU gets its own firmware CA 2011 certificate to present to UEFI. As soon as you add CA 2011 to DBX, the GPU is no longer trusted.

Well, now you don't have video for UEFI. Or maybe the UEFI won't pass HW checks and boot up.

For newer GPU's, the vendors will probably rush out new firmware with a CA 2023 cert added on. For older GPU's, you're screwed.

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 am really confused at this point about the exact meaning of the 'expiration date' (aka NOT AFTER date) on certificate entries in both BIOS and GPU contexts.

(1) I have seen some commenters say the NOT AFTER date on a certificate means anything signed with that certificate will turn into a proverbial pumpkin on and after that date. A Y2K problem on steroids. Your system will not boot, your GPU will black screen. Full doomsday.

(2) I have also seen that the NOT AFTER date on a certificate just means you can't sign anything with that certificate after that date. But if the certificate is present, the software/BIOS/VBIOS will still function normally until the end of time. It is just that that certificate can't be used to sign anything after that date.

So these are two very different outcomes. The first implies some hardware might be bricked upon certificate expiration (unless the vendor provides a BIOS/VBIOS upgrade which will not happen for older out-of-support hardware).

The second is just an inconvenience. Hardware keeps working. But software (mainly newly installed UEFI bootloaders) need to be signed by a newly installed unexpired certificate (ie, the xxx2023xxx updates). As long as the legacy xxx2011xxx certificates are still present in DB/KEK (and not in DBX), and the new xxx2023xxx certificates are added to KEK/DB you are ok.

Turning off secure boot seems to be the solution in case of #1. #2 is still secure boot, but needs new certificates installed.

Almighty1 · Sep 28, 2025

AK6DN said:
I am really confused at this point about the 'expiration date' (aka NOT AFTER data) on certificate entries in both BIOS and GPU contexts.

(1) I have seen some commenters say the NOT AFTER date on a certificate means anything signed with that certificate will turn into a proverbial pumpkin on and after that date. A Y2K problem on steroids. Your system will not boot, your GPU will black screen. Full doomsday.

(2) I have also seen that the NOT AFTER date on a certificate just means you can't sign anything with that certificate after that date. But if the certificate is present, the software/BIOS/VBIOS will still function normally until the end of time. It is just that that certificate can't be used to sign anything after that date.

So these are two very different outcomes. The first implies some hardware might be bricked upon certificate expiration (unless the vendor provides a BIOS/VBIOS upgrade which will not happen for older out-of-support hardware).

The second is just an inconvenience. Hardware keeps working. But software (mainly newly installed UEFI bootloaders) need to be signed by a newly installed unexpired certificate (ie, the xxx2023xxx updates).

Turning off secure boot seems to be the solution in case of #1. #2 is still secure boot, but needs new certificates installed.

See this comment:

Some Older NVIDIA Graphics Cards May Not Boot Correctly with Windows Secure Boot After June 2026

It's all part of the Master Plan. The general PC user population figured out that they have no need to upgrade their computers or that they can do everything they need to on their phones, so They are forcing the people who actually need a PC, but have no idea what Linux is, to upgrade to keep...

www.techpowerup.com

which basically would invalidate #1. #2 has already been explained by @Akeo in a earlier post in this thread that it just needs to be signed while the certificate is valid and the expiration date only does not allow signing with that certificate after it has expired but has no bearing if it was already signed prior to the expiration date.

Cy_kkm · Sep 28, 2025

AK6DN said:
Since all the certificate validation/invalidation is based on what the current month/day/year is

No, not really. Most retails mobos don't even bother checking the RTC. It's not a secure time source. The certificate invalidation will be done my Microsoft after the cert expires. There are two "databases" (simple cryptographically signed lists of certs and hashes) in UEFI, db and dbx. A signature is good if it's signing authority is found in the db, and not found in dbx. After the certs expire, MS will put their hashes into dbx. From then on, all signatures made by this cert will be rejected.

If they back up and won't stuff it in the dbx (I suspect they've got little choice), and you have a lucky mobo that ignores time at all, then you'll be good.

garlin · Sep 28, 2025

The issue isn't based on WHAT TIME IT IS. It's the fact that some VBIOS'es have signed themselves, in order to allow the UEFI to trust it.

By banning the CA 2011 cert by adding it to DBX, it invalidates anything accessible to UEFI that signed itself with CA 2011. This means your boot file readable on a disk device, or the GPU that self-signed as CA 2011. This problem exists as soon as you send CA 2011 to DBX.

Not all GPU's are vulnerable to this problem. But the alarm is from the lack of urgency in providing a similar method for self-scanning, and pestering the GPU vendors to provide some relief.

Cy_kkm · Sep 28, 2025

Almighty1 said:
which basically would invalidate #1.

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...

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 Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Active member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Similar threads