For anyone that comes across this and is interested it looks like HCL also posted this knowledge article regarding the Secure Boot updates.
BigFix Support for Windows Secure Boot Certificate Updates
2 Likes
I'm hoping to have more information about this Monday but i'm curious if anyone has started tackling this on vmware virtual machines. Windows Physical machines with Secure Boot seem to work pretty well updating the Secure boot certificates with just the registry keys and scheduled task we've discussed previously, but vmware virtual's appear to have 2 different potential issues that prevent secure boot certificates from updating.
I will be posting something about this in the next couple of days but i'm curious if anyone has already been looking at this side of it.
Scenario One: Hardware compatibility issues
“The Secure Boot update failed to update KEK 2023 with error Invalid access to memory location.”
Scenario 2: Platform Key (PK) or KEK Certificate Not Applied
Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware.
2 Likes
@jstev Rollout on physical machines hasn’t been an issue once I switch the registry keys to begin the deployment. Like you I have also ran into issues when attempting to update the secure boot certs on vmware servers. Not sure what the deal is and how to tackle those. I am also researching the issue to figure out what steps need to be done for those. Curious to know if others have been succesfull updating vmware virtual servers.
Just want to confirm, a BIOS update may need to be performed prior to running these? Microsoft is recommending BIOS updates, hardware vendors are recommending it, etc. At my company, resources are being allocated towards proving a BIOS update is not required as we have a culture of fearing BIOS updates. I'm attempting to advocate that a BIOS update WILL be required for many of our computers on older BIOS versions. Based on the Secure Boot probe task, I was even able to confirm which BIOS versions needed to be updated. Is anyone able to confirm this?
I have 15k computers I have to update to the new 2023 cert. In preparation for this I updated the BIOS on all computers and had no issues. If the BIOS version is several years old, it may not even recognize the new 2023 cert. You can take a few of the models and search the SN on the manufacturer site and look at the latest BIOS update details. You can always test on a few and see how it goes.
2 Likes
If the registry info is to be trusted it does not seem that I’ve needed to do any BIOS updates against the Dell systems I’ve been testing against.
Set registry key for “Deploy all needed certificates and update to the PCA2023 signed boot manager” and they have been returning “2 - “Windows UEFI CA 2023” certificate is in the DB and the system is starting from the 2023 signed boot manager”
Registry key updates for Secure Boot: Windows devices with IT-managed updates - Microsoft Support
Curious what other’s experience has been in this regard…
I’ve only done this in a home lab (earlier this year), but an older laptop did require a BIOS update but a few laptops went through just fine. My issue right now is vmware vms, like another person here, and I don’t have a solution yet (though have not spent more than a hour or so total, so will be circling back at some point).
Is there a reason that there is no task to validate the cert is needed to start with and set an attribute to avoid the reboot sequences, etc.
if powershell can report True/False for active and db presence - why not load a parameter and report on it and base the rest on those vs the randon ms reg settings which in my case are useless as i believe we updated most systems before the cumulative update which pushed those settings out.
Just a question
The fixlets have relevance. The main requirement is the endpoint is booting UEFI. Legacy BIOS boot is not impacted.
Secondly the Analysis/registry clearly show if the device is impacted or not.
It does seems overly complicated/confusing at first, but if you read through MS documentation and perform some manual updates, it becomes quite clear. MS offers several options, BigFix is using the basic registry method, which is what I used in my home lab to understand what’s going on.
Possible, the analysis should help you determine that.
We had the same concern but with the upgrade from Win10 to Win11 due to Win10 going end of life, addressed most systems anyway. The hardware that is required to support Win11, covers most of the requirements that this certificate has.
We are taking our time and making sure all is well. We have nearly 30k systems that we manage, it is going to take some time.
I have to praise HCL. We requested HCL developed this content in November. They had the beta versions of the content to us in mid December. They did good.
1 Like
The analysis has that data.
Ok so this is one of my test boxes - and the latest analysis:
- Win2019
The powershell validation:
PS C:\Windows\system32> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
True
PS C:\Windows\system32> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
True
The latest fixlet 506820201 still reports as relevant because the registry values and settings didnt exist more than 6 months ago when i updated many of my systems.
Best i can see the values in the registry for Status and Error are ONLY set after the cummulative update in Nov/Dec was installed and IF the updates were done after that time. If the updates were executed prior the registry does not report status correctly, and the relevance and analysis are misleading or valid completely.
Just want to make sure I understand. You are saying that systems that had the certificate updated prior to Nov/Dec do not have the reg keys indicating they have the new cert?
From what I understand, MS did not include the cert in the cumulative patches until Jan 2026.
Correct.
MS has had published process and procedure many months ago, HCL even had a first and second pass at a task to probe and attempt at updating.
MS goes back to 5/2023, and has updated doc twice a year since.
Went back and found the report KB5034770 in Feb 13, 2024 added the cert as available. It did not load it as active.
Can you point me to the PS script that detects if it is installed?
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
The first one will check the active database, the second one will check the default database.
out of curiousity if you run this relevance query on that vmware machine what event logs come up for it?
There are two error's that i've seen so far with vmware virtual machines that i'm working on formally documenting. One requires updating the hardware compatibility and one of them requires updating the Platform key. Broadcom has documented the process of it but it's a pain. If the event id is 1796 it's hardware compatibility and if it's 1801 the issue is either with the KEK cert or the Platform key.
(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 < 7day) of system event log)*
Also, for folks who may not have seen the “Ask Microsoft Anything” session from last month here is the link.
2 Likes
The BigFix team has also published the details of our solution at Content Release: Support for Microsoft Windows Secure Boot Certificate Updates in case any of you have not yet seen it.
3 Likes