Solved garlin's PowerShell scripts for updating Secure Boot CA 2023

In my Google searches I've read many times "soft brick" or similar terms. This means the affected computer does the POST (depending, it properly signals it to the user with a beep/similar or not), but it detects corrupted legacy BIOS settings or not (afterwards I'll explore the corrupted certs possibility), in the former case it's like a driver seeing that he/she is in a dead end, although the car and he/she are healthy (a person can always find a solution, an automatic system it depends), in the latter case "the car" crashes against a wall or anything and the system crashes, minimum a reboot would be required but only a reboot wouldn't be enough in general.

Legacy BIOS settings: SATA ports in IDE/AHCI/RAID, processor/RAM voltage/frequency modes/multipliers (this part can be very dense in data: I've counted about 30-40 user settings in one's manual and not all combinations are possible), onboard sound and other peripherals enabled/disabled,... Corruption here is what most clearly can impede the bootup. In all non UEFI boards I've had the chance to know, visiting the BIOS (that sometimes is automatic) or clearing the CMOS fixes the issue. I've never had the chance to know about any UEFI board.

We're speaking about NVRAM and CMOS, but are they always separated? Is there any "mechanical" characteristic that makes it impossible to use the same store for the CMOS settings and for the certs? Possible one: the CMOS settings live in fixed memory positions, the certs are more like files (with different lengths) and even folders in a "disk" (for fulfilling the "not in DBX" part you don't go to the "KEKs folder"). I'm not meaning there's a "filesystem": this is memory, it's fast and rewriting everything again is possible, although I don't like it because of the intermediate store problem, system RAM isn't reliable enough for my taste and a second store only for this... let it alone if Windows is constantly appending/deleting small items. Maybe it's inevitable anyway depending on the use mechanics of this database. Is there an "absolutely maximum length" for a cert?

Now let's suppose everything in the 2nd paragraph is okay. The very first operation afterwards could be some check in the certs/UEFI variables... even if the computer is set in legacy BIOS? (oldest computers might have a "pure legacy BIOS" mode, CSM is theoretically a part of UEFI although there're probably as many different CSM modes as models). Whatever, any check (let it alone if it's more than a check) of corrupted data can cause a hang, or should it rather cause a SB violation??? This is important b/c a "NVRAM corruption issue" can be seen as an attack. If the user data can be retrieved (it's backed up or the disk can be attached to other computer, not for example in my miniPC that as disk has an "eMMC" soldered to the board), maybe it's preferable to brick the computer (half kidding, half not).

Legacy BIOS or CSM or Secure Boot not capable aren't compatible with Windows 11 so in theory this problem doesn't exist lol. Windows 10 still exists though (and ESU has been extended one year more).

garlin said:

Basically if you don't update the Secure Boot certs, W11 will continue to work. But you won't have the Secure Boot protections (which aren't just the replaced boot manager).

Click to expand...

I admit to being confused by this.

You seem to be saying that Secure Boot protections will cease without the current 2023 certificate update. I was under the impression that Secure Boot protections will continue to function but the device will stop receiving updates to key components: Windows Boot Manager; Secure Boot databases (DB); Revocation lists (DBX), Early‑boot vulnerability fixes (e.g., bootkit mitigations). If such updates are frequent then clearly Secure Boot protections will soon become ineffective.

Is that correct and going on past events (all we have at present) how common are such updates?

misar said:

I admit to being confused by this.

You seem to be saying that Secure Boot protections will cease without the current 2023 certificate update. I was under the impression that Secure Boot protections will continue to function but the device will stop receiving updates to key components: Windows Boot Manager; Secure Boot databases (DB); Revocation lists (DBX), Early‑boot vulnerability fixes (e.g., bootkit mitigations). If such updates are frequent then clearly Secure Boot protections will soon become ineffective.

Is that correct and going on past events (all we have at present) how common are such updates?

Click to expand...

What Garlin ment is that gradually the different aspects of Secure Boot protections will become obsolete.
It's like having an antivirus that you don't update.
Overtime, your protection level gets lower and lower.

Also we do not know if at a certain point, MS could decide that your computer is not eligible for a certain update like 27H1, 27H2, 28H2. I would be extremely surprised that they would do something in that sense for 26H2, MS is a very slow beast...

Don't want to sound alarmist, but MS has done it when W11 came out where many older computers were not officially supported...

misar said:

I admit to being confused by this.

You seem to be saying that Secure Boot protections will cease without the current 2023 certificate update. I was under the impression that Secure Boot protections will continue to function but the device will stop receiving updates to key components: Windows Boot Manager; Secure Boot databases (DB); Revocation lists (DBX), Early‑boot vulnerability fixes (e.g., bootkit mitigations). If such updates are frequent then clearly Secure Boot protections will soon become ineffective.

Is that correct and going on past events (all we have at present) how common are such updates?

Click to expand...

It's like saying you have a working anti-virus product, but stopped getting new security updates from your vendor. You're protected against known past threats, but it might not help against new, unanticipated threats.

The primary objective of Secure Boot (at least related to the certs) is to prevent the "wrong" boot files from loading.

1. When Secure Boot is enabled, only boot files which are validated in the trust chain are allowed to execute. This requires any boot file to be signed by a DB cert (which is backed by a valid KEK), and the same cert cannot be added to the DBX at the same time (banned cert).

The purpose of this step is validate every boot file originates from a trusted publisher (ie. Microsoft or a Linux distro) listed in the DB certs list.

2. While a boot file may be published by a trusted source, it may already be compromised with a reported security hole. This individual boot file needs to be banned, to prevent attackers from using it. But we don't need to ban it's signing cert which is shared by other files, which currently don't have a known security problem.

A hash value is derived from the banned file's digital cert and appended to the DBX's hash list. The rate of having new banned boot files added appears to have slowed down but that isn't a guarantee of future activity. Because UEFI is used by non-Windows OS'es and EFI-level boot tools, the DBX list contains a lot of non-MS boot files. Common practice is to apply the entire DBX list, regardless of your OS.

For the boot manager, both Windows and major Linux distros have evolved into using versioning variables so they can ban multiple files at the same time, instead of adding each file's hash value. This is important if you have multiple boot files where the build version is the same, but the files are not identical. Windows uses the SVN, and Linux uses SBAT. Notably SBAT is stored as a separate variable in the UEFI, outside of the DBX.

If you're concerned about capping the size of the DBX, not applying new DBX entries will allow boot files which were later reported as vulnerable to continue working. You may be thinking you're in a pure Windows environment, so you don't care about Linux. But the DBX list can extend to 3rd-party tools that run from the UEFI level (for example, a BIOS update tool or a RAM memory tester).

3. Without adding the CA 2023 certs, you cannot boot from a CA 2023-enabled Windows in Secure Boot mode. Currently, W10 22H2 and supported W11 releases all get the same security fixes to the boot manager (as needed). The boot manager is always provided in two versions, CA 2011 and CA 2023, but only one version is applied to the EFI volume.

After the PCA 2011 cert expires in Octover, any future boot manager (with a newer security fix) cannot be signed by CA 2011 since the cert is expired. Therefore all boot managers after that can only be signed by CA 2023. Once a newer boot manager is released, it can't be used on a CA 2011-only system. You're stuck with either not taking any future Monthly Updates, or disabling Secure Boot entirely.

4. The decision to not update your BIOS is entirely up to you, but this outcome would have happened any way because CA 2011 was always going to expire. Banning CA 2011 is separate security step that MS wants to do to block Black Lotus variants from working.

If you were on an end-of-lifed Windows, then you don't get any new security fixes. And the Windows boot manager would have no chance of being replaced, which means you could ignore the entire CA 2011 expiration mess. But you're still using a currently supported Windows release.

DarkShadowMD said:

Not to sound like a fanboy, but Garlin and his script has done nothing more than helping people. Thank Microsoft and their failure to bring security patches in efficient ways to systems that need it. It's thanks to them we are in between this mess, and even Garlin has to deal with their mess with files and revocations, just look at his newest posts.

If you wanna sue Microsoft, be my guest, they are the responsible for all this mess, not a script that has done nothing but helping people, and you had the bad luck to get undesirable results, just the same way Microsoft could have bricked your device with the same exact procedure and update.

Click to expand...

Exactly. I had to uninstall the June 2026 Security Update (KB5094126) and NVIDIA - Display - 32.0.15.6094. Specifically, Windows downgraded my driver to "Display - 32.0.15.6094" because Microsoft forced the Nvidia update, which alongside KB5094126 caused a hard freeze. I had to boot into Safe Mode to uninstall KB5094126, and once back in Windows, I manually re-updated my Nvidia drivers.
I can personally attest that Garlin's script worked wonders on my three Dell PCs: an Inspiron 3650, an XPS 8930, and an Optiplex.
While I know every system is different, I am truly grateful for his script.

Today CU 26200.8875
SVN remains at 9.0

SVN only changes if they've patched the Windows boot manager. I don't think you can predict when it will happen.

The most important milestone will be the first SVN change after October 21. Because it means the boot manager has switched, and is not longer usable in Secure Mode if you haven't added the CA 2023 certs.

Monika1491 said:

SVN remains at 9.0

Click to expand...

Although the SkuSiPolicy did update.

I have been following these threads frequently and do not plan to implement any manual changes to the bios secure boot options until I have to.
Of course I will if I am forced to. I have several backup images and have not created a new USB boot stick in 3 months. I'm sure I will have to make a new one and implement the EFI file changes that have been recommended. My current pc is a Beelink. Was informed many months ago it might not work with secureboot without a bios update. I have the bios update on file but have run it yet because there are no issues with the pc as is. I am pasting the "check-uefi" scripts results. I would appreciate opinions of these results regarding suggested next steps.


Windows 11 25H2 (26200.8737)

Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) OFF

BIOS Firmware
-------------
AZW SER8
Version: HPT.8xxx.SER8.V029.P8C0M0C15.12.Link
Date: 2024-12-10
This version of HP BIOS doesn't support automatic updates.

Factory Default UEFI PK Cert
----------------------------
Custom PK

UEFI PK Cert
------------
Custom PK

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Windows UEFI CA 2023

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023

Factory Default UEFI DBX Certs
------------------------------
(NONE)
EFI_CERT_SHA256_GUID Signatures: 371

UEFI DBX Certs
--------------
(NONE)
Windows BootMgr SVN is MISSING.
EFI_CERT_SHA256_GUID Signatures: 431

UEFI Variables
--------------
Credential Guard: ON
SBAT (Linux only): sbat,1,2024010900 / shim,4 / grub,3 / grub.debian,4

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\\.\HarddiskVolume3\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.342, SVN 9.0

Registry: "WindowsUEFICA2023Capable" = 2
[Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.
NOT RECOMMENDED for dual-boot setups.

MachineLanguage said:

I have been following these threads frequently and do not plan to implement any manual changes to the bios secure boot options until I have to.
Of course I will if I am forced to. I have several backup images and have not created a new USB boot stick in 3 months. I'm sure I will have to make a new one and implement the EFI file changes that have been recommended. My current pc is a Beelink. Was informed many months ago it might not work with secureboot without a bios update. I have the bios update on file but have run it yet because there are no issues with the pc as is. I am pasting the "check-uefi" scripts results. I would appreciate opinions of these results regarding suggested next steps.

Click to expand...

MachineLanguage said:

BIOS Firmware
-------------
AZW SER8
Version: HPT.8xxx.SER8.V029.P8C0M0C15.12.Link
Date: 2024-12-10
This version of HP BIOS doesn't support automatic updates.

Click to expand...

This is a bug. There's a check for HP brand PC's, because earlier versions of their BIOS don't support automatic KEK updates.
So the script is getting confused because it sees "HP" in the model string.

MachineLanguage said:

UEFI PK Cert
------------
Custom PK

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Windows UEFI CA 2023

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023

UEFI DBX Certs
--------------
(NONE)
Windows BootMgr SVN is MISSING.
EFI_CERT_SHA256_GUID Signatures: 431

UEFI Variables
--------------
Credential Guard: ON
SBAT (Linux only): sbat,1,2024010900 / shim,4 / grub,3 / grub.debian,4

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\\.\HarddiskVolume3\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.342, SVN 9.0

Registry: "WindowsUEFICA2023Capable" = 2
[Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.
NOT RECOMMENDED for dual-boot setups.

Click to expand...

Your BIOS has all of the CA 2023 certs installed, but CA 2011 has not been revoked (it's still optional for now). This PC is good for now.

Someone mentioned that a recent Beelink BIOS update added CA 2023 support. So it's always important to check for recent BIOS updates, in case your OEM has already added the CA 2023 certs into the firmware.

For the avoidance of doubt I am grateful to garlin for the time he takes responding to my questions AND for his scripts which I used back in May when I first posted about this issue.

My problem is twofold and entirely of Acer's making. Firstly, as they have not updated the BIOS of my two laptops, the script requires use of a manual approach to update the KEK key. I had no problem with following the instruction to download "microsoft corporation kek 2k ca 2023.der", mount the EFI partition, and copy the downloaded file to it. The instructions provided by garlin then say "Find the KEK key management screen (appearance depends on your BIOS), there should be an option to manage keys or "enroll a file". That is where the second Acer problem arises. There is absolutely no way in their BIOS to enrol a new KEK.

Back in May garlin also suggested a last resort approach which may force installation of the full set of 2023 certs. I decided then not to risk that solution unless and until the laptops become unusable. As I said a couple of days ago I am still satisfied with that decision.

when will it all be done? I mean no more updating this time around with these certs

Scott said:

Although the SkuSiPolicy did update.

Click to expand...

To prevent attackers from rolling back to an earlier file version, Windows has two different checks:

SVN -> Windows boot manager's SVN
SkuSiPolicy.p7b -> winload.efi's file version

If you have a SkuSiPolicy file deployed, this means you will have to rebuild your WinRE-based boot media (again). This is the price of keeping up with Windows boot security.

man00 said:

when will it all be done? I mean no more updating this time around with these certs

Click to expand...

Adding the new CA 2023 certs is an one-time operation.
Banning the old CA 2011 cert is an one-time operation.

If you are installing the latest Windows Updates, recent security fixes might result in the Windows boot manager and/or winload.efi being changed. There is no planned stop to this process, or a fixed schedule. Security vulnerabilities are reported to MS and fixed as soon as possible.

Some months you might have no new boot manager or winload.efi. The Secure Boot task is supposed to install any updated boot manager or SkuSiPolicy.p7b on the EFI volume. But it has no responsibility (or ability) to update any bootable USB drives you have.

Windows used to not care about these things, but now it's obvious that MS has to update key boot files more quickly because attackers are getting smart.

After today's cumulative update, my HP laptop confidence level went from observation, more data needed to High Confidence. I haven't revoked the Windows PCA 2011 cert on this system yet. I'll probably wait until either MS decides to revoke it or do it some time after the cert expires.