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

gunrunnerjohn · 2026-06-12T10:08:38-0400

garlin said:
Functionally it's not any different from creating your own privately-issued PK, and self-signing the pre-signed cert files that MS provides. If you had the same technical expertise and the right signing tools, you could do this yourself.

What Mosby accomplishes is the convenience of have an one-stop self-signing tool that works from a bootable USB. That's handy.

But with any crypto tool, you always have ask if your tools are secure. The source code for Mosby is available on GitHub for everyone to examine, but you might need to be a subject matter expert to fully understand the code. My approach is to use the MS-provided files, which are provided for PC vendors to use if they like. In my script, it's very transparent where we're downloading the keys from, and how it's installed.

Transparency is a big driver on how my scripts are done.

The Windows OEM Devices PK has already been used as an official mitigation for the "DO NOT TRUST - AMI Test" PK flaw. So there's previous precedent.

You can get into endless arguments over which approach is better (self-signed vs OEM delivery). But the Windows OEM Devices certs bundle is pre-packaged so it's known to work if you can get it correctly deployed. It doesn't change, so it's a more predictable outcome when dealing with Q&A. As you can tell, I can spend most of my day working with actual users.

Users can choose which way they want to replace their PK. But my update script will also take care of the Windows side of things (like dealing with a new version of the boot manager or SkuSiPolicy).

Makes perfect sense.

Now that I've used both methods, I do find your scripts be quicker and easier to get the job done. With Mosby I guess I counted on the fact that someone that understands the topic far better than I do would be spreading the word if Mosby was compromised. Of course, that could be a fallacy in my thinking! However, it's not like MSC hasn't stumbled with some of their software releases as well... :lmao:

anchamp65 · 2026-06-12T12:07:42-0400

SURPRISE ! SURPRISE !!!

A friends computer on which I never updated any of the certs manually and never force anything
Well MS a applied the SkuSiPolicy on it !!!
The friend has 2 computers, 1 for personal use and 1 for work, which I maintain for him
I never apply any custom tweaking like OOShutUp or service tweaking on firends computers or people that ask for my help
And that friend is in no way capable of doing any of this stuf by himself
For him a computer is something he has to use for email and web access but has no pleasure what so ever doing it

So there pretty much clean MS installs...

Well it seems MS does some times apply SkuSiPolicy !!!
And it did on the 4 years old personal computer, not on the 1 year old work one, go figure...

neldog · 2026-06-12T12:58:56-0400

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

I guess mine got out of step after the Tuesday June update. So, I had to apply the Required Actions. I think I am all good again.

LeeElectrode · 2026-06-12T13:46:22-0400

So I've successfully updated 3 Dell laptops and one Asus Desktop but I am having an issus with my wifes old Dell desktop.... I think it's a Optiplex 3050.
This PC lets me replace the KEK cert however when I reboot the PC it does get installed. None of the other Dells would allow this, they rejected the cert. If I delete all the keys and reboot I still get the same thing. So there is something about this PC that's wierd. Once it boots it takes 30 mins before the WiFi card connects to the router and gives me internet conectivity. To my knowledge this happened after a MS Update in April. I've run the scannow and DISM utilities and everything comes up roses. I won't be near this PC for another 9 days... Any insight is welecome! We're on a much needed RV trip...LOL

S C:\SecureBoot-CA-2023-Updates.v2026.05.31> ./Check_UEFI-CA2023.ps1 -audit
Secure Boot: OFF (Audit Report runs as ON)
Virtualization Based Security: OFF
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

EFI Files
---------
Boot File [Windows UEFI CA 2023] will be UNTRUSTED
Registry: "WindowsUEFICA2023Capable" = 2
[Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

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

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:\SecureBoot-CA-2023-Updates.v2026.05.31>

Capricornus · 2026-06-12T13:53:05-0400

On my HP Z440, i deleted the secure cert keys in the bios and ran the update script. That did not get me anywhere. I then reset the factory default certs in the bios, and ran Update_UEFI.bat -revoke. That worked and this time I got the dbx updates that gave me problems before: so, it confirmed your assumption Garlin that the dbx was corrupt as the computer became a lot faster, after switching it on to the point where it started to load windows 11.
The update script did tell me to manually add certs in the bios, and then reboot, buit I found no possibility to do so. So, I rebooted without manually adding anything.

However, since then, I have secure boot enabled in the bios, but when windows 11 is started, it finds no secure boot. When I look at the check_uefi.bat -verbose, I get this:

.\check-UEFI.bat -Verbose
PowerShell 7.6.2
Windows 11 25H2 (26200.8655)

Secure Boot: OFF
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
------------
(NONE)

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

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

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: 447

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

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

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

PS C:\Users\admin\Downloads\SecureBoot-CA-2023-Updates.v2026.06.08> .\Check-DBX.bat -Verbose
PowerShell 7.6.2
SUCCESS: Matched 289/289 EFI signatures from "dbxupdate.bin"
SUCCESS: Matched 3/3 SVN signatures from "DBXUpdate2024.bin"
SUCCESS: Matched 3/3 SVN signatures from "DBXUpdateSVN.bin"

I assume the problem is the UEFI PK cert being empty. It was populated before. How can I populate this again, or can I do something else?
I have now found out that if I want to get full bios admin access, I will need to open up my HP Z440, and re-add the jumper om the mainboard (which I took out to easily access the bios.). Do you think this may become necessary?

LeeElectrode · 2026-06-12T14:03:56-0400

LeeElectrode said:
So I've successfully updated 3 Dell laptops and one Asus Desktop but I am having an issus with my wifes old Dell desktop.... I think it's a Optiplex 3050.
This PC lets me replace the KEK cert however when I reboot the PC it does get installed. None of the other Dells would allow this, they rejected the cert. If I delete all the keys and reboot I still get the same thing. So there is something about this PC that's wierd. Once it boots it takes 30 mins before the WiFi card connects to the router and gives me internet conectivity. To my knowledge this happened after a MS Update in April. I've run the scannow and DISM utilities and everything comes up roses. I won't be near this PC for another 9 days... Any insight is welecome! We're on a much needed RV trip...LOL

S C:\SecureBoot-CA-2023-Updates.v2026.05.31> ./Check_UEFI-CA2023.ps1 -audit
Secure Boot: OFF (Audit Report runs as ON)
Virtualization Based Security: OFF
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

EFI Files
---------
Boot File [Windows UEFI CA 2023] will be UNTRUSTED
Registry: "WindowsUEFICA2023Capable" = 2
[Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

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

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:\SecureBoot-CA-2023-Updates.v2026.05.31>

Also I can enable or disable Secure boot at will.

garlin · 2026-06-12T15:55:23-0400

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

The last BIOS for Optiplex 3050 was Oct 2024, which isn't that old.

If it didn't have CA 2023 in the factory defaults, it should accept adding the KEK manually. But it appears not to have, I would try this sequence:

1. Disable Secure Boot.
2. Reset to Secure Boot (factory) defaults, so it's at a known good starting point.
3. Reset (power cycle).
4. Try add the KEK CA 2023 manually if that worked the first time. If not, Delete All Keys.
5. Run the update script.

Sometimes the BIOS gets "glitchy" and some sequence of resetting it will clear out any corrupted data. But we need to get the KEK CA 2023 installed.

anchamp65 · 2026-06-12T15:57:26-0400

anchamp65 said:
SURPRISE ! SURPRISE !!!

A friends computer on which I never updated any of the certs manually and never force anything
Well MS a applied the SkuSiPolicy on it !!!
The friend has 2 computers, 1 for personal use and 1 for work, which I maintain for him
I never apply any custom tweaking like OOShutUp or service tweaking on firends computers or people that ask for my help
And that friend is in no way capable of doing any of this stuf by himself
For him a computer is something he has to use for email and web access but has no pleasure what so ever doing it
So there pretty much clean MS installs...

Well it seems MS does some times apply SkuSiPolicy !!!
~~And it did on the 4 years old personal computer, not on the 1 year old work one, go figure...~~

Correction, I reconnected to the computers and its the 1 year old work that has SkuSiPolicy applied
But still, very surprised that MS applied it

@garlin have you seen other cases where MS applies it ?
Just wondering, but don't waist time on this because I'm not changing anything on it and leaving it as is
Dell Inspiron 15 3520

garlin · 2026-06-12T15:57:38-0400

Capricornus said:
UEFI PK Cert
------------
(NONE)

This is not good. You don't have a valid PK, so Secure Boot can never be enabled (requires an installed PK).
I would try running the update script again, since no PK is present to block re-installation of one.

Capricornus said:
I assume the problem is the UEFI PK cert being empty. It was populated before. How can I populate this again, or can I do something else?
I have now found out that if I want to get full bios admin access, I will need to open up my HP Z440, and re-add the jumper om the mainboard (which I took out to easily access the bios.). Do you think this may become necessary?

Maybe. I don't have any owner manuals for this model.

garlin · 2026-06-12T16:00:15-0400

anchamp65 said:
Correction, I reconnected to the computers and its the 1 year old work that has SkuSiPolicy applied
But still, very surprised that MS applied it

A SkuSiPolicy could be deployed if your HW supports all the VBS requirements out of the box. It's like how some PC's get automatic BitLocker, whether you asked for it or not. By meeting all the standards, Windows could be turning on the security feature by itself.

anchamp65 · 2026-06-12T16:02:55-0400

garlin said:
A SkuSiPolicy could be deployed if your HW supports all the VBS requirements out of the box. It's like how some PC's get automatic BitLocker, whether you asked for it or not. By meeting all the standards, Windows could be turning on the security feature by itself.

Thanks for the info

LeeElectrode · 2026-06-12T17:22:57-0400

garlin said:
The last BIOS for Optiplex 3050 was Oct 2024, which isn't that old.

If it didn't have CA 2023 in the factory defaults, it should accept adding the KEK manually. But it appears not to have, I would try this sequence:

1. Disable Secure Boot.
2. Reset to Secure Boot (factory) defaults, so it's at a known good starting point.
3. Reset (power cycle).
4. Try add the KEK CA 2023 manually if that worked the first time. If not, Delete All Keys.
5. Run the update script.

Sometimes the BIOS gets "glitchy" and some sequence of resetting it will clear out any corrupted data. But we need to get the KEK CA 2023 installed.

LeeElectrode · 2026-06-12T17:30:08-0400

I must be mistaken on the model number. I will try what you've suggest in a few days. I have read somewhere in this thread about having to set a password to do anything with the keys. I guess I could try that too.

garlin · 2026-06-12T17:44:20-0400

Some PC's require you to create an Admin password before unlocking advanced Secure Boot menu options. It's to prevent attackers from sitting in front of your PC and changing Secure Boot keys without your permission. Other PC's don't.

Scott · 2026-06-12T21:46:29-0400

garlin said:
It's to prevent attackers from sitting in front of your PC and changing Secure Boot keys without your permission.

Or turning Secure Boot off, allowing booting of any usb stick.

Might be a good idea to set a password just for that reason.

DarkShadowMD · 2026-06-12T23:09:15-0400

garlin said:
Some PC's require you to create an Admin password before unlocking advanced Secure Boot menu options. It's to prevent attackers from sitting in front of your PC and changing Secure Boot keys without your permission. Other PC's don't.

Acer is very known for that. My older Acer needed a supervisor password to mess with Secure Boot keys. In this case I remember having to manually add a shim64 thingy so Kubuntu could boot properly.

HuntyFtw · 2026-06-13T12:10:15-0400

I found this line in the high confidence data:
"0bfb1c263073236f89119210f25baa8cb4e2c088ef46b97ab47ffa186b1c83b3,AMD64,Acer,Acer,TGL,Predator Helios 300,QX60_TLS,V1.15,0000000000000000,PREDATOR PH315-54,V1.15,Insyde Corp.,V1.15,06/29/2023"
This is my laptop model, but Windows Security shows this. What does it mean to have my laptop's name in the data?

garlin · 2026-06-13T12:26:33-0400

There's two parts to the Confidence data.

1. Your specific motherboard/BIOS revision is used to assign everyone with this exact HW combination to an unique hash.

Everyone in the world who owns a Predator PH315-54 model AND BIOS v1.15 belongs to BucketID 0bfb1c263073236f89119210f25baa8cb4e2c088ef46b97ab47ffa186b1c83b3.

If you updated the BIOS (if another one existed), your hash would be different since that's a different unique PC/BIOS combination. MS gathers everyone's calculated BucketID (hash) and collects them into a giant database. They try to determine based on the majority of update results, whether automated updates will work for this unique hash.

Anywhere you see a long line with the model info (sometimes repeated several times), it's just identifying your BucketID. It's not a determination of upgradeability. You may be fortunate that you have a factory supported BIOS (success!) or your OEM submitted a signed KEK to MS (success!). Or you're unfortunate, and left behind.

2. Based on the results of your shared bucket group, MS assigns you into three categories: High Confidence (go), More Data Needed (paused), and forgot what the bad bucket was named (blocked). Those BucketID's who are listed in the Monthly Update's JSON are automatically updated. If your PC lives in "More Data Needed", it's in purgatory.

The confidence data is buried inside a JSON file where you only see ID's like 0bfb1c263073236f89119210f25baa8cb4e2c088ef46b97ab47ffa186b1c83b3, but without the model details.

In short, this Security Center summary is "sorry, your OEM doesn't support this PC". You'll have to manually update this PC, unless it's one those last minute stragglers than Acer is flooding out June BIOS updates for.

HuntyFtw · 2026-06-13T12:58:10-0400

garlin said:
There's two parts to the Confidence data.

1. Your specific motherboard/BIOS revision is used to assign everyone with this exact HW combination to an unique hash.

Everyone in the world who owns a Predator PH315-54 model AND BIOS v1.15 belongs to BucketID 0bfb1c263073236f89119210f25baa8cb4e2c088ef46b97ab47ffa186b1c83b3.

If you updated the BIOS (if another one existed), your hash would be different since that's a different unique PC/BIOS combination. MS gathers everyone's calculated BucketID (hash) and collects them into a giant database. They try to determine based on the majority of update results, whether automated updates will work for this unique hash.

Anywhere you see a long line with the model info (sometimes repeated several times), it's just identifying your BucketID. It's not a determination of upgradeability. You may be fortunate that you have a factory supported BIOS (success!) or your OEM submitted a signed KEK to MS (success!). Or you're unfortunate, and left behind.

2. Based on the results of your shared bucket group, MS assigns you into three categories: High Confidence (go), More Data Needed (paused), and forgot what the bad bucket was named (blocked). Those BucketID's who are listed in the Monthly Update's JSON are automatically updated. If your PC lives in "More Data Needed", it's in purgatory.

The confidence data is buried inside a JSON file where you only see ID's like 0bfb1c263073236f89119210f25baa8cb4e2c088ef46b97ab47ffa186b1c83b3, but without the model details.

In short, this Security Center summary is "sorry, your OEM doesn't support this PC". You'll have to manually update this PC, unless it's one those last minute stragglers than Acer is flooding out June BIOS updates for.

Thanks for the info. And yes, my PC is in the list, but the updates are spread throughout June and even July for some weird reason.

garioch7 · 2026-06-13T13:14:05-0400

@garlin ,

My 2019 Dell XPS 8930 SE (last BIOS version 1.31) did not update the Secure Boot with the new certificates after the June Windows Update to 26200.8655) - Computer Specs 1. My 2020 Dell XPS XPS 15 7590 - Computer Spec 2, also not on the supported list for Dell BIOS updates, miraculously, and without notice, did update itself to the new certificates about six weeks ago, according to the Windows Device Security, Secure Boot screen.

It appears that I will have to manually update my 8930 Secure Boot keys. Is this post still the latest and applicable to that computer: How to check if your Secure Boot certs are updated. (three methods)?

I am really nervous about messing with the BIOS and bricking this expensive 8930 SE rigged out for HD video editing.

I have been perusing this topic for months now, and was hoping that Windows would perform a miracle for my 8930, but alas ...

Also, is there a consolidated posts somewhere in this topic that has all of the download links for the files and scripts that I will need?

I am totally illiterate about Boot Certificates. I know only enough that to know that any time you mess with the BIOS when you don't know and don't understand what you are doing, it is a recipe for disaster, only pursued by fools and idiots.

I really would like a simplified, but comprehensive reply that would precisely identify what steps I should take, and in what order, or a link to an existing post that does so.

I am a great fan of your dedication and knowledge. You have helped many, and I would like to be another person you helped.

Have a great day, and keep up the outstanding work here.

Regards,
Phil

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

Well-known member

My Computers

Active member

My Computer

Rancho Seldom Siesta

My Computers

Member

My Computer

New member

My Computer

Member

My Computer

Well-known member

My Computer

Active member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Active member

My Computer

Member

My Computer

Member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Peaceful Citizen

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Retired R.C.M.P. Veteran

My Computers