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

Ok done. So is stuck on "suspending bitlocker for one reboot" and nothing happens.
So i tried to suspend bitlocker manually before running the script. What happens:
PS C:\Windows\system32> cd C:\SSB\GARLIN\
PS C:\SSB\GARLIN> powershell -ep bypass C:\ssb\GARLIN\Update_UEFI-CA2023.ps1
Successfully appended "DBUpdate3P2023.bin" to UEFI DB.

REQUIRED ACTION
---------------
Restart Windows, for UEFI updates to take effect.

I then try a check-uefi.bat before rebooting:

PS C:\SSB\GARLIN> .\Check-UEFI.bat
Windows PowerShell
Copyright (C) Microsoft Corporation. Tutti i diritti riservati.

Installa la versione più recente di PowerShell per nuove funzionalità e miglioramenti. Windows PowerShell update message FAQ - PowerShell

Secure Boot: ON
Virtualization Based Security: ON

BitLocker on (C:) OFF
SUSPENDED for 1 reboot.

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

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

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0

EFI Files
---------
Disk 1: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

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

Disk 1: SkuSiPolicy.p7b (for VBS) is CURRENT.

STATUS REPORT
-------------
Registry: UEFICA2023Status = Updated

SUCCESS: NO UPDATES ARE REQUIRED.

PS C:\SSB\GARLIN>

Then i reboot... and if i do this check again it says

REQUIRED ACTION
===============

To install [UEFI CA 2023] certs, run the commands:

manage-bde -Protectors -Disable C: -RebootCount 1
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5000 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Like we didn't did anything.

​

Tried also "powershell -ep bypass \your\path\Update_UEFI-CA2023.ps1" with powershell 7... same effect

Before you updated this PC the first time, did you use Setup Mode or any manual enrollment? I'm wondering if this is one of those "problem" BIOS'es which don't return the correct results to Windows.

Can be. Usually i set the regkey "availableupdates" on the value 0x5944 hex then start the secure boot scheduled task, then do 3-4 reboot. I then use your scripts to check the results (i also use another script taken from github - google "cjee guthub").
Is there a way i can check manually if that certificate is installed or not?
The same method has been used on more or less 20 DELL workstation that worked flawless. I have this strange behaviour only with HP zbook g11.

epud80 said:

Can be. Usually i set the regkey "availableupdates" on the value 0x5944 hex then start the secure boot scheduled task, then do 3-4 reboot. I then use your scripts to check the results (i also use another script taken from github - google "cjee guthub").
Is there a way i can check manually if that certificate is installed or not?
The same method has been used on more or less 20 DELL workstation that worked flawless. I have this strange behaviour only with HP zbook g11.

Click to expand...

These HP machines are rather new and the latest firmware update does have updated default certificates already- and from certificate side everything should be OK.

There's the one presumption at Microsoft and in garlins scripts that might be inncorrect somtimes:
If ther's a Microsoft Corporation UEFI CA 2011 cert both the Microsoft UEFI CA 2023 and the Microsoft Option ROM UEFI CA 2023 certs should be added.

Since MS did split the function of the Microsoft Corporation UEFI CA 2011 (enabling secure boot with third party firmware and non MS bootloaders) into two different certificates (Microsoft UEFI CA 2023 for non-MS bootloaders and Microsoft Option ROM UEFI CA 2023 for third party firmware) not always both certs are necessary. For a laptop the third party firmware might not be necessary. They usually don't have any options for adding boot relevant hardware which could need its own firmware at boot, except for discrete graphics- if the manufacturer didn't include this firmware into the main bios.

(The Zbook G11 seems to have discrete NVidia graphics which again might have its own separate firmware which could/ would need this certificate if signed with 2023 certs, but I don't see any separate updates on HPs support- I assume the firmware is included in the main firmware)

Might adding the third party firmware cert (Microsoft Option ROM UEFI CA 2023) be harmful? At first glance not, but I read for example about a rare software som introduces a harddisk password by simulating a third party firmware which get's loaded before the MS bootmanager (see here, this post and the next). One could imagine other more destructive functions executed by such 'firmware'...

So HP might be completely correct by not adding this cert to the defaults in the firmware and maybe in prohibiting adding additional certs. There might be (but this is guessing now) mechanisms in (their) newer firmwares to remove certs not wished for. Or there are other protection mechanisms- direct access to larger parts of NVRAM is prohibited, maybe the NVRAM area with certs is compared to the default at every boot. And HP has it's own firmware protections active.

Well, actually they admit this here:



In conclusion for you:
You simply don't need the third party firmware cert that can't be updated (and HPs making sure you have only the certificates needed for that machine- if you like it or not)

That's the same conclusion i came yesterday reading a lot of stuff- but thank you for point it out, especially the HP note.
So if i understood correctly

1) if a vendor don't publish an updated firmware for a computer model, is forcing you to change it if you want to keep secureboot functioning.
2) Microsoft can act with computer manufacturers to update only "ms secureboot certificates", and ignore the rest (at the expense of other operating systems that do not use that certificate, such as Linux)

?

epud80 said:

1) if a vendor don't publish an updated firmware for a computer model, is forcing you to change it if you want to keep secureboot functioning.

Click to expand...

Unclear, what do you mean by "change it"?

epud80 said:

2) Microsoft can act with computer manufacturers to update only "ms secureboot certificates", and ignore the rest (at the expense of other operating systems that do not use that certificate, such as Linux)?

Click to expand...

No, that'd be manufacturers decision. And if there weren't special protection mechanisms enabled you/ MS / another OS could manually add these certificates- like you tried.

But when buying workstation laptops one normally appreciates a high security level (=> firmware protection).

change it = buy a new one

epud80 said:

1) if a vendor don't publish an updated firmware for a computer model, is forcing you to change it = buy a new one if you want to keep secureboot functioning.

Click to expand...

No.

Afaik if a vendor doesn't publish new firmware and if the vendor doesn't supply a new KEK signed with vendors PK, then one can't update the secure boot system after certificates expire.

Just to avoid misunderstandings: Your Zbook G11 doesn't prevent you from installing other OS, this cert exists, it prevents you from using boot devices with own firmware needed for boot.

garlin said:

The revoke step is not mandatory in the update script. If I forced a revocation, some users would be afraid to run it (not kidding).
Re-run the script with "-Revoke" flag, and you'll be done.

Click to expand...

Okay "not mandatory." Does that mean that since I've successfully run your scripts on both my PCs, I can just wait for Microsoft to remove the old certs via an update sometime later this year and not bother running the -Revoke step sooner?

nikki605 said:

Okay "not mandatory." Does that mean that since I've successfully run your scripts on both my PCs, I can just wait for Microsoft to remove the old certs via an update sometime later this year and not bother running the -Revoke step sooner?

Click to expand...

MS will start the mandatory revocations in the second half of 2026. One of the Secure Boot docs states that MS will provide at least 6 months notice before a date is selected. You're free to wait for their timetable when it gets finally announced.

It'll probably be another gradual rollout, where different PC's get picked at random until they're done with everyone.

Under the UEFI cert model, you don't remove any banned certs. They continue to exist where they were before in the DB, but are also represented in DBX simultaneously.

The security model works like a math equation:
(empty set) + [list of DB certs] - [list of DBX certs] = [list of allowed certs]

t2s50 said:

Afaik if a vendor doesn't publish new firmware and if the vendor doesn't supply a new KEK signed with vendors PK, then one can't update the secure boot system after certificates expire.

Click to expand...

That's the whole reason behind the Windows OEM Devices PK (and other EDK2 binary files that MS provides on their GitHub).

Assuming your BIOS is functional (and not brain dead because of your vendor's stupid design), you can enter Setup Mode and replace the default vendor PK with the "generic" Windows OEM PK. Obviously since the PK re-signs the KEK, MS also provides you with a corresponding CA 2011 and CA 2023 KEK to drop in.

The Windows OEM Devices PK was first proposed as a solution to the dreaded AMI Test/Do Not Ship PK fiasco.
GitHub - CERTCC/PKfail: Mitigations & detection tools for VU#455367

A Mosby-like tool could be written to use the EDK2 files that MS provided, instead of creating a custom PK. I'm not going into the politics of that privacy discussion, other than its technically feasible. The drawback is MS now owns both the PK and the KEK (if you install it), instead of separating those ownerships into different parties.

Windows OEM PK to me looks like a reasonable compromise for orphaned PC's. But it can't be used in a number of cases because your legacy BIOS is flat broken or not a mature product compared to later generations of BIOS'es.

Last sarcasm for the day: HP SureStop.

garlin said:

MS will start the mandatory revocations in the second half of 2026. One of the Secure Boot docs states that MS will provide at least 6 months notice before a date is selected. You're free to wait for their timetable when it gets finally announced.

It'll probably be another gradual rollout, where different PC's get picked at random until they're done with everyone.

Under the UEFI cert model, you don't remove any banned certs. They continue to exist where they were before in the DB, but are also represented in DBX simultaneously.

The security model works like a math equation:
(empty set) + [list of DB certs] - [list of DBX certs] = [list of allowed certs]

Click to expand...

Looks like the gradual rollout has started for some users:

garlin said:

Assuming your BIOS is functional (and not brain dead because of your vendor's stupid design), you can enter Setup Mode and replace the default vendor PK with the "generic" Windows OEM PK. Obviously since the PK re-signs the KEK, MS also provides you with a corresponding CA 2011 and CA 2023 KEK to drop in.

Click to expand...

You might as well take the certs from a newer machine from same manufacturer (if the machine gives access to import certifiates). Tried this for an old Haswell MSI board and it worked, too. (Updating KEK with stock PK in place with normal MS-/ Windows- procedure didn't work).

Tried updating after checking this is what I got, I really don't know to finish or do

man00 said:

Tried updating after checking this is what I got, I really don't know to finish or do

Click to expand...

Can you run the check script, with the "-Verbose" option added to the command line? I suspect you don't have a KEK CA 2023 written (which is why the boot manager isn't supported). If you have Secure Boot currently enabled, shutdown Windows and temporarily disable Secure Boot so you can continue booting Windows for now.

You have a BIOS that is unsupported for automatic updates. While you're looking the BIOS, find the UEFI setup menu and see if this BIOS supports manual key enrollment. If it does, check if there's a KEK category and select load key from a file. The script should have copied a cert file to the EFI, and you can scroll through the different disk devices and look for an "\EFI\Certs" folder. Load the KEK CA 2023 file from inside the folder.

If you don't have what looks like a manual KEK option, search for a Setup Mode option.

garlin said:

Can you run the check script, with the "-Verbose" option added to the command line? I suspect you don't have a KEK CA 2023 written (which is why the boot manager isn't supported). If you have Secure Boot currently enabled, shutdown Windows and temporarily disable Secure Boot so you can continue booting Windows for now.

You have a BIOS that is unsupported for automatic updates. While you're looking the BIOS, find the UEFI setup menu and see if this BIOS supports manual key enrollment. If it does, check if there's a KEK category and select load key from a file. The script should have copied a cert file to the EFI, and you can scroll through the different disk devices and look for an "\EFI\Certs" folder. Load the KEK CA 2023 file from inside the folder.

If you don't have what looks like a manual KEK option, search for a Setup Mode option.

Click to expand...

If that is one of those ps1 files no I was not able to run any of those

How did you get the report output from above? Did you run the batch file instead?

For the batch file:

man00 said:

If that is one of those ps1 files no I was not able to run any of those

Click to expand...

Most batch files now need to be unblocked (Right click)
Some systems wont allow PS1 scripts. Try the following in Powershell before you run the ps1

Run in terminal as admin:
Set-ExecutionPolicy Unrestricted

I had to do this to run those scripts.