Solved garlin's PowerShell scripts for updating Secure Boot CA 2023

I ran the Check-UEFI check and it shows my 2011 Cert as still active even though I revoked it months ago.
So I ran the Check-DBX check and I get this.



If they're removed after Oct, why is this an error?

The first line, currently in red, should be in green with 291/291 signatures. That is what I have.

like this

Yes

winston81 said:

I am working on updating the certs on my notebook (see signature) for quite a while now and it is a PITA. Before going into details too much and probably wasting your time, my simple question is: is it possible to update the 2023 KEK manually because stupid manufacturer did not provide a signed PK / KEK to MS to deploy?

Crippled UEFI (Aptio) does not allow any kind of key management and so i am either stuck on default secure boot keys (with 2011 KEK) or stuck in secure boot setup mode with 2023 certs (after update script) but with no chance to switch to any working secure boot mode (user / custom etc) without getting "secure boot violation" at boot up.

Click to expand...

There's four methods of adding Secure Boot certs (ranked in order of least to most obtrusive):

1. BIOS update with CA 2023 certs in factory defaults (best option)
2. OEM submits a signed KEK CA 2023 to MS, and the Secure Boot update task can install it.
3. Manual key enrollment of KEK CA 2023 from the UEFI setup menu.
4. Deleting all keys, and installing a replacement set.

For the first two methods, your PC OEM or their BIOS provider needs to help out. If you don't have the option for Manual key enrollment, you need to check if your UEFI supports a Custom mode. Sometimes the Custom mode is enabled only if you Delete All Keys or you set a BIOS admin password.

When you delete all keys, the Platform Key is cleared and this allows a new set of certs to be installed. Assuming this works, run the update script and it will detect this mode. The script will download and install the Windows OEM Devices keys as a replacement set. This is a last resort, assuming the first three methods are not available to you.

Some BIOS implementations are more bare-bones than others.

fg2001gf11F said:

So far, all the Builds that are not in the blocked ranges, booted just fine.
The last one I tried on purpose is in the blocked range. and it just turns off the PC if I try booting from it.
No problem booting the same media on another machine that has not that SKuSiPolicy.p7b.

Edit:
I think it is interesting that with the ranges that are blocked they force a PC power off without giving any error message.

Click to expand...

That's kinda weird. Windows is supposed to display the digital signature is invalid for winload.efi. If you can't read the message, how would you know what the problem is?

gunrunnerjohn said:

I ran the Check-UEFI check and it shows my 2011 Cert as still active even though I revoked it months ago.
So I ran the Check-DBX check and I get this.

Click to expand...

1. dbxupdate.bin has 15 missing EFI signatures your DBX variable doesn't currently have. You should run "Update-UEFI.bat -Revoke" to add the missing signatures.

2. DBXUpdate2024.bin used to have a "starter set" of 3 SVN's bundled along with the PCA 2011 cert. In the Oct 2026 CU, MS removed these obsolete SVN's so they're no longer included in this file. For users who have not updated to Oct 2026, or running on an End-of-Life Windows which stopped updating before this month, this file will be the older version which still has the SVN's.

3. DBXupdateSVN.bin contains the latest SVN's, which is why DBXUpdate2024.bin no longer needs to include an older set of them. The cleanup of DBXUpdate2024.bin is for administrative reasons, it doesn't affect any Secure Boot functionality.

garlin said:

1. dbxupdate.bin has 15 missing EFI signatures your DBX variable doesn't currently have. You should run "Update-UEFI.bat -Revoke" to add the missing signatures.

2. DBXUpdate2024.bin used to have a "starter set" of 3 SVN's bundled along with the PCA 2011 cert. In the Oct 2026 CU, MS removed these obsolete SVN's so they're no longer included in this file. For users who have not updated to Oct 2026, or running on an End-of-Life Windows which stopped updating before this month, this file will be the older version which still has the SVN's.

3. DBXupdateSVN.bin contains the latest SVN's, which is why DBXUpdate2024.bin no longer needs to include an older set of them. The cleanup of DBXUpdate2024.bin is for administrative reasons, it doesn't affect any Secure Boot functionality.

Click to expand...

Hmm... I did the October updates, but the update batch fixed it anyway. I was surprised that was complaining, I thought that was behind me.
Thanks.

The Secure Boot task doesn't automatically perform revocation tasks (which includes adding new DBX entries). You have to force it using an AvailableUpdates reg value, or running something like the update script.

I believe MS is still paranoid about forced revocations because non-technical users aren't aware of what changes that will bring (possibly banning your bootable ISO or USB drive).