Another simple question - i notice the relevance is only for systems with SecureBoot enabled.
- should it not be on all systems, so that future enablement will succeed?
Another simple question - i notice the relevance is only for systems with SecureBoot enabled.
As Windows 11 requires Secure Boot, the likelihood that itâs not already enabled on a computer that doesnât already require a LOT of attention is likely pretty low.
Ideally, I would think you would have a policy that is active and targeting devices with Secure Boot enabled so that if it does get enabled but isn't currently it would then get the policy and update the certificates as needed. I don't think these configurations not being there will ever prevent secure boot from being able to be enabled.
This is what Microsoft Documentation states regarding certificates that don't get renewed in time:
Devices that havenât received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.
Windows Secure Boot certificate expiration and CA updates - Microsoft Support
Is anyone encountering errors with the Bigfix secure boot process? Iâve tried it on a few lab computers with mixed results. The computersâ BIOS has been updated to the latest from HP that is supposed to support the secure boot change.
Bigfix Secure Boot fixlet Action 1 completes successfully. Action 2 shows each line completed both in the console and the client log, but the action status shows a failure.
Action 2 calls OS scheduled task "\Microsoft\Windows\PI\Secure-Boot-Update". Scheduled task history shows success as well. Action executed at 2:00:20pm.
There are no errors in the event logs. The only clue is from the analysis which shows â2147500037â for âUEFI CA 2023 Errorâ column. Google wasnât helpful. Anyone have any experience or suggestions?
Have the systems been rebooted?
Yes, theyâve been rebooted multiple times.
There is a potential issue with some vmware vmâs updating the KEK CA to 2023
The first command initiates the certificate and boot manager deployment on the device. The second command causes the task that processes the AvailableUpdates registry key to run right away. Normally the task runs every 12 hours. The registry key should quickly change to 0x4100. Rebooting and running task again will cause the boot manager to be updated and the AvailableUpdates to become 0x4000. See Troubleshooting for more details on the how AvailableUpdates behaves.
What is this returning?
values "UEFICA2023Status" of keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry
Microsoft says the âWindowsUEFICA2023Capableâ key isnât for general use, but in my analysis it pretty much line up 1:1 with the âUEFICA2023Statusâ key.
If âUEFICA2023Statusâ = âNot Startedâ then âWindowsUEFICA2023Capableâ = â0 - Windows UEFI CA 2023 certificate is not in the DBâ
If âUEFICA2023Statusâ = âIn Progressâ then âWindowsUEFICA2023Capableâ = â1 - Windows UEFI CA 2023 certificate is in the DBâ
If âUEFICA2023Statusâ = âIn Progressâ then âWindowsUEFICA2023Capableâ = â2 - Windows UEFI CA 2023 certificate is in the DB and the system is starting from the 2023 signed boot managerâ
This is my analysis.
if (exists value "WindowsUEFICA2023Capable" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry) then (if (it = "0") then "0 - Windows UEFI CA 2023 certificate is not in the DB" else if (it = "1") then "1 - Windows UEFI CA 2023 certificate is in the DB" else if (it = "2") then "2 - Windows UEFI CA 2023 certificate is in the DB and the system is starting from the 2023 signed boot manager" else "Unexpected Value: " & it) of (value "WindowsUEFICA2023Capable" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry as string) else "Key Missing"
Microsoft Reference
WindowsUEFICA2023Capable
REG_DWORD (code)
This registry key is intended for limited deployment scenarios and is not recommended for general use. For most cases, use the UEFICA2023Status registry key instead.
Valid values:
0 â or key does not exist - âWindows UEFI CA 2023â certificate is not in the DB
1 - âWindows UEFI CA 2023â certificate is in the DB
2 - âWindows UEFI CA 2023â certificate is in the DB and the system is starting from the 2023 signed boot manager âââââââ
This is the output of the query and analysis that youâre recommending from my problem lab computer.
q: values "UEFICA2023Status" of keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry
A: InProgress
T: 0.401 ms
I: plural registry key value
q: if (exists value "WindowsUEFICA2023Capable" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry) then (if (it = "0") then "0 - Windows UEFI CA 2023 certificate is not in the DB" else if (it = "1") then "1 - Windows UEFI CA 2023 certificate is in the DB" else if (it = "2") then "2 - Windows UEFI CA 2023 certificate is in the DB and the system is starting from the 2023 signed boot manager" else "Unexpected Value: " & it) of (value "WindowsUEFICA2023Capable" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry as string) else "Key Missing"
A: 0 - Windows UEFI CA 2023 certificate is not in the DB
T: 0.274 ms
I: singular string
This is a view of the registry of that computer as well.
The UEFICA2023Status of âin Progressâ should mean that the 2023 cert is in the DB, but the analysis results say the opposite.
I have Vmware Virtual machines that are showing InProgress but have Platform key issues on the vcenter side that we are trying to address. It might help to look at the event logs to see if there is any valuable information in there. try to run this relevance query and see what events come back.
(Source of it, time generated of it, event id of it, description of it) of (records whose ((event id of it is contained by set of (1032;1033;1034;1035;1036;1037;1043;1044;1045;1795;1796;1797;1798;1799;1800;1801;1802;1803;1808)) and source of it = "Microsoft-Windows-TPM-WMI" and now - time generated of it < 7*day) of system event log)
Following up to my posts in early March to share my experience in hopes that it benefits someone.
On some computer models that we have, following the default advice and fixlet that HCL provides has worked fine. However, we have a large set of computers where we had gotten incomplete results (see my prior posts in this thread). This was even after upgrading the BIOS to the latest version that is specifically designed to support Secure Boot. I worked with HPâs upper tier of support to find a solution. In my specific case for HP Engage One Pro model registers, I created a baseline that: 1) disables BIOS password ahead of Secure Boot updates using the HP BIOS configuration tool 2) run HCLâs secure boot fixlet 3) use HPâs BIOS configuration tool to specifically toggle some of the secure boot settings 4) reboot up to five times (for some models) and 5) reenable BIOS password at the end of the process using HPâs BIOS configuration tool.
Itâs a bit ugly and takes about an hour to run with all the reboots, but it does work.
This is the HP BIOS config that we used.
createfile until EOF
BIOSConfig 1.0
;
; Originally created by BIOS Configuration Utility
; Version: 4.0.32.1
; Date="2026/03/12" Time="11:10:42" UTC="-4"
;
Windows UEFI CA 2023
Disable
*Enable
Microsoft Option ROM UEFI CA 2023
Disable
*Enable
Microsoft UEFI CA 2023
Disable
*Enable
Ready to disable MS UEFI CA Key
*Not Ready
Ready
EOF