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.