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

I gave your new scripts a shot, unfortunately I ran into the same issue where I couldn't enable secure boot and had to restore the factory keys in order to tun it back on. Thank you for trying as I Imagine it's a lot of unpaid work and time, which nevertheless is greatly appreciated. I've no doubt your latest update will help others, that in itself is quite an achievement, so kudos to you!

Dirtyflash said:

I gave your new scripts a shot, unfortunately I ran into the same issue where I couldn't enable secure boot and had to restore the factory keys in order to tun it back on. Thank you for trying as I Imagine it's a lot of unpaid work and time, which nevertheless is greatly appreciated. I've no doubt your latest update will help others, that in itself is quite an achievement, so kudos to you!

Click to expand...

This Lenovo BIOS keeps tripping up the the PK check, so the script think it's allowed to replace the PK (and fails).

From reading a few online comments, can you try this:
1. Confirm if your BIOS has a Device Guard setting. If true, temporarily disable it.

2. Quoting someone else's advice on a Gentoo forum:

To install new keys you probably have to:
1) Set "Platform mode" to "Setup Mode", this tells the firmware to accept new keys
2) Create a new Platform Key if you don't already have one, use the PK to sign the list of KEK keys (which should contain the Microsoft keys, and your own KEK). Use your own KEK to sign the DB key that you'll be signing your efi files with. (app-crypt/sbctl may be used to automate the process)
3) Install the new set of keys using, for example, app-crypt/sbctl (which has the --enroll option or something similarly named), or systemd-boot which can enroll keys it finds on the ESP automatically if the firmware is in Setup Mode (you'd have to check the manual to see what the file name of the key should be)
4) Set "Secure Boot Mode" to "Custom" and "Platform mode" to "User Mode" to instruct the firmware to use your custom set of keys instead of the built-in set of Microsoft keys (this may happen automatically after enrolling your keys).

Click to expand...

garlin said:

This Lenovo BIOS keeps tripping up the the PK check, so the script think it's allowed to replace the PK (and fails).

From reading a few online comments, can you try this:
1. Confirm if your BIOS has a Device Guard setting. If true, temporarily disable it.

2. Quoting someone else's advice on a Gentoo forum:

Click to expand...

Okay, I've turned off Device Guard in GPEdit and will use Setup Mode instead of Clear All Keys. I can sort of see what you're getting at, trying to append the new PK key while keeping the original Lenovo PK key. I'll be back shortly, I've had lots of practice..,

I finally got around to running the new scripts and at least for me I see no change. Not showing the PK info, and at the end still wants to suggest
running the -Revoke command.

ran the verbose - audit and the whatsmypk.ps1 all looks the same.


PS C:\WINDOWS\system32> powershell -nop -ep bypass -f C:\temp\check_uefi-ca2023.ps1
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) OFF

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011

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
--------------
(NONE)

EFI Files
---------
Disk 0: Windows Boot Manager [Production PCA 2011] is ALLOWED.

Registry: WindowsUEFICA2023Capable = 1
[Windows UEFI CA 2023] in UEFI DB.

Disk 0: SkuSiPolicy.p7b (for VBS) is NOT PRESENT.


REQUIRED ACTION
===============

Run the command:
Update_UEFI-CA2023.ps1 -Revoke

Finish the UEFI steps to manually add the [KEK CA 2023] cert, if the script provided instructions.

Verbose-audit
PS C:\WINDOWS\system32> powershell -nop -ep bypass -f C:\temp\check_uefi-ca2023.ps1 -verbose -audit
Windows 11 25H2 (26200.7462)

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

BIOS Firmware
-------------
HP HP Pavilion Desktop TP01-1xxx
Version: F.54
Date: 2025-08-03

Factory Default UEFI PK Cert
----------------------------
HP UEFI Secure Boot PK 2017

UEFI PK Cert
------------
HP UEFI Secure Boot PK 2017
[KEK CA 2023] Update is available from HP or Microsoft.

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
HP UEFI Secure Boot KEK 2017

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
HP UEFI Secure Boot KEK 2017

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
HP UEFI Secure Boot DB 2017

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
HP UEFI Secure Boot DB 2017
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023

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

UEFI DBX Certs
--------------
(NONE)
Windows BootMgr SVN is missing.
EFI_CERT_SHA256_GUID Signatures: 483

EFI Files
---------
Disk 0: Windows Boot Manager [Production PCA 2011] is ALLOWED.
bootmgfw.efi File version: 26100.30227

Registry: WindowsUEFICA2023Capable = 1
[Windows UEFI CA 2023] in UEFI DB.

Disk 0: SkuSiPolicy.p7b (for VBS) is NOT PRESENT.


AUDIT REPORT
============
1. Secure Boot is DISABLED
2. [Microsoft Corporation KEK 2K CA 2023] is missing from UEFI KEK
3. [Production PCA 2011] is missing from UEFI DBX
4. Windows BootMgr SVN is missing from UEFI DBX
5. Windows Boot Manager [Production PCA 2011] is wrong version
6. SkuSiPolicy.p7b (for VBS) is missing


REQUIRED ACTION
===============

Run the command:
Update_UEFI-CA2023.ps1 -Revoke

Finish the UEFI steps to manually add the [KEK CA 2023] cert, if the script provided instructions.

WhatsmyPK
PS C:\WINDOWS\system32> powershell -nop -ep bypass -f C:\temp\WhatsMyPK.ps1


Subject : O=HP Inc., C=US, OU=CODE-SIGN, CN=HP UEFI Secure Boot PK 2017
Issuer : CN=HP Inc. PK 2016 CA, O=HP Inc., C=US
Thumbprint : D52AC7DB954C167A386E1AA955249A4D9BDADEDD
FriendlyName :
NotBefore : 1/19/2017 7:00:00 PM
NotAfter : 1/16/2033 6:59:59 PM
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
System.Security.Cryptography.Oid...}

garlin said:

This Lenovo BIOS keeps tripping up the PK check, so the script think it's allowed to replace the PK (and fails).

From reading a few online comments, can you try this:
1. Confirm if your BIOS has a Device Guard setting. If true, temporarily disable it.

2. Quoting someone else's advice on a Gentoo forum:

Click to expand...

Dang Garlin, it is impressive to see how much you, (and @Ghot) put into these threads to help everyone out. You guys just keep hammering it out, day after day, to help everyone. You and Ghot need to be recognized somehow for all your expert advice and instructions. We all here are truly fortunate to have you two here to help us out. Good work and thank you much!

neldog said:

You and Ghot need to be recognized somehow

Click to expand...

Negatory good buddy. I just collect things the others (like @garlin and @XxXxX etc. ) have figured out, and put them all in one place.

garlin said:

This Lenovo BIOS keeps tripping up the the PK check, so the script think it's allowed to replace the PK (and fails).

From reading a few online comments, can you try this:
1. Confirm if your BIOS has a Device Guard setting. If true, temporarily disable it.

2. Quoting someone else's advice on a Gentoo forum:

Click to expand...

A slight difference when running the update script ( no red error ) , see below. No go sadly, thanks though. I admire your persistence.

Would it be worth trying the same thing again, but Clearing All Keys instead? It would be just like throwing a dart to see if it sticks.

Edit: I threw the dart and it didn't stick.

TheVisitor said:

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
HP UEFI Secure Boot KEK 2017

Click to expand...

This PC has the default MS KEK CA 2011, and HP added its own KEK 2017 (presumably to sign its own HP certs).
You don't have the KEK CA 2023 cert installed.

TheVisitor said:

REQUIRED ACTION
===============

Run the command:
Update_UEFI-CA2023.ps1 -Revoke

Finish the UEFI steps to manually add the [KEK CA 2023] cert, if the script provided instructions.

Click to expand...

The script is saying you have to enter the BIOS menu, search for a manual UEFI setting to add a cert from a file.

If your BIOS has this mode, then you select one of the listed disk(s), and look for an "\EFI\Certs" folder on the disk. Inside the folder, should be two KEK CA 2023 files. They're the same file, but each copy is named differently because some UEFI's will only accept a certain file extension. You can try either one.

Afterwards, restart Windows.

Ghot said:

Negatory good buddy. I just collect things the others (like @garlin and @XxXxX etc. ) have figured out, and put them all in one place.

Spoiler

All this stuff gives me brain damage too. I just use my OCD to organize it.

Click to expand...

Right and shame on me for leaving out @XxXxX! He also has done great support with all this.

I'm confused about one thing with the latest scripts, doubtless me not understanding specifically what is being reported.

Why does Windows BootMgr SVN 7.0 appear to be revoked? I'm guessing I'm just misunderstanding the report. I thought we just went through a process to get this added?

I've got a Toshiba Satellite L50-C-22L, Secure Boot has one switch and that's On or Off, i followed the prompts on the previous version scripts revoking the 2011 certs. I now have no other option than to turn off SB because i get a dialog telling me a security key is unsuitable as soon as i power on, even with the hard drive pulled out. MOSBY will not play because it wants SB turned on. I can't even find a current BIOS to reinstall as a test because it's an EOL machine although i doubt that would clear the embedded certs.

I'll be trying this new version tomorrow morning.

gunrunnerjohn said:

I'm confused about one thing with the latest scripts, doubtless me not understanding specifically what is being reported.

Why does Windows BootMgr SVN 7.0 appear to be revoked? I'm guessing I'm just misunderstanding the report. I thought we just went through a process to get this added?

View attachment 158970

Click to expand...

Unlike the other UEFI variables (PK, KEK, and DB), the DBX variable handles extra functions:

Does that sound complicated? You bet. All of those are combined into the DBX variable, and requiring a tool or script to unpack all those details.

This PC has:

SVN's are weird, in like everything the UEFI does, you don't remove a lower SVN value.

Instead you keep adding a "fake EFI hash" containing a higher SVN to the DBX variable, and the highest encoded value wins out. If you break down the DBX variable there's a 2.0, 5.0 and 7.0 value each representing the BootMgr's SVN. The SVN's can only reside in the DBX variable and it's not a standalone cert, but the idea is you see everything related to DBX together.

The SVN gets bumped to 7.0 if you have followed the MS steps to add a SVN, or run the upgrade script with the -Revoke flag.

If you had VBS enabled, the original check script might have suggested you run a revoke, because it didn't have a separate -SkuPolicy flag. And revoke was the only way (at the time) to get the SkuPolicy copied over. Now the script will suggest using -SkuPolicy without revoking. But a revoke will always include the SkuPolicy step, as it did before.

garlin said:

Unlike the other UEFI variables (PK, KEK, and DB), the DBX variable handles extra functions:

- Holds a list of banned X509 certs (like Production PCA 2011)​

- Holds a list of banned EFI files, based on signature hashes (not a complete certificate but a hash derived from the banned file's signing cert)​

- Holds a set of SVN values, encoded to resemble a banned EFI signature hash (but isn't really)​

Does that sound complicated? You bet. All of those are combined into the DBX variable, and requiring a tool or script to unpack all those details.

Click to expand...

Thanks again, I figured it was something like that, just threw me when I saw it pop up in the DBX list!

The factory-default HP BIOS sets Key Ownership to HP Keys. This means the HP platform key (PK), Microsoft key exchange key (KEK), Microsoft database (db), and a blacklist database (dbx) are populated. When Secure Boot is disabled, the keys currently enrolled in the system are preserved. If a custom PK, KEK, db, and dbx are desired, the user must change Key Ownership to Custom Keys. Once confirmed, this change will automatically disable Secure Boot and clear the PK, KEK, db, and dbx. The user may then import custom keys and re-enable Secure Boot.

Note: If the user tries to import the HP PK when Key Ownership is Custom Keys, the BIOS will reject the PK.

Click to expand...

Hello.

Thank you for your efforts @garlin.

The new version of the script already mentions the Pk, unlike the previous one, however I still have some outputs that I don't understand:

When I run Check UEFI CA 2023 EFI files it says that "Boot Manager [Windows UEFI CA 2023] is BANNED", however Windows boots from it (at least that's what it says in all the scripts to check it).

The other error is that when I try to run the update script the only message that appears is:
"Downloading "edk2-x64-secureboot-binaries.zip" from GitHub.
Incorrect authentication data: 0xC0000022".

The last error I don't understand is that when in audit mode the output says "secure boot enable" at the beginning and at the end of the report it says "secure boot disable".

Thanks again.

Ps- I will send the outputs if necessary.

garlin said:

https://h30434.www3.hp.com/t5/Desktop-Operating-Systems-and-Recovery/BIOS-UEFI-Settings/td-p/6485308

Click to expand...

That better explains why some some devices are being stubborn and don't want to play along with the upgrade script. Makes for interesting reading, thanks for posting.

cool59 said:

The new version of the script already mentions the Pk, unlike the previous one, however I still have some outputs that I don't understand:

When I run Check UEFI CA 2023 EFI files it says that "Boot Manager [Windows UEFI CA 2023] is BANNED", however Windows boots from it (at least that's what it says in all the scripts to check it).

Click to expand...

cool59 said:

The last error I don't understand is that when in audit mode the output says "secure boot enable" at the beginning and at the end of the report it says "secure boot disable".

Click to expand...

The script must check several settings in order to determine if the current boot file is allowed:

What happens if you don't have Secure Boot enabled? Then any boot file is allowed, and we really don't have to worry about CA 2011 revocation. But some users might want to update their UEFI, just in case they need Secure Boot later on.

When you use the script without -Audit, it runs the checks based on the current Secure Boot setting. With Secure Boot disabled, you can be out of compliance with CA 2023 and CA 2011 updates. That is permitted.

When you use the script with -Audit, it checks as if Secure Boot is currently enabled (ignoring if the UEFI really has it turned off). This allows the script to show you what steps are needed to be done.

There is a subtle hint for those familiar with English idioms. "Windows Boot Manager is BANNED." or "Windows Boot Manager will be BANNED."

To see if there isn't a problem, I need to see the full output of "Check_UEFI-CA2023.ps1 -verbose -audit".

cool59 said:

The other error is that when I try to run the update script the only message that appears is:
"Downloading "edk2-x64-secureboot-binaries.zip" from GitHub.
Incorrect authentication data: 0xC0000022".

Click to expand...

I'm trying to track down why the update script thinks some PC's are in Setup Mode, but they are not (which leads to 0xC0000022 errors). It means we're not allowed to change the UEFI's data.

garlin said:

The script must check several settings in order to determine if the current boot file is allowed:

- if Secure Boot is disabled, then any boot file is allowed​

- if Secure Boot is enabled, the boot file must be signed by a cert that appears in the DB and not banned in the DBX​

- if Secure Boot is enabled and the SVN has been invoked, a file hash comparison is done of the Windows reference copy of the boot file and the EFI version of the same file​

What happens if you don't have Secure Boot enabled? Then any boot file is allowed, and we really don't have to worry about CA 2011 revocation. But some users might want to update their UEFI, just in case they need Secure Boot later on.

When you use the script without -Audit, it runs the checks based on the current Secure Boot setting. With Secure Boot disabled, you can be out of compliance with CA 2023 and CA 2011 updates. That is permitted.

When you use the script with -Audit, it checks as if Secure Boot is currently enabled (ignoring if the UEFI really has it turned off). This allows the script to show you what steps are needed to be done.

There is a subtle hint for those familiar with English idioms. "Windows Boot Manager is BANNED." or "Windows Boot Manager will be BANNED."

- "is BANNED" means the current settings do not allow this file.​

- "will be BANNED" means if you enabled Secure Boot, then the system will not boot. -Audit is explaining the future danger of turning on Secure Boot without updating the UEFI or boot files.​

To see if there isn't a problem, I need to see the full output of "Check_UEFI-CA2023.ps1 -verbose -audit".


I'm trying to track down why the update script thinks some PC's are in Setup Mode, but they are not (which leads to 0xC0000022 errors). It means we're not allowed to change the UEFI's data.

Click to expand...

Thanks again @garlin

Here the "Check UEFI-CA.ps1 -Verbose:

Windows 11 25H2 (26200.7462)

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

BIOS Firmware
-------------
Dell Inc. XPS 13 9360
Version: 2.21.0
Date: 2022-06-02

Factory Default UEFI PK Cert
----------------------------
Dell Inc. Platform Key

UEFI PK Cert
------------
Dell Inc. UEFI Platform Key
Manual update of [KEK CA 2023] is REQUIRED.

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Dell Inc. Key Exchange Key

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Dell Inc. UEFI DB

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

Factory Default UEFI DBX Certs
------------------------------
Microsoft Windows PCA 2010
EFI_CERT_SHA256_GUID Signatures: 77

UEFI DBX Certs
--------------
Microsoft Windows PCA 2010
Windows BootMgr SVN 7.0
EFI_CERT_SHA256_GUID Signatures: 486

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is BANNED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b (for VBS) is NOT PRESENT.


REQUIRED ACTION
===============

Run the command:
Update_UEFI-CA2023.ps1 -Revoke

Finish the UEFI steps to manually add the [KEK CA 2023] cert, if the script provided instructions.

PS C:\WINDOWS\system32>

And Audit:

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

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011

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 PCA 2010
Windows BootMgr SVN 7.0

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is BANNED.

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

Disk 0: SkuSiPolicy.p7b (for VBS) is NOT PRESENT.


AUDIT REPORT
============
1. Secure Boot is DISABLED
2. [Microsoft Corporation KEK 2K CA 2023] is missing from UEFI KEK
3. [Production PCA 2011] is missing from UEFI DBX
4. SkuSiPolicy.p7b (for VBS) is missing


REQUIRED ACTION
===============

Run the command:
Update_UEFI-CA2023.ps1 -Revoke

Finish the UEFI steps to manually add the [KEK CA 2023] cert, if the script provided instructions.

PS C:\WINDOWS\system32>


Thanks again for patience

@cool59, can you run this command from PowerShell?

It should return an error, with no variable found. If it does report $true, let me know.

garlin said:

@cool59, can you run this command from PowerShell?

Code:

get-variable SetupMode

It should return an error, with no variable found. If it does report $true, let me know.

Click to expand...

Yes...give me this error:

PS C:\WINDOWS\system32> get-variable SetupMode
get-variable : Cannot find a variable with the name 'SetupMode'.
At line:1 char:1
+ get-variable SetupMode
+ ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (SetupMode:String) [Get-Variable], ItemNotFoundException
+ FullyQualifiedErrorId : VariableNotFound,Microsoft.PowerShell.Commands.GetVariableCommand






PS C:\WINDOWS\system32>