Event details
I was able to add the same AUTH files (containing the 2023 certs) to the z840 without much issue (had to use KeyTool.efi though).
Unfortunately, I receive 1802 errors ("The Secure Boot update Option ROM CA 2023 (DB) was blocked due to a known firmware issue on the device."). I assume that is just related to the z840 and other machines of that era no longer receiving BIOS updates (stuck with old DB/KEK/PK) and therefore being blacklisted, as noted here:
https://support.microsoft.com/en-us/topic/understanding-secure-boot-events-1802-and-1803-29a045f3-54bd-464b-bd16-d5989f82885d
"KI_7, KI_8, KI_9: HP Firmware
This HP device has a known compatibility problem during Secure Boot updates."
Arden_White - will it be possible to force-bypass this blacklisting on these devices through a registry edit, or similar?
Regardless, I did get event 1034 (Secure Boot Dbx update applied successfully), so I'm wondering if even if MS does not allow me to force the update process to go any further, will I at least continue to get DBX updates (even after the 2011 certs expire) on this machine, or am I only receiving them now because the 2011 certs are still valid?
MicrosoftHere’s how I’m understanding your observations. Please correct me if this is off:
- You were able to apply AUTH files containing Microsoft Corporation KEK 2K CA 2023 and Windows UEFI CA 2023.
- The 1802 error appears specific to the Option ROM CA 2023 (DB) update.
- DBX updates appear to be applying successfully.
If that summary is accurate, then based on current behavior:
- Since the device now trusts KEK 2023, it appears able to continue accepting DBX updates.
- Since the device trusts Windows PCA 2023, it appears able to continue receiving Windows boot manager updates.
- Option ROMs signed with Option ROM CA 2023 do not appear to be trusted on this platform. For a system that is not changing hardware, this seems unlikely to be impactful.
- Force‑bypassing the 1802 block is not supported, as the block is enforced due to known firmware limitations.
Given the age of the platform and the lack of ongoing firmware updates, this behavior aligns with what we would generally expect to see on older workstation‑class systems, but it should still be considered outside the fully supported Secure Boot update path. Good luck to you.
Here is what I get when pulling the DB/KEK with Get-SecureBootUEFI:
DB:
Subject: CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Not After: 10/19/2026 1:51:42 PM
Subject: CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Not After: 6/27/2026 4:32:45 PM
Subject: CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
Not After: 6/13/2035 2:08:29 PM
Subject: CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
Not After: 6/13/2038 2:31:47 PM
Subject: CN=My Custom DB
Not After: 3/15/2036 7:52:49 PM
KEK:
Subject: CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Not After: 6/24/2026 3:51:29 PM
Subject: CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
Not After: 3/2/2038 2:31:35 PM
Subject: CN=My Custom KEK
Not After: 3/15/2036 7:51:17 PM
- Arden_White
My take is the device currently trusts the Microsoft UEFI CA 2011 certificate and the update process is trying to apply both the Microsoft UEFI CA 2023 and the Microsoft Option ROM UEFI CA 2023. These two new certificates are the replacement for the old one. Trying to update both is expected. The Microsoft UEFI CA 2023 will be used to sign 3rd party software that has a firmware component that needs to be trusted. It could be disk encryption, EFI utilities, Lunix boot loaders, etc.
We don't test a scenario like this, so I can't say for sure, but it seems like it should.
Note that we have not signed any DBX updates with the new Microsoft Corporation KEK 2K CA 2023. Any DBX updates that were recently applied would have been signed with the Microsoft Corporation KEK CA 2011. That means this bullet in the previous response was making an incorrect assumption.- Since the device now trusts KEK 2023, it appears able to continue accepting DBX updates.
If you dump the DB and the KEK on these machines and see the new certificates, that seems like a good sign.
Yes, thank you, that's all correct, except that I should add that I did try removing the Option ROM CA 2023 cert from the AUTH files, and then I wound up getting the 1802 error for a different cert (might have been Microsoft UEFI CA 2023, but I don't recall).
I received one DBX update (event 1034) after applying the new AUTH files with the 2023 certs.
It's your belief, then, that this machine will continue to receive DBX updates post-2011-cert expiration? I would think the DBX update component is the most critical from a security standpoint... but I could be wrong.