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

Dirtyflash said:

@garlin

Here's a great article where you get mentioned, you're famous. Everyone can learn a lot from reading it:

Windows 11's Secure Boot 2023 updates are failing across some PCs, exposing a wider firmware problem

Microsoft’s CA-2023 Secure Boot update broke PCs. Learn why UEFI firmware failed, how vendors reacted, and how to fix your boot issues.

www.windowslatest.com

Click to expand...

Nice to see garlin getting some recognition for all the work he's put into these scripts.

gunrunnerjohn said:

Nice to see garlin getting some recognition for all the work he's put into these scripts.

Click to expand...

The man is a godsend. Thanks to him all my systems are fully updated, even with revocations and a bootable USB.
He should be Microsoft's CEO, a true warrior.

@Ed Tittel very well written article, thanks.

As it turns out, @garlin can code

On Windows 2016 When I run the Check_UEFI-CA2023 , I am getting the following results with errors and when I run Check_DBXUpdate I am getting "FAILED: Missing 420/431 EFI signatures from "dbxupdate.bin". Any thoughts?

TooMuchCaffeine said:

On Windows 2016 When I run the Check_UEFI-CA2023 , I am getting the following results with errors and when I run Check_DBXUpdate I am getting "FAILED: Missing 420/431 EFI signatures from "dbxupdate.bin". Any thoughts?

BIOS Firmware
-------------
Dell Inc. PowerEdge R530
Version: 2.19.0
Date: 2024-02-21

Factory Default UEFI PK Cert
----------------------------
Dell UEFI PK PowerEdge

UEFI PK Cert
------------
Dell UEFI PK PowerEdge
Manual update of [KEK CA 2023] is REQUIRED

Click to expand...

Your last BIOS update is 2024, but none of the Dell release notes mentions anything about Secure Boot certs.

The PK signature check is done by running your Dell's PK through the MS GitHub list of vendor PK's which have signed a KEK CA 2023 for MS. I find it strange that Dell updated the BIOS to 2024, but apparently failed the steps you'd expect to support the migration.

Automatic updates can't be done. What you need to do is to check if your Dell BIOS has a manual key enrollment in the UEFI menu. Based on other Dell owners (but you're the first person with an enterprise-class box), it's going to reject the .der or .crt formatted file in favor of an .auth file.

We can't do the .auth since that assumes we have access to keys we don't have. The worst case is going into Setup Mode, which wipes the original Dell certs (PK and all private Dell KEK's and DB's), and installing the Windows OEM Devices PK as a drop-in replacement.

If you're in a true enterprise environment, your manager or manager's manager may not be happen with this solution. It should work from a Secure Boot point of view, but I have no idea if you're using any UEFI-based remote management tools, etc.

TooMuchCaffeine said:

UEFI DBX Certs
--------------
(NONE)
Windows BootMgr SVN is MISSING.
EFI_CERT_SHA256_GUID Signatures: 14

Click to expand...

In the old days, the method to ban compromised EFI boot files was for vendors to add their signature hashes to the DBX. You have a factory list of 14 hashes. Most vendors added somewhat more, but they got out of the practice since MS promised to take over and manage DBX EFI signatures.

Windows has a list of 431 signatures (some of which may duplicate your factory list). This tells me your BIOS is super outdated (even though it received a 2024 firmware). You could try Setup Mode to get into CA 2023 compliance, but I don't know the consequences of losing the Dell KEK and DB certs. I don't know if something in your environment would depend on it.

It could also be you're never going another firmware update again with this PowerEdge's age.

Thanks for taking the time to look at this, I really appreciate your input.

I can honestly say I never would've gotten Secure Boot working and updated on ALL 12 of my PCs if it hadn't been for the @garlin scripts. That's why I plugged them so mercilessly in that WindowsLatest story. All I can say further on this thread is: Keep up the good work!
--Ed--

Ed Tittel said:

I can honestly say I never would've gotten Secure Boot working and updated on ALL 12 of my PCs if it hadn't been for the @garlin scripts. That's why I plugged them so mercilessly in that WindowsLatest story. All I can say further on this thread is: Keep up the good work!
--Ed--

Click to expand...

Here, here... A lot of people owe @garlin a big thank you, me included. Glade to see you give him some print time. That was very kind of you.

Ed Tittel said:

I can honestly say I never would've gotten Secure Boot working and updated on ALL 12 of my PCs if it hadn't been for the @garlin scripts. That's why I plugged them so mercilessly in that WindowsLatest story. All I can say further on this thread is: Keep up the good work!
--Ed--

Click to expand...

Thanks to Ed, I recently had an ironic twist on another Windows forum.

I tried to correct a resident guru's reply that W10 22H2 can't support the Secure Boot update process (it can because all of the current cert files got pushed in Oct. 2025 before normal support ended). That person suggested I go read Ed's article...

garlin said:

That person suggested I go read Ed's article...

Click to expand...

That's too funny... Oh well.

Hey, I think it's funny, too. Thanks for sharing.
--Ed--

garlin said:

Thanks to Ed, I recently had an ironic twist on another Windows forum.

I tried to correct a resident guru's reply that W10 22H2 can't support the Secure Boot update process (it can because all of the current cert files got pushed in Oct. 2025 before normal support ended). That person suggested I go read Ed's article...

Click to expand...

WELL??? Did you read it???

News flash! News Flash! @garlin and all other interested parties.
Windows Security is now showing Secure Boot status in Device Security.
My problem is there are two different "status=OK" messages and I can't figure out how MS decides them and what they mean
One status is OK, no further cert changes needed; the other is "SB is protecting your system"

One one system where no further cert changes needed, here's the output from check_UEFI-CA-2023
.\Check_UEFI-CA2023.ps1
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) ON

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

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

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

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 (for VBS) is MISSING. [OPTIONAL]


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

To install [UEFI CA 2023] certs, run the commands:

manage-bde -Protectors -Disable C: -RebootCount 1
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5800 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

On the other system that says OK but says nothing about no further changes needed, here's the same script's output
.\check_UEFI-CA2023.ps1   pwsh   100  09:59:56 
Secure Boot: 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
--------------
(NONE)

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.

Disk 1: SkuSiPolicy.p7b (for VBS) is CURRENT.


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

To revoke the [PCA 2011] cert, run the commands, run the commands:

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

What am I missing here? Is it really just as simple as revoking/leaving CA-2011? What's the deal with the SVN 7.0 revoked on machine 1 (first listing above).

Somebody, please help me get this straight. I'm confused.
--Ed--

Ed Tittel said:

News flash! News Flash! @garlin and all other interested parties.
Windows Security is now showing Secure Boot status in Device Security.
My problem is there are two different "status=OK" messages and I can't figure out how MS decides them and what they mean

Click to expand...

MS did announce before that it was adding a "Secure Boot dashboard" feature to Security Center.

Ed Tittel said:

One status is OK, no further cert changes needed; the other is "SB is protecting your system"

One one system where no further cert changes needed, here's the output from check_UEFI-CA-2023
.\Check_UEFI-CA2023.ps1
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) ON

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

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

Click to expand...

This has the bare minimum of DB certs to boot Windows. The Microsoft (not Windows) certs for Linux are missing, along with Option ROM.

Ed Tittel said:

On the other system that says OK but says nothing about no further changes needed, here's the same script's output
.\check_UEFI-CA2023.ps1   pwsh   100  09:59:56 
Secure Boot: 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

Click to expand...

This is what's expected, but I don't know how SecHealthUI treats the previous example.

Ed Tittel said:

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

Click to expand...

Revocation has not been done. Which is still optional for now. I would expect SecHealthUI not to flag this until later this year.

For the first PC, you can run the update script or AvailableUpdates=x5800 to backfill the other certs. They're not mandatory, but it keeps everything easier rather than trying to account for the differences. Since all full set of certs doesn't hurt the PC.

running update script on P16G3 now. will report findings after it reboots.
Thanks for checking this out for me.
--Ed--

Here's the output of the check script after running update script. What can you tell me about getting SkuSiPolicy.p7b installed on that PC?
.\check_UEFI-CA2023.ps1
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) ON

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

UEFI DB Certs
-------------
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
---------
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 (for VBS) is MISSING. [OPTIONAL]

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

SUCCESS: UPDATES ARE FINISHED. UEFI CA 2023 certs are present, PCA 2011 cert is revoked.

Update_UEFI-CA2023.ps1 -SkuSiPolicy

When I first wrote the update script, it automatically copied the SkuSiPolicy policy if VBS was enabled. But that can create problems with users who dual-boot with Insider releases or some bootable Macrium drives, since there could be a conflict with the boot file versions.

Now you have to ask the script to copy SkuSiPolicy. It’s probably safe to always update SkuSiPolicy if you only use one Windows and don’t switch around releases. I don’t want to risk guessing what you want to do with the PC.

@garlin
Copilot told me running update_uefi-CA2023.ps1 -SkuSiPolicy would take care of the missing item. It did. Thought you'd be tickled to learn that AI is hip to your tricks. Thanks, thanks, thanks again.

If you have any thoughts about why the status check in Windows Security > Device Security > Secure Boot offers two different status messages for its OK status (one that mentions "all required certificate updates have been applied" and one that doesn't) I'd be all ears. In fact, I'd love it if you'd post a comment on my blog post at Windows Security Checks Secure Boot - Ed Tittel to share your thoughts there. Or do it here and I'll link to it in my post, for sure.

Thanks yet one more time.
--Ed--

Where do you find this Device Security listing? I went to SETUP, Privacy & Security, Windows Security, Device Security.

This is all I see, nowhere do I find any "OK status" or any status other than the tiny green checkmark. Am I looking in the wrong place?

I’ll take a look after my test Windows gets the update. It currently doesn’t have the Secure Boot feature visible.

My current thought is the dashboard is well intentioned, but dubious. What I mean is it doesn’t list what criteria it used, like providing a list of found certs or your boot manager’s status. On one hand, MS instructs you to manually check a bunch of reg keys, but doesn’t visually confirm those same settings in the dashboard.

By “dumbing it down” in the current rollout, it’s not as helpful nor does it fully replace a check script. Hopefully this Security Center feature gets more detailed over time.

@gunrunnerjohn: In my blog post and in its cited Windows Latest article you would have found an explanation that the green checkmark in the little icon to the left of the "Secure Boot" text is the OK marker. Sorry if that wasn't crystal clear. It's there: you needed more info to recognize it for what it is. And FWIW, I agree with @garlin that this dumbed down version doesn't tell us everything we might need or want to know about Secure Boot status. His Check_UEFI-CA2023.ps1 script remains my "gold standard" for insight into what's up with Secure Boot on any of my Windows systems.
--Ed--