Event details
219 Comments
Can you please clarify what does 'Not applicable' means for the certificate status in the Intune report - Reports>Windows quality updates>Reports>Secure Boot Status>Certificate status and if any action is needed for these?
- Jason_Sandys
Microsoft
Hi Sunila Chugh, This is generally due to one of two things:
- The device hasn't reported in yet.
- The device isn't configured to share diagnostic data.
The documentation at https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/monitor/secure-boot-status-report#data-freshness-reporting-latency-and-diagnostic-data-requirements has more details on this.
Using PowerShell, this is how we're detecting if the devices have updated their Secure Boot certificates. Is this valid code? Is there better code we should be using?
# Detect if 2023 KEK certificate is installed
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
# Detect if 2023 DB (Windows) certificate is installed
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
# Detect if 2023 DB (Third Party) certificates are installed
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Option ROM UEFI CA 2023'
# Detect if boot files are signed by 2023 certificate
$efiPartition = Get-Partition | Where-Object {$_.GptType -eq "{C12A7328-F81F-11D2-BA4B-00A0C93EC93B}"}
Add-PartitionAccessPath -DiskNumber $efiPartition.DiskNumber -PartitionNumber $efiPartition.PartitionNumber -AccessPath "S:"
$efiBootmgfw = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
$efiBootmgfw.Import("S:\EFI\Microsoft\Boot\bootmgfw.efi", $null, 'DefaultKeySet')
($efiBootmgfw | ? {$_.Subject -eq 'CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US'}) -ne $null
Remove-PartitionAccessPath -DiskNumber $efiPartition.DiskNumber -PartitionNumber $efiPartition.PartitionNumber -AccessPath "S:"
- Jason_Sandys
Hi Bryant_Kintner, Our sample script for this task is published at Sample Secure Boot Inventory Data Collection script - Microsoft Support. We recommend using this as an example to use or start from being careful to test and validate in your environment (and with the caveats listed in the scripts NOTES section). Be sure to sign the script with your own signing cert as well.
If my device doesn't have UEFICA2023 cert and can no longer PXE, what would be the process to update that machine if the device is not bootable.
Have your PXE server push securebootrecovery.efi as the boot binary for just that device (e.g. by mac address).
Otherwise I am unsure what you mean by "device is not bootable". Anything signed with the old 2011 cert will still boot fine. So put securebootrecovery.efi on a bootable device and boot from it. Done.
What impact will the TLS lifetime decreasing to 47 days have on these secure boot certificates? Will these certificates eventually need to be replaced every 47 days?
https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days- Jason_Sandys
Hi mataylor,
These certificates are not TLS certificates and are not used for TLS and thus unrelated to this guidance from DigiCert.
My understanding is that all the UEFI certificate/keying is not subject to CA/Browser Forum baseline requirements. Heck, "expiration" seems to be more a suggestion from my understanding of these certificates, especially the PKs which come from the OEMs.
Currently there's only a GPO (ADMX) to do the update of the certificates. Are you also working on a GPO (ADMX) for the "revocation" (dbx) of the 2011 certificates?
- Jason_Sandys
Hi ClientAdmin,
Not at this time no as we have no plans on adding these certs to DBX since they are needed to validate existing boot critical components signed by these certs. Adding these certs to DBX now would completely break Windows unless we intended to update and re-sign all boot critical components with the new certs but we have no plans on doing this since there is no value in doing this.
- Jason_Sandys
Quick follow-up caveat here: revoking the PCA cert (by adding it to DBX) is something we are recommending in the long run. This is the cert used to sign the boot loader (and only the boot loader) as there is an attack vector here as was exploited some past attack(s). To be clear, this is only for the PCA cert and does not materially change my answer above.
We are having some issues getting the new certs installed on our VM guests. Our ESXI is patched to newest level but our hosts are showing the following error:
The Secure Boot update failed to update KEK 2023 with error Invalid access to memory location
What version of ESXi are you running?
there’s a article from Broadcom that you need to power down the vm and rename/remove NVRAM en then boot vm again. After that you will see this error disappear. Here’s the article :
https://knowledge.broadcom.com/external/article/415333/error-unable-to-upgrade-a-vm-due-to-boot.html
We are on ESXI 8.0.3
I update the servers to the point where I see the following Reg entries..
- Both Active and Default DBs show both 2023 and 2011.
- AvailableUpdates show 0x00004000
- WindowsUEFICA2023Capable registry key was set to 2
- UEFICA2023Status registry key shows “Updated”
- For Server OS I see the following:
- Server 2019/2022 I see Event ID 1808 in system log
- Server 2025 I see event 1799 in system log
Both events say that the UEFI CA 2023 was installed successfully….so does that mean the system is up to date?
However, if we run the command below, I get the return code “00” …is that a problem???
- $pk = Get-SecureBootUEFI -Name PK
- $bytes = $pk.Bytes
- $cert = $bytes[44..($bytes.Length-1)]
- [IO.File]::WriteAllBytes("PK.der", $cert)
- certutil -dump PK.der
You can view PK and KEK certificates, as well as DB and DBX certificates and hashes, using my PowerShell script Get-UEFICertificate PowerShell script. You can install it from the PowerShell gallery here.
Install-Script -Name Get-UEFICertificate -Scope CurrentUser
GitHub: https://github.com/richardhicks/uefi.
Not sure why you are trying to manually extract a certificate from the PK variable with some magic offsets. I don't know if that will work every time.
But you are lucky, March updates, Get-SecureBootUEFI learned a new -decoded switch which can decode the PK for you.
Follow up on earlier SCCM boot.wim questions:
Can we continue using the boot.wim with 2011 cert past June 2026?
Will that work successfully with devices that only have 2011 cert?
Will devices that have 2023 cert already require a boot.wim that has 2023 cert once June 2026 has passed?
(We have thousands of devices in storage, and need to know sooner, rather than later, if they need to get updated pre-June 2026)- Jason_Sandys
Nothing changes instantly in June or when the certs expire. The boot critical components signed by these certs are still trusted and valid and devices will continue to boot fine as the certs themselves are still "trusted".
Answers
- Yes, the old certs are still trusted as noted.
- Yes, same reason.
- No, device will trust both old and new certs.
Note that a better path though is to begin your Intune and Autopilot journey.
- Pearl-Angeles
Community Manager
Your 3rd question was addressed at 49:00 during the live AMA.
I manually updated the registry on a device, set it to 22852, and forced the Scheduled Task to start, waited 30 seconds and forced a reboot, and the server (server 2019 VM in hyperv with the latest march patches) and it restarted several more times on its own before it settled down and showed updated. Not sure if several reboots are going to be required every time, of if me forcing things my running the scheduled task had this effect.
Oke so we’re pretty much trying to get it in control. So I am wondering the PK (platform key) isn’t present in our hypervisor version at this moment. What does this mean for the whole chain?
cause we have a well guided plan aligned with Microsoft their approval. But after running the workflow 0x5944 , en you go to 0x4100 and after a while you get the 0x4000. This means the flow is done. After this you have the remaining 0x280 (revocation of PCA2011 , and applying SVN). After this you are done.
reading the march update there is this line:
KB5079473
Secure Boot] With this update, Windows quality updates include additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Devices receive the new certificates only after demonstrating sufficient successful update signals, maintaining a controlled and phased rollout.
could you tell us more about this? - my guess is that you need telmetry on to have this nice feature/support?
You need somebody else with your exact hardware configuration (bucket id) to have telemetry on. The HighConfidenceBuckets cab file is included in the update, so all devices that have same bucket ID will receive the update, even if that individual device has telemetry off or is not even connected to the Internet.
