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

MS is hedging their bets. The universe has too many possible PC models and BIOS versions to chase down. So if they cannot collect data from customers who have already forced the updates, they're hesitant to expose your PC.

It might be your PC updates perfectly fine, but not enough supporting data is available to make that call. It's like the gradual rollouts, someone will get a shiny Windows feature before you, even though everyone has the same Windows updates. The constraint is entirely artificial, created by MS and managed by MS.

If you have a rare PC, because very few of the model was manufactured and sold in the first place, or almost all existing models were binned, there won't be a sample size big enough to switch your PC from "More Data Needed" to "High Confidence". Following the Confidence data like it's gospel is a mistake.

The best thing you can do is run the update script, and report if it was successful or what message it returned.

Well it's updated now! In terms of the not enough data message, I turned on send diagnostics - not sure if that helped. It was odd though it kept showing as needing updating. I then did a couple of lenovo updates and suddenly secure boot was up to date. Might have been a coincidence and it was just updating in the background, because the lenovo updates were just related to a thermal driver and function keys.

You can run the check script in verbose mode, and confirm if Lenovo pushed a new BIOS image (based on the firmware date).

I would like to give some feedback on updating my older HP Z440 workstation:
I first had to remove the bios admin password by removing a jumper at position E49 on the mainboard. The manual says it is a blue jumper, but it looks green to me, especially when holding it up to natural light. That removal worked well. No more bios admin password.
Then, all I did was to set secure boot to ON. Any other settings I left alone.
On rebooting win 11 told me under settings - privacy & settings - windows security - device security - secure boot:
Secure boot is on, but there is a known issue. Secure Boot certificate updates are paused.....etc.

That gave me a lot to think about, as I use this computer to run my business.

On the other hand the script Check_UEFI-CA2023.ps1 indicated a straightforward way to update it, and basically saying it could be done.
So, I was intrigued, but scared to make mistakes.

Having followed the further comments of Garlin yesterday and this morning, and realising I wanted to get this over and done with,
I ran Update_UEFI-CA2023.bin.ps1
That went without a hitch. It installed everything successfully.
win 11 told me under settings - privacy & settings - windows security - device security - secure boot:
secure boot is on and all required certificate updates have been applied.

The result from Check_UEFI-CA2023.ps1 - Verbose :

Windows 11 25H2 (26200.8457)

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
--------------
(NONE)
Windows BootMgr SVN is MISSING.
EFI_CERT_SHA256_GUID Signatures: 812

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.322, SVN 8.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.


REQUIRED ACTION
===============
To REVOKE the [PCA 2011] cert, run the commands:

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


Then I ran Check_DBXUpdate.bin.ps1, and it succeeded partially with this message:
SUCCESS: Matched 278/278 EFI signatures from "dbxupdate.bin"
FAILED: Missing 3/3 SVN signatures from "DBXUpdate2024.bin"
FAILED: Missing 3/3 SVN signatures from "DBXUpdateSVN.bin"
I am not sure what that means.

Anyway, the secure boot certificates 2023 are now on my HP Z440.

So: A BIG THANK YOU to Garlin for his scripts. And all his work to explain everything, so that it gave me enough confidence to get going.

Now my three machines are up to date (2 due to the scripts, and one automatically), and I am relieved it is behind me.

Capricornus said:

I would like to give some feedback on updating my older HP Z440 workstation:
I first had to remove the bios admin password by removing a jumper at position E49 on the mainboard. The manual says it is a blue jumper, but it looks green to me, especially when holding it up to natural light. That removal worked well. No more bios admin password.
Then, all I did was to set secure boot to ON. Any other settings I left alone.
On rebooting win 11 told me under settings - privacy & settings - windows security - device security - secure boot:
Secure boot is on, but there is a known issue. Secure Boot certificate updates are paused.....etc.

Click to expand...

When I warn users that some older PC's need manual assistance, I didn't expect someone to open up their box.
Great job on figuring out how to unlock the BIOS settings.

garlin said:

When I warn users that some older PC's need manual assistance, I didn't expect someone to open up their box.
Great job on figuring out how to unlock the BIOS settings.

Click to expand...

It shows how far we are willing to go to show you our gratitude for all your work !
Someone even "open up their box" to allow your script to do it's job !!!

I got one of my other HP laptops updated last night as well. A straightforward one but I'm seeing the pattern now. Did the latest Windows updates (it had been turned off for a few months before that), completely up to date. During installation of a security update, windows updates starts searching again (it's done this on all three), for maybe 30 seconds to a minute. But doesn't produce any other updates. Once all installed and rebooted, the Device Security check still shows it needs updating. An hour or so of restarting, and re-searching windows updates and turning on send diagnostics and give me the latest updates first etc - and still no change. Then as soon as I play chess for 20 minutes I find it's installed .

So clearly the update is in there but takes a long time to process in the background before it changes the device security settings. Either that or you need to play chess for 20 minutes to complete the installation. I have three more to go.

And I now find I have the new start menu and I don't like it at all. I had adapted to the old one by pinning what I needed and ignoring the app menu and I want it back how it was before - grrr.

Sometimes the Secure Boot task waits until a restart before applying the next round of changes, like replacing the boot manager. If you're installing the Monthly Update, the task can use the pending restart(s) to its advantage. Otherwise it may be appear "stuck", waiting for a future reboot so the changes will take effect.

MS could have done the updates all in one go (which my script does), but it has specific reasons why they didn't chose this option.

garlin said:

Sometimes the Secure Boot task waits until a restart before applying the next round of changes, like replacing the boot manager. If you're installing the Monthly Update, the task can use the pending restart(s) to its advantage. Otherwise it may be appear "stuck", waiting for a future reboot so the changes will take effect.

MS could have done the updates all in one go (which my script does), but it has specific reasons why they didn't chose this option.

Click to expand...

Do you know what those reasons are? Curious to know.

It's strictly for auditing purposes. Any script or tool can check the status of some UEFI variables, and the boot manager's version. However, that could have been secretly switched to something else in between when you last checked.

Booting in Secure Boot mode forces the CPU to write to a special set of CPU registers to record audit events. These registers, when dumped out on the live Windows system, provide a positive confirmation of whether Windows followed each of the Secure Boot steps exactly as designed.

Naturally that requires everything to be in place, before the audit begins. While my script can apply the same UEFI cert updates, and switch the boot manager, it can't force the audit since that only happens on the next reboot. My script is merely interested in pushing out the changes, but MS holds their own Secure Boot task to a higher standard.

MS has to satisfy all the enterprise clients' concerns that someone can't hijack the update process. Ultimately if you use my method, Windows do the expected auditing on the next restart. But the normal Windows process applies some updates, waits for a reboot for confirmation, then does another update, waits for a reboot, and finally does the last update, and waits for a reboot.

The MS method takes longer to arrive at the finish line. It's the user's choice on which method to follow. I prefer having users get immediate feedback that the updates worked (and they're done), or get an error message right away. Otherwise the MS method is pokey, and may take a while before revealing why the task is "stuck" waiting for help. By help, that means you and not Windows to clear the bottleneck.

Thank you.

Just did one more hp laptop. That one was a bit fiddly as it needed upgrading from 23H2, has an Optane drive and also needed a bios update. Disabled Optane to do the bios update. Waited a bit and it got the secure boot update after the bios update.

Garlin,
I ran the 5-14 version of Check_UEFI-CA2023.ps1 and saw this:
Secure Boot: ON
Virtualization Based Security: OFF
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 8.0
InvalidOperation: C:\SecureBoot-CA-2023-Updates 5-14-26\Check_UEFI-CA2023.ps1:1533
Line |
1533 | $EFI_Path = '{0}\EFI' -f (Get-HarddiskVolume $Matches[0])
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Cannot index into a null array.
Command cannot find any of the specified files.
PS C:\SecureBoot-CA-2023-Updates 5-14-26>

This only happens on this PC...
The 4-24 version shows success on this PC

Can you do me a favor, and run:
bcdedit /enum

garlin said:

Can you do me a favor, and run:
bcdedit /enum

Click to expand...

PS C:\SecureBoot-CA-2023-Updates 5-14-26> bcdedit /enum

Windows Boot Manager
--------------------
identifier {bootmgr}
device unknown
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
flightsigning Yes
default {current}
resumeobject {c9e37ee1-b681-11f0-a20e-60a44c601701}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 11
locale en-US
inherit {bootloadersettings}
recoverysequence {c9e37ee4-b681-11f0-a20e-60a44c601701}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
flightsigning Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {c9e37ee1-b681-11f0-a20e-60a44c601701}
nx OptIn
bootmenupolicy Standard
PS C:\SecureBoot-CA-2023-Updates 5-14-26>

Having updated my HP Z440 workstation, today I wanted to revoke the 2011 cert.
I ran
.\Update_UEFI-CA2023.ps1 -Revoke (running version 5-14)

But that fails with this error:
Error: failed to append "DBXUpdate2024.bin" to UEFI DBX

When I ran the same command on the one machine that got an automatic cert update, it installs all three .bin files successfully in the UEFI DBX.

Does the error maybe have to do with post 1385?

LeeElectrode said:

PS C:\SecureBoot-CA-2023-Updates 5-14-26> bcdedit /enum

Windows Boot Manager
--------------------
identifier {bootmgr}
device unknown

Click to expand...

You got a problem there.

"device" is supposed to be a disk device or assigned drive letter. The old method (2026.04.24) of locating the EFI isn't reliable on some Windows setups, so the new method is preferred. I would have to think if a fallback method should be allowed when "unknown" happens.

This command tells you where Windows thinks the boot manager lives:

Capricornus said:

Having updated my HP Z440 workstation, today I wanted to revoke the 2011 cert.
I ran
.\Update_UEFI-CA2023.ps1 -Revoke (running version 5-14)

But that fails with this error:
Error: failed to append "DBXUpdate2024.bin" to UEFI DBX

Is this still due to post #1385? And do we need to wait for an update of this bin?

Click to expand...

I have to run some tests. The update script was rewritten to understand both the "new" and "old" DBXUpdate2024 file.
But will have to reconfirm.

garlin said:

I have to run some tests. The update script was rewritten to understand both the "new" and "old" DBXUpdate2024 file.
But will have to reconfirm.

Click to expand...

Meanwhile I checked on my very old Lenovo C340 all-in-one with the UEFI from 2012, and there too the same command (version 2026-5-8 I believe) had run without problem. So, there seems to be a problem with this HP Z440.

Maybe your PC re-enabled that HP security feature that looks for "unauthorized" cert updates. HP Smart Start is a big selling point for a certain class of workstations.