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

Dirtyflash said:

There was no need to update the Mosby USB stick as it never boots the device, rather it only appends and amends the UEFI in the NVRAM.

Click to expand...

Okay, good to know. I wasn't sure if I even needed to bother.

nikki605 said:

Okay, good to know. I wasn't sure if I even needed to bother.

Click to expand...

I was looking at Mosby on GitHub after your previous post. There is a new version 3.2 that was released a week ago.

hottroc said:

Sorry that went over my head a little. So please just tell me what I should do? Or nothing? And would this be any factor in my boot problems? Thank you for your help btw, really appreciate your efforts.

Click to expand...

That means you didn't revoke the CA 2011 certs yet. Which would be a good thing, since it could have been a potential blocker to booting. But if you're still have boot problems, it means the reason lies somewhere else.

jabbado said:

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

Click to expand...

jabbado 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.[/CODE]

Click to expand...

You have an unsupported BIOS.

The manual steps (from the README_UEFI.TXT) are to look in your BIOS menu, for an option to manually add a KEK key.

If you find this option, it will provide a list of drive devices and you search the device(s) until you find an \EFI folder. Under the EFI folder will be a "Certs" subfolder. In that folder is a KEK CA 2023 file to import.

Presuming that step goes well, restart Windows. Now run the update script again. If you don't have a KEK manual enrollment option, we need to proceed to deleting all keys first from the BIOS menu. Then restart Windows, and run the update script again.

garlin said:

If you find this option, it will provide a list of drive devices and you search the device(s) until you find an \EFI folder. Under the EFI folder will be a "Certs" subfolder. In that folder is a KEK CA 2023 file to import.

Click to expand...

Thank you for helping.
Yes the bios has options to enroll keys. But as I mentioned in my OP, there are no files in the 'certs' folder for some reason.

Try running the update script again, without the -Revoke option. The script should report it's copying the cert files to \EFI\Certs.

After the script is done copying, confirm the .der & .crt files are present on the EFI volume:

Ok now I'm confused. After mounting the efi partition the certs are there. In the bios I can browse to the cert folder but it shows empty.



Those top options can't be changed. But what does "Installed and Locked" mean?

I believe you want "User Customized Security", otherwise it's locked to the factory defaults.

garlin said:

I believe you want "User Customized Security", otherwise it's locked to the factory defaults.

Click to expand...

I suspect that. However I can't see a setting to enable it?

You may have to create a BIOS password to unlock the advanced options.

@garlin
I waited 24hrs to see if MS task Secure-Boot-Update would update the SVN to 9.0, it didn't
Task runs but always finishes with last run result 0x800706D9
As your check script suggest, I set the AvailableUpdates registry to 0x200 and ran the task again which terminated again with 0x800706D9
Rebooted any way, and it did bump SVN to 9.0
So it does do it's job, but always exits with 0x800706D9
That was on my Dell 3910.

Task has the same result on my Surface Pro 9 but I haven't set AvailableUpdates to 0x200 yet just to see if it will eventually do the SVN bump to 9.0

Any insight on the task result I'm getting... ?

garlin said:

You may have to create a BIOS password to unlock the advanced options.

Click to expand...

Did that and still can't see a way of enabling custom mode anywhere in the bios. Would I need to reset secureboot to factory settings?

anchamp65 said:

So it does do it's job, but always exits with 0x800706D9
That was on my Dell 3910.

Task has the same result on my Surface Pro 9 but I haven't set AvailableUpdates to 0x200 yet just to see if it will eventually do the SVN bump to 9.0

Click to expand...

I don't work for MS, and can't tell you why Secure Boot isn't designed that way.

Error code 0x800706D9 is related to RPC not finding a correct endpoint. Meaning the task wanted to work with something else, and failed to.

There's always my update script. It just does the job without flinching: appends the current DBXUpdateSVN.bin's contents when something's missing from the DBX update file.

jabbado said:

Did that and still can't see a way of enabling custom mode anywhere in the bios. Would I need to reset secureboot to factory settings?

Click to expand...

No, that's not going to help. Are you allowed to use "Erase All Secure Boot Settings"? This should put it into Setup Mode (no certs).

If you can, chose that option. Restart Windows, and run the update script.

garlin said:

There's always my update script. It just does the job without flinching: appends the current DBXUpdateSVN.bin's contents when something's missing from the DBX update file.

Click to expand...

I know your script does it, and I fully trust your script !!!
I've used and still do on 5 other computers, 3 old laptops and 2 VMs, I never wait for MS on those

I'm just worried that in 12 or 18 months if you move on to something else, if I'm still relying on your script but you stop updating it and it no longer works, I'll be stuck...

That's what's driving my need to see MS do it itself on my Dell 3910 and SP9 Pro

anchamp65 said:

I know your script does it, and I fully trust your script !!!
I've used and still do on 5 other computers, 3 old laptops and 2 VMs, I never wait for MS on those

I'm just worried that in 12 or 18 months if you move on to something else, if I'm still relying on your script but you stop updating it and it no longer works, I'll be stuck...

Click to expand...

Assuming everyone's finished with Secure Boot certs, the only future changes will be unscheduled releases of the DBX EFI signatures and a new boot manager.

The update script is agnostic, it really doesn't care about what version is present on your PC or pushed out in the SecureBootUpdates folder. It performs a comparison of the DBX file contents and determines if any updates are needed.

The only risk is MS does something stupid like changing the binary file formats for "Legacy" and non-Legacy versions. I have no idea why they decided it was necessary to use a proprietary, MS-only encoding scheme where they added extra header bytes. There's an existing UEFI standards spec already for the file format.

MS was nice enough to answer my posted question to them in short order, but unless they do something stupid again, the update scripts should function without my tweaking. In fact the update script was probably the 2nd easiest script to write because it's functionality is so limited. Most of it is safety logic to prevent the script from doing bad things.

In comparison, the check script has to accommodate all sorts of weird and random PC conditions.

24 Hours after updating to June This is what I have.

I know that running
Update_UEFI-CA2023.ps1 -Revoke -SkuSiPolicy will fix everything.

Is there a way to automate this without running your script? I love your script. Is there some setting I have forgotten to enable for these things to be updated by MS instead of your script?


PS C:\SecureBoot-CA-2023-Updates.v2026.06.08> powershell -nop -ep bypass -f .\Check_UEFI-CA2023.ps1 -verbose -audit
Windows 11 25H2 (26200.8655)

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

BIOS Firmware
-------------
Gigabyte Technology Co. B760M H DDR4
Version: F14
Date: 2025-06-19

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 8.0
EFI_CERT_SHA256_GUID Signatures: 497

UEFI Variables
--------------
Credential Guard: ON
SBAT (Linux only): sbat,1,2024010900 / shim,4 / grub,3 / grub.debian,4

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

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

SkuSiPolicy.p7b Version: 3.0.0.14 is WRONG VERSION.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Version: 3.0.0.14

SkuSiPolicy.p7b is WRONG VERSION.


AUDIT REPORT
============
1. SecureBootUpdates SVN is higher than UEFI DBX
2. SkuSiPolicy.p7b is not updated


REQUIRED ACTION
===============
To update the DBX SVN, run the commands:

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

[OPTIONAL] To update SkuSiPolicy.p7b, run the command:
Update_UEFI-CA2023.ps1 -SkuSiPolicy

PS C:\SecureBoot-CA-2023-Updates.v2026.06.08>

garlin said:

Are you allowed to use "Erase All Secure Boot Settings"? This should put it into Setup Mode (no certs).

If you can, chose that option. Restart Windows, and run the update script.

Click to expand...

I'm just a little worried your script won't be able to install the certs because of the locked key db. I can't understand why there doesn't appear a way to unlock custom mode. Unless erasing the settings will do it.

Having seen that there were updated scripts (2026-06-08), I ran them on my three computers. On my oldest computer (Lenovo all-in-one with a UEFI from 2012) it worked well. I updated the SVN to 9.0 and the latest Skusipolicy, and the dbx. On running an audit, all was well. The same for my newest computer (gigabyte X570 with 5800X). However, on my HP Z440 workstation, things did not go as expected. With secure boot on, I tried to update everything: SVN was updated to 9.0, Skuispolicy became current, but it did not add to the dbx. I then ran it with secure boot disabled, but got the same result:
Secure Boot: OFF (Audit Report runs as ON)
Virtualization Based Security: ON
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 9.0

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] will be ALLOWED.

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

SkuSiPolicy.p7b is CURRENT.


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


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"

ON running the required action several times and rebooting in between, I still get the message: DBX Updates are missing from UEFI DBX.
Running check_DBXUpdate.bin.ps1 results in:
FAILED: Missing 11/289 EFI signatures from "dbxupdate.bin"
SUCCESS: Matched 3/3 SVN signatures from "DBXUpdate2024.bin"
SUCCESS: Matched 3/3 SVN signatures from "DBXUpdateSVN.bin"

Any idea what I should do now?

garlin said:

Run this command to check on your Secure Boot task:

Code:

>powershell -f C:\Windows\SecureBoot\ExampleRolloutScripts\Enable-SecureBootUpdateTask.ps1 check

========================================
 Secure Boot Update Task Enabler
========================================

Task: \Microsoft\Windows\PI\Secure-Boot-Update

Checking: Y50-70
  State: Ready

========================================
 Summary
========================================
Total Checked: 1
Enabled:


ComputerName : Y50-70
TaskExists   : True
TaskState    : Ready
IsEnabled    : True
LastRunTime  :
NextRunTime  :
Error        :

Presuming you have a different result, then recreate the missing task:

Code:

powershell -f C:\Windows\SecureBoot\ExampleRolloutScripts\Enable-SecureBootUpdateTask.ps1 create
powershell -f C:\Windows\SecureBoot\ExampleRolloutScripts\Enable-SecureBootUpdateTask.ps1 enable

Click to expand...

Thanks I get the following:
========================================
Secure Boot Update Task Enabler
========================================

Task: \Microsoft\Windows\PI\Secure-Boot-Update

Checking: LT26-006
State: Ready

========================================
Summary
========================================
Total Checked: 1
Enabled:


ComputerName : LT26-006
TaskExists : True
TaskState : Ready
IsEnabled : True
LastRunTime :
NextRunTime :
Error :


I'm guessing " TaskExists : True" means the task "-TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"" is there but If i look under "\Microsoft\Windows\PI\" in task sched there is nothing there. Is that normal?