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

nikki605 · 2026-06-11T07:47:16-0400

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

Since I only used it once to add the Mosby keys, I'm not sure I will need it again. I don't even remember the steps I used to use Rufus & Mosby to add the keys. (I'm old and have frequent senior moments).

gunrunnerjohn · 2026-06-11T09:37:21-0400

nikki605 said:
Since I only used it once to add the Mosby keys, I'm not sure I will need it again. I don't even remember the steps I used to use Rufus & Mosby to add the keys. (I'm old and have frequent senior moments).

These scripts accomplish the same job as Mosby, but there's simpler to run. I updated a number of systems with Mosby, but the last two I've done with the @garlin scripts. The end result is I have a fully updated system with Secure Boot enabled.

anchamp65 · 2026-06-11T10:29:42-0400

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

Yes, you did mention that in previous posts and your code is there to prove it.

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

That's the part that worries me...

Some people at MS, because I don't beleive it's everyone, have a tendancy to think they can do better then the rest of the industry and publish something that is completely different then what the rest of the industry uses.

That's why I might seem obsessed with wanting MS to it by itself on my main computers (Dell 3910 & SP9 Pro).

So sorry if you might have perceived my questions or reactions has questionning your work.
There are now 2,282 posts that are proof of the quality of your work and dedication to supporting all of us !!!

garlin · 2026-06-11T10:45:21-0400

JamesSmith said:
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?

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

The Secure Boot task is the intended mechanism for applying all future changes. I can imagine MS is hesitant (for now) to allow the task to update revocation settings because of the non-zero risk of "bricking" your Windows.

It's relatively safe to add new CA 2023 certs, since that doesn't prevent you from using CA 2011 boot managers.

Anything that is a revocation action is by design restrictive. If you don't apply the changes in lockstep, Windows might stop booting until you temporarily disable Secure Boot. So MS may be slow rolling updates, like it appears the SVN isn't automatically applied to the DBX.

In short, for now there is no risk presented by the Secure Boot task. But then it's not always going to apply every security change right away. Again, I don't work for MS. The best I can do is provide tools to allow users to check their status, and do their own updates.

garlin · 2026-06-11T10:47:16-0400

jabbado said:
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.

You may have to delete all keys to unlock Custom mode. Since by definition, there are no more factory keys at that point.

garlin · 2026-06-11T10:57:37-0400

Capricornus said:
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:

Re-run the update script with -Revoke option.

I'm making an upcoming script change to allow more automatic updates, if you already have revoked CA 2011. When I first wrote the update script, it was intended as an "one and done" task to finish the CA 2023 migration process. The idea was after you climbed over the CA 2023 hurdle, Windows would take care of future updates.

Therefore the script wouldn't perform a revocation unless you explicitly asked. The problem is I moved most of the post-revocation actions to the "other side of the wall" where revocation is done and thus the script expects you to use -Revoke. After a few months, that's kinda annoying that the user needs to know I put in a safety mechanism.

itsme1 · 2026-06-11T11:18:41-0400

I can't update SkuSiPolicy and view its version using your latest script.

I get the error ERROR: bcdedit {bootmgr} device D: is not FAT32 when I check with Check-UEFI.bat and with the command Update_UEFI-CA2023.ps1 -SkuSiPolicy.

I previously used an older version of your script to view and update SkuSiPolicy on this same computer without encountering this error.

garlin · 2026-06-11T11:30:39-0400

ryan190123 said:
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?

You might have to try fixing the task.

Code:

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

Dirtyflash · 2026-06-11T12:15:28-0400

gunrunnerjohn said:
These scripts accomplish the same job as Mosby, but there's simpler to run. I updated a number of systems with Mosby, but the last two I've done with the @garlin scripts. The end result is I have a fully updated system with Secure Boot enabled.

I totally agree that @garlin 's scripts are the preferred method, that's until you run into a very unusual situation like the PK key on the Lenovo T460 that throws security violation errors. That's where Mosby comes in to stab the PK in the heart and kill it by replacing it with its own custom version, thereby allowing the 2023 certs to be installed.

garlin · 2026-06-11T12:28:10-0400

Mosby and the update script operate on the same basic principle: You can't make certain changes while the vendor's PK is in place.

It's part of the UEFI security model. The PK's presence forces authentication of whatever new keys you're adding, which implies they must be properly signed. Only the vendor owns the private key for the PK, so you can't just add a KEK CA 2023 without their help.

If you're sitting in front of the BIOS, you can enroll a pre-signed cert file because it takes a physical presence. This cannot be scripted, so it's a trusted step. To counter attackers from using this method, you can assign a BIOS password.

Mosby or any other scripted method requires you to delete the default PK (since you didn't create it), thus removing the authentication problem. Mosby chooses to self-sign a randomly unique cert, which is a norm in the Linux community (lots of guides on how to do this). I choose to use the Windows OEM Devices certs (which includes a MS provided PK).

All I'm offering the user is an update solution using 100% MS-provided security files. For some users, they may prefer that choice.

hottroc · 2026-06-11T12:41:50-0400

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

Ah thanks for the clarification (and to DirtyFlash too). I deliberately did not want to revoke anything in case it blocked something from working (unless it was the cause of the problem itself). So do you have any suggestion on the "somewhere else" or would it be better to ask in a different topic?

Ed Tittel · 2026-06-11T12:42:16-0400

Hey @garlin:
On my 2020 vintage (11th Gen Intel) Lenovo Hybrid Tablet X12 I'm stuck in a loop. I think this is the relevant output from the check script run with audit verbose options engaged:

EFI Files
---------
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.

SkuSiPolicy.p7b is CURRENT.

REQUIRED ACTION
===============
To install Windows Boot Manager [UEFI CA 2023], run the commands:

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

I've run the registry update and powershell task thing twice. In regedit the AvailableUpdates entry appears but has a zero value. What, if anything, should I do. The machine is booting fine.
--Ed--

Capricornus · 2026-06-11T12:53:32-0400

garlin said:
Re-run the update script with -Revoke option.

I'm making an upcoming script change to allow more automatic updates, if you already have revoked CA 2011. When I first wrote the update script, it was intended as an "one and done" task to finish the CA 2023 migration process. The idea was after you climbed over the CA 2023 hurdle, Windows would take care of future updates.

Therefore the script wouldn't perform a revocation unless you explicitly asked. The problem is I moved most of the post-revocation actions to the "other side of the wall" where revocation is done and thus the script expects you to use -Revoke. After a few months, that's kinda annoying that the user needs to know I put in a safety mechanism.

I ran the update script with the revoke option on my HP Z440, but I get this error:
ERROR: Failed to append "dbxupdate.bin" to UEFI DBX

And this is the output from check-uefi.bat -verbose:
Windows 11 25H2 (26200.8655)

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

BIOS Firmware
-------------
Hewlett-Packard HP Z440 Workstation
Version: M60 v02.62
Date: 2024-01-04

Factory Default UEFI PK Cert
----------------------------
Hewlett-Packard UEFI Secure Boot Platform Key

UEFI PK Cert
------------
Hewlett-Packard UEFI Secure Boot Platform Key

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Hewlett-Packard UEFI Secure Boot Key Exchange Key

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
Hewlett-Packard UEFI Secure Boot Key Exchange Key

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Hewlett-Packard UEFI Secure Boot DB Key

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
Hewlett-Packard UEFI Secure Boot DB Key
HP UEFI Secure Boot 2013 DB key

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

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 9.0
EFI_CERT_SHA256_GUID Signatures: 817

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 is CURRENT.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Version: 3.0.0.15

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"

Unfortunately this required action does not work.

garlin · 2026-06-11T12:57:05-0400

Ed Tittel said:
On my 2020 vintage (11th Gen Intel) Lenovo Hybrid Tablet X12 I'm stuck in a loop. I think this is the relevant output from the check script run with audit verbose options engaged:

Ed Tittel said:
I've run the registry update and powershell task thing twice. In regedit the AvailableUpdates entry appears but has a zero value. What, if anything, should I do. The machine is booting fine.

--Ed--

Run the check script with -Verbose. You need to see the version numbers.

When the boot manager gets replaced you get a triple whammy:

- new boot manager

- new SVN

- new SkuSiPolicy (because they probably replaced winload.efi at the same time)

If you don't line up a new boot manager and winload.efi (from applying the Monthly Update), then it will fail a security check. On paper, the Secure Boot task is supposed to correctly update, but I don't know if MS has extra paranoia checking that makes it avoid some update actions.

My update script just compares the SecureBootUpdates folder files, and does the right things (when used with the -Revoke option).

garlin · 2026-06-11T13:07:58-0400

Capricornus said:
I ran the update script with the revoke option on my HP Z440, but I get this error:
ERROR: Failed to append "dbxupdate.bin" to UEFI DBX

I just rebooted after installing June 2026 Monthly Update.

Code:

PS C:\Users\GARLIN\Downloads> .\Check_DBXUpdate.bin.ps1 -verbose
FAILED: Missing 11/289 EFI signatures from "dbxupdate.bin"

SUCCESS: Matched 3/3 SVN signatures from "DBXUpdate2024.bin"
FAILED: Missing 1/3 SVN signatures from "DBXUpdateSVN.bin"
    Missing [01612B139DD5598843AB1C185C3CB2EB92000009000000000000000000000000] bootmgfw.efi SVN 9.0

Code:

PS C:\Users\GARLIN\Downloads> .\Update_UEFI-CA2023.ps1 -revoke
Successfully appended "dbxupdate.bin" to UEFI DBX.
Successfully appended "DBXUpdateSVN.bin" (SVN 9.0) to UEFI DBX.

REQUIRED ACTION
---------------
Restart Windows, for UEFI updates to take effect.

Can you run:
Check-DBX.bat -verbose

If you get an output that's over like 20 lines, you don't need to copy the whole output, maybe the last 20 lines of text.

Capricornus · 2026-06-11T13:24:49-0400

Running check-dbx.bat -verbose only gives:

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"

garlin · 2026-06-11T13:42:17-0400

That's really strange you got 3/3 SVN matched from DBXUpdateSVN.bin. This implies your SVN is now 9.0 (expected).

So there should be no authentication errors from installing the missing 11 EFI signatures. Both .bin files are signed by the same DB cert. Try rebooting, and running the update script again.

MS is lagging on updating the JSON file for DBXUpdate on the GitHub repo. So I can't inform you what boot files they banned, could be 3rd-party products.

Capricornus · 2026-06-11T13:49:33-0400

I rebooted and ran
.\Update_UEFI-CA2023.ps1 -Revoke
ERROR: Failed to append "dbxupdate.bin" to UEFI DBX.

garlin · 2026-06-11T13:58:14-0400

I dunno, unless you want to try resetting the UEFI back to factory defaults and repeat the same process you used to update the certs. The DBX variable might be corrupted.

Capricornus · 2026-06-11T14:00:30-0400

I will try that. Thanks.

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

Well-known member

My Computers

Well-known member

My Computers

Active member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

New member

My Computer

Well-known member

My Computers

New member

My Computer

Well-known member

My Computer

Well-known member

My Computer

New member

My Computer

Well-known member

My Computer

New member

My Computer

Well-known member

My Computer

New member

My Computer