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

JamesSmith said:

Tried everything and can't get it to load the cert. Look at this screenshot at the bottom.

Click to expand...

According to your screenshot, the PK key is the factory default. If you run the check script, does it continue to report "(NONE)" for the PK?

garlin said:

According to your screenshot, the PK key is the factory default. If you run the check script, does it continue to report "(NONE)" for the PK?

Click to expand...

Yes the output is still the same.

I don't know if this helps.



Should I run the update script and see what happens?

At the bottom in the bios it says this.

Nebulon Ranger said:

New user chiming in who manually updated the DB; this look okay? Other than the command to revoke, of course.

Click to expand...

You're good on the first part (adding CA 2023 certs and the boot manager). Revocation can be delayed until when MS makes it mandatory, later this year.

garlin said:

You're good on the first part (adding CA 2023 certs and the boot manager). Revocation can be delayed until when MS makes it mandatory, later this year.

Click to expand...

Good shout, thanks!

Anything related to UEFI peaks my anxiety pretty hard (don't want to potentially brick my board, after all), so it's great to put it to rest.

Nebulon Ranger said:

Good shout, thanks!

Anything related to UEFI peaks my anxiety pretty hard (don't want to potentially brick my board, after all), so it's great to put it to rest.

Click to expand...

Usually if your last BIOS was released in 2024-2025, they added the CA 2023 certs to the factory defaults. It's the older PC's that have more issues.

JamesSmith said:

At the bottom in the bios it says this.
View attachment 165418

Click to expand...

I would hold off on doing the update for now. I need to find a test script to extract your PK variable's data bytes, and figure out if the problem is with the script's parsing function for deciphering certs. Gimme an hour to figure it (or find the old script).

garlin said:

Usually if your last BIOS was released in 2024-2025, they added the CA 2023 certs to the factory defaults. It's the older PC's that have more issues.

Click to expand...

Hah! Let the only time I've forced myself to ignore my anxiety be the one time I needed to prove it wrong anyway. 5021 isn't the original version that shipped with the first-gen X570-E, I believe that was 440-something. I thiiiink I updated it around the time 5021 dropped, actually.

Regardless, thanks for the help, garlin. :)

garlin said:

I would hold off on doing the update for now. I need to find a test script to extract your PK variable's data bytes, and figure out if the problem is with the script's parsing function for deciphering certs. Gimme an hour to figure it (or find the old script).

Click to expand...

I ran your script and got this in event viewer



still getting the same output in your script. where is the old one you mentioned?

I found a earlier script. Does this help?

JamesSmith said:

I ran your script and got this in event viewer

Click to expand...

What's logged is that Windows knows it wrote the other CA 2023 certs (good), but this task doesn't bother checking your for PK (because it presumes you always had a valid one).

JamesSmith said:

still getting the same output in your script. where is the old one you mentioned?

Click to expand...

Run this script, and attached the exported .bin files (as a ZIP). I need to download it and confirm whether it's a parsing error or something's weird in your UEFI variables.

garlin said:

What's logged is that Windows knows it wrote the other CA 2023 certs (good), but this task doesn't bother checking your for PK (because it presumes you always had a valid one).


Run this script, and attached the exported .bin files (as a ZIP). I need to download it and confirm whether it's a parsing error or something's weird in your UEFI variables.

Click to expand...

How do I run it?

Run as Administrator:

Replace the first part of the file path with the folder where the script lives.

garlin said:

Run as Administrator:

Code:

powershell -ep bypass -f \folder\where\script\lives\Export-PKbytes.ps1

Replace the first part of the file path with the folder where the script lives.

Click to expand...

Is this what you wanted?

JamesSmith said:

Is this what you wanted?

Click to expand...

Thanks. I figured the problem, try this updated version of the check script.

garlin said:

Thanks. I figured the problem, try this updated version of the check script.

Click to expand...

I am not sure if this messed with your script but I updated everything while I was waiting and this is the output I get with the script you just gave me.

PS D:\temp> powershell -nop -ep bypass -f Check_UEFI-CA2023.ps1 -verbose
Windows 11 25H2 (26200.7840)

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

BIOS Firmware
-------------
Gigabyte Technology Co. B760M H DDR4
Version: F14
Date: 2025-06-19

Factory Default UEFI PK Cert
----------------------------
(NONE)

UEFI PK Cert
------------
(NONE)

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: 77

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0
EFI_CERT_SHA256_GUID Signatures: 487

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b version: 33284.17421.33440.335 is CURRENT.

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

SUCCESS: NO UPDATES ARE REQUIRED.

PS D:\temp>


I am done for today. I assume everything is working. The other script showed the UEFI PK Gigabyte

So I guess I am okay? Maybe some weird thing with my PC and your script?

Sorry, it's my script. One more try.
If you want to continue tomorrow, I'll be around.

garlin said:

Sorry, it's my script. One more try.
If you want to continue tomorrow, I'll be around.

Click to expand...

Looks like you fixed it. Can you confirm I am all done and nothing else is wrong?


PS D:\Temp> powershell -nop -ep bypass -f Check_UEFI-CA2023.ps1 -verbose
Windows 11 25H2 (26200.7840)

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

BIOS Firmware
-------------
Gigabyte Technology Co. B760M H DDR4
Version: F14
Date: 2025-06-19

Factory Default UEFI PK Cert
----------------------------
GIGABYTE

UEFI PK Cert
------------
GIGABYTE

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

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

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

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
GIGABYTE
GIGABYTE

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

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0
EFI_CERT_SHA256_GUID Signatures: 487

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b version: 33284.17421.33440.335 is CURRENT.

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

SUCCESS: NO UPDATES ARE REQUIRED.

PS D:\Temp>

This looks good, but I suspect Gigabyte cut a few corners when they issued their other certs.

Normally every cert's Subject line is supposed to have a descriptive title. But apparently Gigabyte simply chose to assign their name (CN=), but added nothing else. That's technically allowed, but not very helpful for debugging purposes.

garlin said:

This looks good, but I suspect Gigabyte cut a few corners when they issued their other certs.

Normally every cert's Subject line is supposed to have a descriptive title. But apparently Gigabyte simply chose to assign their name (CN=), but added nothing else. That's technically allowed, but not very helpful for debugging purposes.

Click to expand...

Is there a reason GIGABYTE is listed 2 times under
Factory Default UEFI DB Certs
and
UEFI DB Certs

All of the other times it says Gigabyte how do we know what year these are?

For example what needs to be revoked for this

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

Click to expand...

Thanks Garlin.

Vendors are allowed to create their own Secure Boot certs, in order to self-sign software tools used to update BIOS'es.

HP and Dell are also known to self-issue certs. The problem here is Gigabyte is too lax in not following the formal ISO organization model for labeling the cert's Subject field. For example, here's two examples of a Dell PK:


For reasons known only to Gigabyte (but it's a common issue with Chinese or Taiwanese OEM's), they simply encode their PK as "CN=GIGABYTE". I'd imagine the other Gigabyte-issued KEK and DB certs share a basic lack of descriptive detail.

The cert's Subject field is only present for human consumption, since they're actually referenced using the cert's thumbprint (or hash value). I can't add more reporting if there wasn't enough details to begin.