Any thoughts on the different secure boot certificates?

Posted by sccmjd@reddit | sysadmin | View on Reddit | 7 comments

I'm looking this.

https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e

And discussing it with AI but that's AI.

These are critical and should be on all machines?

Windows UEFI CA 2023

Microsoft Corporation KEK 2K CA 2023

And then these other two, also in db like Windows UEFI CA 2023, are optional and only there if Microsoft thinks they need to be?

Microsoft Option ROM UEFI CA 2023

Microsoft UEFI CA 2023 (which is different than WINDOWS uefi ca 2023)

I see this one -- Microsoft Windows Production PCA 2011 -- has an expiration (or "milestone" date since apparently it's not actually a "deadline") of October 2026. I read there was something more with secure boot certs in October. This is the only official mention of October I've seen. And it gets replaced with the most important Windows UEFI CA 2023 so that's already fixing things for the June milestone date.

It looks like these two are critical and must be there -- Windows UEFI CA 2023 and Microsoft Corporation KEK 2K CA 2023 -- while Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 might be there if Microsoft determines they should be, but those aren't critical. Is that correct?

[-]

itskdog@reddit

Option ROM is for UEFI Option ROMs, the Microsoft (as opposed to Windows) one is for Linux and other 3rd-party OSes.

But I'll agree with u/TerrorToadx, just set the GPO and let Microsoft decide which ones you need.

[-]

Amomynou5@reddit

just set the GPO and let Microsoft decide which ones you need.

This is assuming you've got telemetry enabled and you're reporting your data back to MS. A lot of enterprises block telemetry for privacy/data sovereignty reasons, so the automatic rollout doesn't work.

Also, you may still need to do a lot of manual work anyways, such as:

Updating the BIOS/firmware for your entire tech stack
Sometimes BIOS/firmware updates aren't enough - eg with VMWare you may need to delete the .nvram file, upgrade the virtual HW level + VMTools, maybe even upgrade ESXi itself if you're on an old version. And some HP workstations may not support the new certs even though HP claims its supported (like the EliteBook G4s), and for these you'll need to manually contact HP and get a powershell script from them to update the certs. Other workstations that haven't received an updated BIOS from the OEM may never even be supported. So you'll first need to inventory your entire fleet and see what is/isn't supported, then make a call on what to do with the unsupported models. Like in our case, about 1/3rd of our fleet doesn't support the new certs so we're in a bit of a pickle, because the current hardware pricing situation means we aren't at a liberty to just buy new models ASAP.
You'll also need to update anything that boots basically. Like SCCM Task Sequences, WinPE Images, ISOs, USB drives, VM templates (OVA/OVF etc), backup/recovery media and so on.

So it's a lot of work depending on how big and complex the tech stack at your org is, and isn't often as simple as "set the GPO and forget it".

cc: u/sccmjd

jamesaepp@reddit

Everything is contextual, but here's my breakdown for you.

Nothing is "critical". Nothing stops booting later this month even with expired certificates. It's the new stuff (new bootloaders, new revocations) that won't work anymore.

Assuming you're booting Windows operating systems, this is my order of importance, most to lowest:

Windows UEFI CA 2023. This is the CA that signs new Windows bootloaders. Without this, you can still install LCUs, but the LCU may be unable to install the newest bootloader because it wouldn't be trusted by secure boot.
KEK 2K CA 2023. This is the key that replaces the function of the 2011 KEK. Want to know how malicious bootloaders are revoked/added to the blocklist? Today, the 2011 KEK signs a revocation list/capsule update, and your machine verifies the signature based on the 2011 KEK cert. The 2023 cert replaces that function.
Microsoft UEFI CA 2023. This is the CA that signs third party stuff like the shim bootloader for tons of Linux distros and stuff that isn't Windows but is still signed by Microsoft. If you aren't regularly booting to non-Windows operating systems, don't worry about this one.
Microsoft Option ROM UEFI CA 2023. Similar to the above, but for boot loaders that are on add-in cards on computers. For example, if you boot to a network card that has iPXE flashed to it as an OpROM, that OpROM (could/should) be signed by this CA.

TerrorToadx@reddit

You are overthinking this. Set your AvailableUpdates regedit value to 0x5944 and be done with it. There is also a GPO for this.

I disagree with the overthinking angle.

If it's so straightforward, why doesn't MSFT automate the registry value themselves to 0x5944? Why even have the registry value at all?

Why is MSFT not doing CFR/high confidence evaluations for server SKUs?

Because it does require thought put into it. OP is essentially asking about what they need to do. I'd argue MSFT has done a poor job of communicating "MUST" from "SHOULD" from "RECOMMENDED" from "MAY".

smonty@reddit

But also more involved if you want an updated 2 regkeys result and you’re running a VMware stack.