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

Ed Tittel said:

I wrote a blog post today that includes a PS script to repair a freshly-built Macrium Reflect X Rescue Media UFD to workable condition. Check it out at: Fixing Macrium Rescue Disk - Ed Tittel.
Hope some readers find this helpful,
--Ed--

Click to expand...

Why am I getting this:
PS C:\SecureBoot USB Boot drive fix Macrium> .\fixmrrd.ps1 -TargetDrive I:
At C:\SecureBoot USB Boot drive fix Macrium\fixmrrd.ps1:174 char:58
+ if (-not (Test-Path (Split-Path $destExternal))) {
+ ~
Missing closing '}' in statement block or type definition.
At C:\SecureBoot USB Boot drive fix Macrium\fixmrrd.ps1:171 char:33
+ if (-not $SkipExternalBoot) {
+ ~
Missing closing '}' in statement block or type definition.
At C:\SecureBoot USB Boot drive fix Macrium\fixmrrd.ps1:73 char:5
+ try {
+ ~
Missing closing '}' in statement block or type definition.
At C:\SecureBoot USB Boot drive fix Macrium\fixmrrd.ps1:175 char:71
+ ... Write-Fail "EFI boot directory not found on $TargetDrive."
+ ~
The Try statement is missing its Catch or Finally block.
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : MissingEndCurlyBrace

PS C:\SecureBoot USB Boot drive fix Macrium>

That's easy. The second half of the script is missing from Ed's OneDrive link.

garlin said:

That's easy. The second half of the script is missing from Ed's OneDrive link.

Click to expand...

...and does Ed know?

garlin said:

If the update script cannot find a matching KEK bin for your PC, it will recommend you first try manual KEK enrollment.

That's wheere you enter Custom Mode, and see if you're allowed to add a KEK cert from a file. Depending on your BIOS, this may not be supported. If it works, add the KEK cert and run the update script again. If you're not allowed to add a KEK file, then use the Clear All Keys option, and run the update script.


Run the update script first without -Revoke to see if it's successful. Presuming everything work, then run the -Revoke.


26H2 is the same as 24H2 & 25H2 in terms of Secure Boot. The certs are the same for all Windows releases.

Click to expand...

Hello Garlin, I had to delete all keys, ran script, looked good, ran script with -Revoke, here's the outcome:

PS C:\User\Bob\GarlinUEFI2023> .\check_uefi-ca2023.ps1 -audit -verbose
Windows 11 25H2 (26200.9550)
Secure Boot: OFF (Audit Report runs as ON)
Virtualization Based Security: OFF (Audit Report runs as ON)
BitLocker on (C:) OFF

BIOS Firmware
-------------
Sony Corporation SVE15128CXS
Version: R0200D5
Date: 2016-09-25

Factory Default UEFI PK Cert
----------------------------
(NONE)

UEFI PK Cert
------------
Windows OEM Devices PK

Factory Default UEFI KEK Certs
------------------------------
(NONE)

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

Factory Default UEFI DB Certs
-----------------------------
(NONE)

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
------------------------------
(NONE)
EFI_CERT_SHA256_GUID Signatures: 0

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 11.0
EFI_CERT_SHA256_GUID Signatures: 5

UEFI Variables
--------------
SBAT (Linux only): sbat,1,2025051000 / shim,4 / grub,5 / grub.debian,4 / grub.peimage,2 / grub.proxmox,2

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] will be ALLOWED.
\\.\HarddiskVolume3\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.367, SVN 11.0

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

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.

AUDIT REPORT
============
1. Secure Boot is DISABLED
2. DBX Updates are missing from UEFI DBX

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is missing from EFI

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


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

To update DBXUpdate signatures, run the commands:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x2 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

I have'nt done the above "required actions". Should I?
================================
FAILED: Missing 291/291 SVN signatures from "dbxupdate.bin"
SUCCESS: Matched 3/3 SVN signatures from "DBXUpdate2024.bin"
SUCCESS: Matched 3/3 SVN signatures from "DBXUpdateSVN.bin"
===========================================
anything I should do?
I have'nt applied: schtasks /change /disable /tn "\Microsoft\Windows\PI\Secure-Boot-Update, should I?

Thank you so much for you guidance!

Sony Vaio sve said:

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 11.0
EFI_CERT_SHA256_GUID Signatures: 5

Click to expand...

DBX -> PCA 2011 is banned + 5 SVN's
So you're in no danger of overflowing the DBX.

Sony Vaio sve said:

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

To update DBXUpdate signatures, run the commands:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x2 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Click to expand...

You should ignore this advice, since the check script has no idea you DON'T WANT THIS.
It's providing instructions for the 95% of other users who can update the DBX without any concerns.

Hi, i found this forum when looking for a solution regarding the 2023 certificate.

I have an old computer enrolled with esu but the event viewer keep giving error everytime the computer startup,
there are error 1797: The Secure Boot update failed as the Windows UEFI CA 2023 certificate is not present in Db
and error 1802: The Secure Boot update KEK 2023 was blocked due to a known firmware issue on the device.

I ran the script for checking and the below is the result, the computer is already eol so it will not get any new bios update, does this mean i shouldn't proceed and can only ignore the event viewer?

Thanks in advance.

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

BIOS Firmware
-------------
Hewlett-Packard HP Pro 3330 MT
Version: 8.06
Date: 2013-01-24
This BIOS may be corrupted by updating Secure Boot certs.

UEFI PK Cert
------------
(NONE)
Platform Key is UNTRUSTED.

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

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011

UEFI DBX Certs
--------------
(NONE)

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

Registry: "WindowsUEFICA2023Capable" = 0
[Windows UEFI CA 2023] not in UEFI DB.

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.

STATUS REPORT
-------------
Registry: "UEFICA2023Status" = InProgress
Registry: "ConfidenceLevel" = Temporarily Paused

This device is affected by a known issue. This may require a firmware update.

Panna said:

I have an old computer enrolled with esu but the event viewer keep giving error everytime the computer startup,
there are error 1797: The Secure Boot update failed as the Windows UEFI CA 2023 certificate is not present in Db
and error 1802: The Secure Boot update KEK 2023 was blocked due to a known firmware issue on the device.

I ran the script for checking and the below is the result, the computer is already eol so it will not get any new bios update, does this mean i shouldn't proceed and can only ignore the event viewer?

Thanks in advance.

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

BIOS Firmware
-------------
Hewlett-Packard HP Pro 3330 MT
Version: 8.06
Date: 2013-01-24
This BIOS may be corrupted by updating Secure Boot certs.

Click to expand...

There is a possibility that some older PC's can get "bricked" when trying to the update certs, due to HW or firmware limitation on how much space is allocated to Secure Boot variables.

For about a year, MS has been collecting telemetry data from different PC's and organizing them into "buckets" based on motherboard model and BIOS revision. Based on this data and working with the OEM's, it has marked some buckets as ineligible for updates because of known issues. MS won't provide a specific reason why, other than updates should not go forward on tagged models.

Your BIOS is dated from 2013, and no longer supported. It might be possible to perform a manual enrollment, but it's not clear if revoking the PCA 2011 cert will lead to UEFI errors or not. You can obviously try, but since no one else has reported whether it worked on this model, it's a big unknown.

UPDATE: 2026-10-08

1. Add option for Update_UEFI-CA2023.ps1 to block dbxupdate.bin updates
2. Update_UEFI-CA2023.ps1 needs to update SecureBoot reg keys when "Secure-Boot-Update" task is disabled or removed

Update_UEFI-CA2023.ps1 now has the -RevokeNoDBX option, which can be used in the place of -Revoke. Both options are mutually exclusive; you can only pick between one of the two. -RevokeNoDBX will ban the CA 2011 cert and update the SVN, without adding the hundreds of potentially new EFI signatures to the DBX.

Some users with older BIOS'es have a known (or suspected) HW or firmware limitation where overflowing the DBX with too much data can "brick" the UEFI. In order to provide partial Secure Boot protection, we can ban CA 2011 boot managers. This leaves the PC insecure as the DBX signatures are designed to block banned non-Windows EFI boot files with known security exploits.

It's not a recommended solution, but some users have specifically asked for this type of outcome rather than give up their unsupported PC. Most normal users should be using the regular -Revoke option (when needed).

-RevokeNoDBX will disable the Secure Boot task, because we don't want Windows to force a DBX update whenever MS announces they will finally enforce the CA 2011 revocation. When the Secure Boot task is no longer running, the status reg keys are not updated. So the update script has to update the WindowsUEFICA2023Capable & UEFICA2023Status keys.

Nice addition.

garlin said:

UPDATE: 2026-10-08

1. Add option for Update_UEFI-CA2023.ps1 to block dbxupdate.bin updates
2. Update_UEFI-CA2023.ps1 needs to update SecureBoot reg keys when "Secure-Boot-Update" task is disabled or removed

Update_UEFI-CA2023.ps1 now has the -RevokeNoDBX option, which can be used in the place of -Revoke. Both options are mutually exclusive; you can only pick between one of the two. -RevokeNoDBX will ban the CA 2011 cert and update the SVN, without adding the hundreds of potentially new EFI signatures to the DBX.

Some users with older BIOS'es have a known (or suspected) HW or firmware limitation where overflowing the DBX with too much data can "brick" the UEFI. In order to provide partial Secure Boot protection, we can ban CA 2011 boot managers. This leaves the PC insecure as the DBX signatures are designed to block banned non-Windows EFI boot files with known security exploits.

It's not a recommended solution, but some users have specifically asked for this type of outcome rather than give up their unsupported PC. Most normal users should be using the regular -Revoke option (when needed).

-RevokeNoDBX will disable the Secure Boot task, because we don't want Windows to force a DBX update whenever MS announces they will finally enforce the CA 2011 revocation. When the Secure Boot task is no longer running, the status reg keys are not updated. So the update script has to update the WindowsUEFICA2023Capable & UEFICA2023Status keys.

Click to expand...

This is my main machine:

Scott said:

Nice addition.

Click to expand...

Some users have to disable the Secure Boot task because of unrelated TPM issues (for example, Dell's with a STMicroelectronics chip). When the task runs 5 min. after every reboot, it triggers a TPM attestation call (or audit). This locks up the system.

The task isn't necessarily doing any changes, but in order to refresh the status reg keys, it needs to run attestation to definitively prove that Secure Boot is indeed actually working. Without positive confirmation, certain updates are paused until the status can be verified. The lockups are an unintentional side effect of the task doing its normal thing.

Until there's a firmware fix for your TPM chip, some users are stuck disabling the task. It's not ideal, but you don't have an option. The good news is you can use the update script to do most of the same work (like updating the SVN and boot manager). My script can't do any attestation (it's a highly priviledged system call), so it won't hang your PC.