Category Archives: Secure Boot

Checking Boot/Recovery Media CA-2023 Status

Here’s an interesting consequence of the switchover in the Secure Boot chain of trust from CA-2011 to CA-2023. Once that occurs, you can’t boot from install, repair and recovery media that doesn’t support CA-2023. The PC firmware will reject it as “non-compliant.” What that means is with the revocation of CA-2011 upcoming in June, it’s time to start checking boot/recovery media CA-2023 status. When you can, it’s also time to replace older non-compliant media with newer, compliant versions.

I had Copilot write me a PowerShell Script that did 3 key things:
1. It checked to make sure drive G: (default letter for my UFDs) was present and accounted for
2. It showed me the top-level directory so I could see what I was dealing with (handy to distinguish installers, repair tools, etc.)
3. If it found EFI files, it reported Yes/No on their CA-2023 compliance.

After Checking Boot/Recovery Media CA-2023 Status, Then…?

The TL;DR answer to this question is: replace it if needed, keep it otherwise. I also used this opportunity to label my UFDs so I would know what I had in the future. I found all kinds of interesting stuff, including:

  • An MSI flash drive for my “new” MAG Tomahawk B550 mobo, a UEFI updater for v 2.90 on the ASRock B550 Extreme4+
  • Multiple Macrium Reflect and Hasleo Backup Suite rescue UFDs
  • A copy of the Windows DaRT (Diagostics and Recovery Toolset)
  • Multiple Windows Installer UFDs, mostly via MCT, some from UUPDump

Here’s the interesting thing: NONE of these items is CA-2023 compliant. Copilot says, in fact, that MS has not yet released an installer or repair ISO that includes the CA-2023 boot files in the EFI partition (see lead-in graphic bottom portion). I’d planned to update my dozen or so bootable UFDs today if I could. Looks like I’ll be waiting a while…

Key Takeaway

If you revoke CA-2011 support on any or all of your Windows PCs, you put yourself in the position of having to go into UEFI and turn off Secure Boot sometimes. When might that be? Whenever you want or need to use media to boot that PC for repair, recovery or installation. Good to know! That’s not the kind of thing I’d like sprung on me as a total surprise. Bet you feel the same way, too…

Facebooklinkedin
Facebooklinkedin

Pondering UEFI Updates

I’m still getting settled in with my new production desktop environment. ICYDK, it’s built around an MSI MAG Tomahawk B550 mobo, with Ryzen 5800X, NVIDIA 3070Ti GPU, and 64GB DDR4 RAM. This morning, I started digging into the MSI Center app that orchestrates other system utilities, and handles updates for drivers and firmware. In my investigation, I discovered a “new” update for the mobo firmware. In turn, that has me pondering UEFI updates.

Where Does Pondering UEFI Updates Take Me?

I had to figure out that MSI’s once-standalone “Live Update” utility now sits beneath its top-level Support tab (top middle of option bar in the lead-in graphic). Then I had to figure out that UEFI updates appear only when one clicks the “Advanced” button, rather than the more pedestrian “Scan” button (which scans only for driver updates).

As  you can see in that graphic, the company shares its guidance in eye-catching red text at the head of the MB BIOS list. That guidance reads: “MSI does not recommend to update BIOS when system has no issue” in somewhat fractured English. However rough the wording might be, the guidance is still pretty good. Let me explain…

If It Ain’t Broke, Don’t Fix It!

The reason why I recently rebuilt my Flo6 desktop stemmed from UEFI problems with the previous ASRock B550 Extreme4 mobo. It kept sticking halfway between Secure Boot old/updated data sets. That resulted in extreme boot requirements, when I might sometimes have to reset CMOS just to get the PC to boot.

Most of the time I had to shut it down, and cut power, then wait a while to bring it back to life. That went on for weeks before I made the switch to the MSI board. Since then, boot and update operations have been blissfully boring. Things just work, and I can use all of the various boot options and related keyboard options to do exactly what I want.

Reading over Copilot’s summary of what UEFI v2.A0 brings me, as compared to the running v2.90, I don’t see anything I need. Nor do I see anything that would improve Flo6’s currently rock-solid and dependable, fully caught-up Secure Boot Status.

Hence my decision: I’m not going to update. Nothing is causing problems. Everything is working dependably and reliably. Secure Boot is golden. This time, I’ll pass… Maybe next time?

Facebooklinkedin
Facebooklinkedin

Windows Security Checks Secure Boot

I just read at WindowsLatest that the Windows Security app now includes a Secure Boot check beneath its Device Security left-column head. I checked all of the PCs in my office to make sure (7 of them). Sure enough. each now lists Secure boot amidst its elements. As the aforelinked story shows, when Windows Secure checks Secure Boot status it uses one of three visual symbols as quick indicators:

  • Green checkmark indicates Secure Boot is basically OK. There’s more going on here than meets the eye, as I’ll explain later.
  • Yellow exclamation (warning) indicates Secure Boot is running but the latest certificate (CA-2023) is not yet in place or use.
  • Red X (stop sign, error/problem) indicates the device cannot receive required updates to keep the Windows boot process secure.

Why Windows Security Checks Secure Boot Now

Microsoft added this new entry because Secure Boot certificates from 2011 are expiring in 2026. Thus, Windows needs a user‑visible way to show if a device has received the updated 2023 certificates. Up to now, Secure Boot status was invisible unless users dug into UEFI or used PowerShell.

But with certificates — CA-2011, specifically –expiring, Microsoft now needs some way to:

  • Tell users whether their system is still protected
  • Indicate whether the new certificates have been applied
  • Warn users if action is required (firmware update, OEM tool, etc.)
  • Provide a simple green/yellow/red indicator instead of forcing people to inspect UEFI variables

That makes the new Secure Boot section in Windows Security  essentially an approachable, easy-to-grasp health dashboard for the certificate update.

It’s Not as Easy as It Looks?

The WindowsLatest story shows the same green checkmark text as the lead-in graphic for this story. But when I checked a couple of my other machines, I saw something different. Here ’tis:

Note the difference in the text output here. Even though both forms proffer the green checkmark to denote Status=OK, the first one reads “Secure Boot is on and all required certificate updates have been applied. No further certificate changes are needed (bold emphasis mine).” However, the second one simply says “Secure boot is on, preventing malicious software from loading when your device starts up.”

The second doesn’t say “No further certificate changes are needed.” At first, I thought the difference might be that on some PCs the CA-2011 certificate had already been revoked (all OK PCs must have the CA-2023 cert installed, in use, and recognized in the boot loader to qualify for that status). But on one PC with the simpler message, the CA-2011 certificate shows revoked (it’s in the UEFI DBX Certs database, which means it’s blocked). And on the other PCs with the “no further” language the CA-2011 certs are still enrolled (they’re in the UEFI KEK and UEFI DB databases, and NOT in the UEFI DBX database).

So I’m still wondering exactly what’s going on here, and what MS is trying to tell us with these two different OK messages. I’ll keep digging and write more when I find or figure out what’s going on. A sense of mystery, and a willingness to suspend resolution pending necessary information, are familiar sensations in Windows-World. The plot thickens…but I hope, not too much!

Added 1 Hr Later: Word from the Top

I corresponded with Garlin himself on ElevenForum, and at his suggestion, ran his update_UEFI-CA2023. script on the P16G3. That brought all the DB certs into the UEFI DB (including Option ROM and Windows UEFI). It still shows VBS policy as missing. But it turns out that by running .\Update_UEFI-CA2023 -SkuSiPolicy and rebooting, I can take care of that. Here goes … another reboot. Now the Garlin check script gives the P16G3 a completely clean bill of health, but I still get the short message. Very interesting!

 

 

Facebooklinkedin
Facebooklinkedin