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

gunrunnerjohn · 2026-10-21T10:09:35-0400

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?

itsme1 · 2026-10-21T11:22:23-0400

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

Thierry 83200 · 2026-10-21T11:27:12-0400

like this

itsme1 · 2026-10-21T11:29:51-0400

garlin · 2026-10-21T11:40:12-0400

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.

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.

garlin · 2026-10-21T11:42:00-0400

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.

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?

garlin · 2026-10-21T11:51:03-0400

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.

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.

gunrunnerjohn · 2026-10-21T13:56:58-0400

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.

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.

garlin · 2026-10-21T14:02:39-0400

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

gunrunnerjohn · 2026-10-21T20:02:45-0400

garlin said:
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).

I had thought that when I revoked the 2011 Cert several months ago that would be the end for it. I still don't quite understand why that arises from the dead again.

garlin · 2026-10-21T20:18:29-0400

MS will add more EFI entries to dbxupdate.bin over time, which is a list of banned EFI boot files for Windows, Linux or whatever EFI-level tools are flagged as insecure (known security hole). The pace of new Windows or Linux boot file entries has dramatically slowed down by the introduction of SVN (for Windows) and SBAT (for Linux). But it's entirely possible that other banned files which don't fall into either category are added.

The net change is 15 EFI entries got added to the list since you initially performed the revocation (months ago). But also the overall file shrank by 154 entries when MS cleaned up the dbxupdate.bin file. Which is why you're missing DBX entries, but at the same time the file has less total entries than when you performed the revocation.

anchamp65 · 2026-10-21T21:42:07-0400

garlin said:
MS will add more EFI entries to dbxupdate.bin over time, which is a list of banned EFI boot files for Windows, Linux or whatever EFI-level tools are flagged as insecure (known security hole). The pace of new Windows or Linux boot file entries has dramatically slowed down by the introduction of SVN (for Windows) and SBAT (for Linux). But it's entirely possible that other banned files which don't fall into either category are added.

The net change is 15 EFI entries got added to the list since you initially performed the revocation (months ago). But also the overall file shrank by 154 entries when MS cleaned up the dbxupdate.bin file. Which is why you're missing DBX entries, but at the same time the file has less total entries than when you performed the revocation.

@garlin
We can use your script force update of DBX / revocations.
Windows secure boot scheduled task should also take of it over time but it might take longer and a few reboots.
If we don't want to wait, that's when we can use your update with -revoke again to force immediate update.
Correct ?

garlin · 2026-10-21T22:10:44-0400

The update script can perform all of the following tasks:

(by default)	- Add OEM's signed KEK CA 2023 cert if it's been submitted to MS - Add CA 2023 DB certs if a KEK CA 2023 is already installed - Add the Windows OEM Devices keys if UEFI is in Setup mode - Update the boot manager (when needed) on the EFI volume - Update the SkuSiPolicy file if one already exists on the EFI volume
-SkuSiPolicy	- Install the SkuSiPolicy file if none exists on the EFI volume
-Revoke	- Revoke the PCA 2011 cert - Add the latest SVN to DBX - Add any missing EFI signatures from dbxupdate.bin
-RevokeNoDBX	- Revoke the PCA 2011 cert without adding any EFI signatures - Add the latest SVN to DBX
-Latest	- Download the latest dbxupdate.bin & DBXUpdateSVN.bin from the MS GitHub repo, and apply them
-BootMedia	- Update the boot manager file on USB media (but not update the boot or install WIM's)

What it cannot do by itself:
- Add the SBAT variable because it's a privileged secure operation (script must call the Secure Boot task for this step)

Right now, unless you update AvailableUpdates to specific hex values, the Secure Boot task will only perform the same steps as the update script's default steps. Any step that can block Windows or a boot USB from booting can be considered a "revocation" action. Because it revokes something that would have worked before you made any changes.

Adding the CA 2023 certs or installing a boot manager with a higher SVN than the DBX (if it exists) is not considered a revoke action, because these changes don't prevent an older version of the boot file from working. Windows will not (at this time), do anything which will deliberately lock you out of booting. You must request the Secure Boot task to execute a revocation action thru defined AvailableUpdates values.

It's not clear if MS will move ahead and make revocation mandatory. That was the original indication, but no further guidance has appeared on what happens next. If MS doesn't make a policy change now, it could wait until 27H2 since it's a different OS. Different OS = different rules.

fg2001gf11F · 2026-10-21T22:15:46-0400

garlin said:
MS will add more EFI entries to dbxupdate.bin over time, which is a list of banned EFI boot files for Windows, Linux or whatever EFI-level tools are flagged as insecure (known security hole). The pace of new Windows or Linux boot file entries has dramatically slowed down by the introduction of SVN (for Windows) and SBAT (for Linux). But it's entirely possible that other banned files which don't fall into either category are added.

The net change is 15 EFI entries got added to the list since you initially performed the revocation (months ago). But also the overall file shrank by 154 entries when MS cleaned up the dbxupdate.bin file. Which is why you're missing DBX entries, but at the same time the file has less total entries than when you performed the revocation.

@garlin,
I just went through a weird situation on a multiboot machine when I tried to test the SkuSiPolicy.p7b 3.0.0.19.
After testing that, I deleted it from EFI\microsoft\boot to allow the multiboot to work, then I found out that the Dell XPS 8940 firmware copied that policy in the firmware and it was still enforcing it and blocking some of my installation USB media that are in the blocked ranges.
The problem is that there is no easy way to remove the copy of of the policy from the firmware, the only way on that machine is by resetting the BIOS to the factory settings. At that point I could not boot any of my systems because they all have the CA 2023 updates and I could not manually add the
Microsoft Corporation KEK 2K CA 2023 to the BIOS. It has to be done by Windows, but only when Secure boot is enabled.
To make the story short, I had to do a clean install of 26300.9711 with Secure boot enabled and then let Windows do the updates for CA 2023.
When that was finally done, I could restore the backup of my original system and now everything is back to normal.
It is a weird behavior of the Dell XPS 8940, and perhaps also other models.

It sure took a long time to figure that out and then find a way to get the machine back to the same working condition that it was before this experiment.
I'm sure glad that it is now done and everything is back to normal.

After all this, I decided not to revoke the CA 2011 on this machine, given that the official Microsoft installation media still uses that CA 2011.

garlin · 2026-10-21T22:41:37-0400

The normal way to clear the SkuSiPolicy enforcement:

1. Disable Secure Boot.

2. Boot Windows. Mount the EFI volume and delete SkuSiPolicy:

Code:

mountvol S: /s
del S:\EFI\Microsoft\Boot\SkuSiPolicy.p7b

3. Shutdown Windows.

4. Enable Secure Boot.

If you skip the steps, Windows thinks an attacker is trying to bypass security. When Windows boots, it checks if Secure Boot is enabled or not. If it's disabled, it will clear the hidden UEFI secure variable setting which locks in SkuSiPolicy enforcement for the next reboot.

fg2001gf11F · 2026-10-21T22:50:44-0400

garlin said:
The normal way to clear the SkuSiPolicy enforcement:

1. Disable Secure Boot.

2. Boot Windows. Mount the EFI volume and delete SkuSiPolicy:

Code:

mountvol S: /s del S:\EFI\Microsoft\Boot\SkuSiPolicy.p7b

3. Shutdown Windows.

4. Enable Secure Boot.

If you skip the steps, Windows thinks an attacker is trying to bypass security. When Windows boots, it checks if Secure Boot is enabled or not. If it's disabled, it will clear the hidden UEFI secure variable setting which locks in SkuSiPolicy enforcement for the next reboot.

I did that, but this is a different case; a copy of the policy gets saved in the firmware of the DELL XPS 8940.

hader · 2026-10-22T06:49:26-0400

fg2001gf11F said:
I did that, but this is a different case; a copy of the policy gets saved in the firmware of the DELL XPS 8940.

It is not inside the firmware or BIOS but in the same NVRAM area where the description region, Intel ME/AMD PSP region, BIOS and the variable store (Stores e.g. the PK Keys.) It's a pity that DELL uses his own layout because I have seen so much dealing with correction on the part of Microsoft updates and DELL machines. Also HP have some issues but DELL sticks out. These are things where a DELL customer not looking forward to it. Not a judgement but just an observation.

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

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Active member

Attachments

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Similar threads

My Computers

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computers

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computer

My Computers