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

Klaver7 · Mar 17, 2026

JamesSmith said:
Should I be worried? I kind of understand what you are saying. Not sure if I can do anything?
Please advise.

@Klaver7 try this in PS

foreach ($var in @('PK','KEK','DB','DBX')) { "`n${var}:"; (Get-SecureBootUEFI -Name $var -Decoded).Subject }

What do you get?

PS C:\WINDOWS\system32> foreach ($var in @('PK','KEK','DB','DBX')) { "`n${var}:"; (Get-SecureBootUEFI -Name $var -Decoded).Subject }

PK:
CN=GIGABYTE

KEK:
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=GIGABYTE

DB:
CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=GIGABYTE
CN=GIGABYTE
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US

DBX:
CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
PS C:\WINDOWS\system32>

Hope this helps,

garlin · Mar 17, 2026

JamesSmith said:
Should I be worried? I kind of understand what you are saying. Not sure if I can do anything?
Please advise.

You have a working system, so don't stress about it. We only need to be concerned about validating the MS-provided certs, and not about other private keys the OEM provides.

Nebulon Ranger · Mar 17, 2026

Chances are anyway, since Gigabyte also make laptops, the duplicate DB certificates are the equivalent of the ASUS Motherboard and Notebook ones--meaning they just include both so they don't have to ship two different versions of the same UEFI. These mainboard OEMs tend to base their mobile boards on near-equivalent desktop hardware, simply because it's more efficient to do so.

SaliesBuzz · Mar 17, 2026

garlin said:
It's not officially released (because I have to do testing). Here's a work-in-progress version.

Ran the script on the old DELL and still got::

Dell Inc. Inspiron 5721
Version: A16
Date: 2018-05-24
La variable est actuellement non définie : 0xC0000100
(The variable is currently undefined)

The BIOS is now in "Custom" mode, (there appears to be no "Setup" mode in the DELL system BIOS

garlin · Mar 17, 2026

Look for "Reset All Keys"
DELL - How To Update Secure Boot Active Database from BIOS

SaliesBuzz · Mar 17, 2026

garlin said:
Look for "Reset All Keys"
DELL - How To Update Secure Boot Active Database from BIOS

There is no "Reset All Keys" just "Factory Defaults". The same thing?

garlin · Mar 17, 2026

Read the Dell link, it lists the 5 different BIOS types. Find the one that matches this PC, and follow the instructions.

SaliesBuzz · Mar 17, 2026

garlin said:
Read the Dell link, it lists the 5 different BIOS types. Find the one that matches this PC, and follow the instructions.

Read all of those, not one lists "Reset All Keys" just Factory Default. The setup screen is also different as it is InsydeH20 Setup Utility. Will try again later today my time, it is early morning here! Thanks anyway

Klaver7 · Mar 18, 2026

JamesSmith said:
I got this exact same output on my Lenovo laptop.

I got my FirmwareSVN to 7.0, let me explain, the [Update_UEFI-CA2023.ps1] would not work for me as it threw me an error about bitlocker and I was left with input for certain blah[0] stuf! .... blink blink like what do I fill in ? (I dont use bitlocker) So I used the [Check_UEFI-CA2023.ps1] scripts to UPDATE my 2023 certificate's, with set-regs and powershell task etc. I lost track of how many times I done that and reset the BOOT keys to default in the BIOS as [FirmareSVN to 2.0] kept popping up! So I took out the [bitlocker parts] from the [Update_UEFI-CA2023.ps1], rebooted, cleared my BIOS to default keys again and after booting running the modified [Update_UEFI-CA2023.ps1] -Revoke .. the result will show you below:
====
PS C:\WINDOWS\system32> powershell -nop -ep bypass -f C:\Temp\Update_UEFI-CA2023.ps1 -Revoke
Successfully appended "DBUpdate3P2023.bin" to UEFI DB.
Successfully appended "DBUpdateOROM2023.bin" to UEFI DB.
Successfully appended "dbxupdate.bin" to UEFI DBX.
Successfully appended "DBXUpdate2024.bin" to UEFI DBX.
Successfully appended "DBXUpdateSVN.bin" (SVN 7.0) to UEFI DBX.

REQUIRED ACTION
---------------
Restart Windows, for UEFI updates to take effect.
==================================================================================
PS C:\WINDOWS\system32> Get-SecureBootSVN

FirmwareSVN : 7.0
BootManagerSVN : 7.0
StagedSVN : 7.0
ComplianceStatus : Compliant (Boot Manager SVN meets staged SVN)
BootManagerPath : \\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi

==================================================================================
Windows 11 24H2 (26100.8037)

Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) OFF

BIOS Firmware
-------------
Gigabyte Technology Co. B650 AORUS ELITE AX V2
Version: F40
Date: 2026-02-06

Factory Default UEFI PK Cert
----------------------------
GIGABYTE

UEFI PK Cert
------------
GIGABYTE

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
GIGABYTE

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
GIGABYTE

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Windows UEFI CA 2023
GIGABYTE
GIGABYTE

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023
GIGABYTE
GIGABYTE

Factory Default UEFI DBX Certs
------------------------------
(NONE)
EFI_CERT_SHA256_GUID Signatures: 77

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0
EFI_CERT_SHA256_GUID Signatures: 487

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 26100.30227, SVN 7.0

Registry: WindowsUEFICA2023Capable = 2
[Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

SkuSiPolicy.p7b is CURRENT.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Version: 33284.17421.33440.335

STATUS REPORT
-------------
Registry: UEFICA2023Status = Updated

SUCCESS: NO UPDATES ARE REQUIRED.

I hope this will help someone out as it had me puzzled for day's, now I can sleep better

JamesSmith · Mar 18, 2026

Garlin said a few things about the SVN's not matching

Mine says

I believe Garlin advised this was a bug.

garlin said:
My current thinking is it's a bug within the PowerShell function.

If you've followed the expected steps, there are least two different BootMgr SVN numbers, 2.0 & 7.0. In theory, the highest of the available number is enforced. But PS can return inconsistent results for different people. For now, I would place more faith on the way my script determines the SVN because that's how the SVN mechanism is designed to work.

I have no idea anymore.

garlin · Mar 18, 2026

Let's settle this argument, by listing all of the SVN's in the order they appear in the DBX:

Code:

PS C:\Users\GARLIN\Downloads> .\SVN_Order.ps1
BootMgr SVN 2.0
CDMgr SVN 2.0
WDS SVN 2.0
BootMgr SVN 7.0
CDMgr SVN 3.0
WDS SVN 3.0


FirmwareSVN : 7.0

JamesSmith · Mar 18, 2026

garlin said:
Let's settle this argument, by listing all of the SVN's in the order they appear in the DBX:

Code:

PS C:\Users\GARLIN\Downloads> .\SVN_Order.ps1 BootMgr SVN 2.0 CDMgr SVN 2.0 WDS SVN 2.0 BootMgr SVN 7.0 CDMgr SVN 3.0 WDS SVN 3.0 FirmwareSVN : 7.0

On my Lenovo Laptop

PS C:\> powershell -nop -ep bypass -f .\SVN_Order.ps1
BootMgr SVN 7.0
CDMgr SVN 3.0
WDS SVN 3.0
BootMgr SVN 2.0
CDMgr SVN 2.0
WDS SVN 2.0

FirmwareSVN : 2.0

PS C:\>

garlin · Mar 18, 2026

See? PowerShell is wrong, it's picking the last SVN instead of the highest available SVN.

This confirms my original argument. If you apply the DBX updates in the intended order, it would add SVN 2.0 first from DBXUpdate2024.bin (where PCA 2011 gets added to DBX), and then SVN 7.0 would be added from DBXUpdateSVN.bin.

But if you manually mess around with AvailableUpdates, it's possible to apply both files in reverse order. Now the boot manager file which reads the SVN from DBX should be looking for the highest SVN. Otherwise that is a really terrible security bug to base the accepted SVN on the last one found, which I cannot believe MS would make.

If that were the case, then I can defeat SVN 7.0 by pushing a DBX update file which adds a SVN 1.0 as last in the DBX list.

Therefore the obvious answer is PS is really stupid. Because the PS team is not the same devs who wrote the boot manager.

JamesSmith · Mar 18, 2026

garlin said:
See? PowerShell is wrong, it's picking the last SVN instead of the highest available SVN.

This confirms my original argument. If you apply the DBX updates in the intended order, it would add SVN 2.0 first from DBXUpdate2024.bin (where PCA 2011 gets added to DBX), and then SVN 7.0 would be added from DBXUpdateSVN.bin.

But if you manually mess around with AvailableUpdates, it's possible to apply both files in reverse order. Now the boot manager file which reads the SVN from DBX should be looking for the highest SVN. Otherwise that is a really terrible security bug to base the accepted SVN on the last one found, which I cannot believe MS would make.

If that were the case, then I can defeat SVN 7.0 by pushing a DBX update file which adds a SVN 1.0 as last in the DBX list.

Therefore the obvious answer is PS is really stupid. Because the PS team is not the same devs who wrote the boot manager code.

Seeing as I updated in the wrong order do I need to fix anything?

Or am I good

Thanks Garlin

garlin · Mar 18, 2026

As I've repeated, PS is plainly broken. What really matters is the boot manager's behavior.

If you're paranoid, the only way to "fix" this in order to satisfy PS (which I don't believe is the correct approach) is to clear the UEFI keys and start over with the update process. In theory, you could enter the UEFI setup menu and under DBX key management clear the individual keys. But they're all labeled as cryptic hex strings and that's not practical.

I suppose if this Dell has manual key management, you can delete all the DBX keys one at a time, for 400+ times in a row until they're all gone.

Then re-run the update script in revoke mode, which will apply the DBX update files in the expected order.

To me, it's not necessary. I strongly believe a large number of under-informed folks have not followed the MS manual instructions and already ended up in the same situation as you (mis-ordered SVN's). Their Windows system didn't stop working.

t2s50 · Mar 18, 2026

garlin said:
....
If you're paranoid, the only way to "fix" this in order to satisfy PS (which I don't believe is the correct approach) is to clear the UEFI keys and start over with the update process. In theory, you could enter the UEFI setup menu and under DBX key management clear the individual keys. But they're all labeled as cryptic hex strings and that's not practical.

I suppose if this Dell has manual key management, you can delete all the DBX keys one at a time, for 400+ times in a row until they're all gone.
......

I think it's Lenovo, not Dell? They got a "bios simulator". If it's the model given by JamesSmith as 'System two' this would be the link:

Lenovo BIOS Simulator Center

I can't find any option to remove single dbx key entries, just to reset the keys.

Klaver7 · Mar 18, 2026

JamesSmith said:
On my Lenovo Laptop

PS C:\> powershell -nop -ep bypass -f .\SVN_Order.ps1
BootMgr SVN 7.0
CDMgr SVN 3.0
WDS SVN 3.0
BootMgr SVN 2.0
CDMgr SVN 2.0
WDS SVN 2.0

FirmwareSVN : 2.0

PS C:\>

Here is my outcome JamesSmith:

PS C:\WINDOWS\system32> powershell -nop -ep bypass -f C:\Temp\SVN_Order.ps1
BootMgr SVN 2.0
CDMgr SVN 2.0
WDS SVN 2.0
BootMgr SVN 7.0
CDMgr SVN 3.0
WDS SVN 3.0

FirmwareSVN : 7.0

As Garlin explained it takes the last entry, so nothing to worry about!
Big thanx again garlin for all the help and support you give us :clap:

Sequence · Mar 18, 2026

- deleted - because:

EDIT: I am stupid, i am using a different script. Sorry. This topic is messing with my brain.

JamesSmith · Mar 18, 2026

garlin said:
As I've repeated, PS is plainly broken. What really matters is the boot manager's behavior.

If you're paranoid, the only way to "fix" this in order to satisfy PS (which I don't believe is the correct approach) is to clear the UEFI keys and start over with the update process. In theory, you could enter the UEFI setup menu and under DBX key management clear the individual keys. But they're all labeled as cryptic hex strings and that's not practical.

I suppose if this Dell has manual key management, you can delete all the DBX keys one at a time, for 400+ times in a row until they're all gone.

Then re-run the update script in revoke mode, which will apply the DBX update files in the expected order.

To me, it's not necessary. I strongly believe a large number of under-informed folks have not followed the MS manual instructions and already ended up in the same situation as you (mis-ordered SVN's). Their Windows system didn't stop working.

I don't have the technical knowledge to clear the dbx keys on the Gigabyte Bios and I don't think it's possible on the Lenovo.
When I looked into the BIOS the keys were all labelled with weird hashes and strings.

If I ran Update_UEFI-CA2023.ps1 -Revoke would it change anything?

At this point all the secure boot scripts I have used come back 100% fine. The only issue I have had is with this PowerShell one.

There is nothing I can do but wait until June.

Thanks for the help again.

LeeElectrode · Mar 18, 2026

hvoqasimo said:
outcome runing Check_UEFI-CA2023.ps1 script:
powershell -nop -ep bypass -f "C:\temp\SecureBoot-CA-2023-Updates\Check_UEFI-CA2023.ps1”
Secure Boot: ON
Virtualization Based Security: OFF
BitLocker on (C:) OFF

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0

EFI Files
---------
Disk 1: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

Registry: WindowsUEFICA2023Capable = 2
[Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

STATUS REPORT
-------------
Registry: UEFICA2023Status = Updated

SUCCESS: NO UPDATES ARE REQUIRED.

PS C:\Users\asimo>

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

Member

My Computer

Well-known member

My Computer

Member

My Computer

Member

My Computer

Well-known member

My Computer

Member

My Computer

Well-known member

My Computer

Member

My Computer

Member

My Computer

Well-known member

My Computers

Well-known member

Attachments

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Member

My Computer

Member

My Computer

New member

My Computer

Well-known member

My Computers

Member

hvoqasimo... How did you get to this point from your previous post?​

My Computer

hvoqasimo... How did you get to this point from your previous post?