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

garlin · May 6, 2026

SaliesBuzz said:
Their response was:

BIOS date ≠ computer manufacturing date. Many OEM machines don't necessarily have updated BIOS versions after leaving the factory; they often use a stable version.

The core issue isn't the BIOS release date or which stable version. Their BIOS is missing the CA 2023 certs as factory defaults.

Most Chinese Mini PC vendors manufacture someone else's reference design. If they don't have the resources to manage their own BIOS, they should consult the upstream source for the BIOS provider.

SaliesBuzz said:
This script has two characteristics:

It's a community script, not an official Microsoft tool.

It's not a community script. I wrote the entire set of scripts (minus the certificate decoding function borrowed from a well known Windows security researcher).

SaliesBuzz said:
It uses "rule-based judgment," not "security certification."
For example: Seeing AMI test PK
Marking it "untrustworthy."
But in reality:
Many OEM BIOS internal test keys may already exist
Or the fields are not fully standardized.
The script "judges by string," not certified by a security organization.

That's hilarious. AMI Test PK is a well known concern in the PC security community for several years now.

CERT even released a GitHub fix of their own (2024) which replaces the test key. A question for them, is why are you even using the AMI Test Key? It violates AMI's instructions that vendors are supposed to create their own PK's.

GitHub - CERTCC/PKfail: Mitigations & detection tools for VU#455367

SaliesBuzz said:
Does it provide "chain of evidence verification"?
No (it only reads fields + rule-based judgment)
Is it possible for false alarms? ✔ Very high (especially the BIOS/UEFI section)

I get the distinct impression they are giving me "the finger"!

It is rule-based, but I imagine the Secure Boot task when it runs, follows the same general set of rules. It's not rocket science if you read the Secure Boot specs and what MS has provided in piecemeal in their official guidance.

The short answer is (after fixing any user reported bugs), no one's found a significant disagreement between what the Secure Boot task returns (in reg key settings) and my script's report. I didn't randomly make up the checks, they're based on the logical requirements for how the process works. It's like solving a proof in math class.

Their response is essentially based on the fact that the only BIOS they can get their hands on is a copy of the AMI Test PK. Because the reference copy from AMI never had any CA 2023 certs added. And they're not going to admit the AMI Test PK is suspected of being compromised from a previous supply chain hack at an unnamed OEM, and shouldn't be trusted in 2026.

PKfail: Untrusted Platform Keys Undermine Secure Boot on UEFI Ecosystem

You don't have to use my script. Windows will report the same facts, but not in a well organized manner. But that doesn't change the fact no offbrand Chinese vendor should be using AMI Test PK.

anchamp65 · May 6, 2026

garlin said:
The core issue isn't the BIOS release date or which stable version. Their BIOS is missing the CA 2023 certs as factory defaults.

Most Chinese Mini PC vendors manufacture someone else's reference design. If they don't have the resources to manage their own BIOS, they should consult the upstream source for the BIOS provider.

.........

Am I the only one that feels like we're getting a free course on Sceure Boot...

It just shows that even after 40 years in the computer industry, you definitely can't know everything !

Thanks @garlin

UrthBoundMisfit · May 6, 2026

garlin said:
That's hilarious. AMI Test PK is a well known concern in the PC security community for several years now.

True story. Even a relative noob like myself is aware of this.

gunrunnerjohn · May 6, 2026

I know more than I ever wanted to know about Secure Boot, and I'm pretty sure I haven't scratched the surface as far people that actually know all the in's and out's of the process!

I know for sure that I shouldn't have to know that much about it to keep my computer running with reasonable security! I'm certainly thankful for people like @garlin that have really explored all the twists and turns of the process and shared the fruits of his labors with us unwashed masses. :clap:

Dirtyflash · May 6, 2026

gunrunnerjohn said:
I know more than I ever wanted to know about Secure Boot, and I'm pretty sure I haven't scratched the surface as far people that actually know all the in's and out's of the process!

I know for sure that I shouldn't have to know that much about it to keep my computer running with reasonable security! I'm certainly thankful for people like @garlin that have really explored all the twists and turns of the process and shared the fruits of his labors with us unwashed masses.

I can say the same. However, I can't help but wonder about the other 99.99% of users around the world that don't visit, or participate in Windows forums. What will they do if they experience problems related to Secure Boot, let me guess, they'll go out and buy a new computer, there, fixed.

DarkShadowMD · May 6, 2026

Dirtyflash said:
I can say the same. However, I can't help but wonder about the other 99.99% of users around the world that don't visit, or participate in Windows forums. What will they do if they experience problems related to Secure Boot, let me guess, they'll go out and buy a new computer, there, fixed.

I can cite Reddit for example, there has been a fair influx of people asking why their machines suddenly have Secure Boot violations, or other issues related to this.

You would assume that Microsoft, taking charge of the process would avoid that kind of problems, but reality tells otherwise.

I really hope their way of handling things for the rest of the people really solves this, because we are gonna see an armaggedon of unbootable devices (unless they disable Secure Boot) because they couldn't handle this properly.

I'm glad I saw this thread and @garlin is the guy that helps us all, with that huge patience of his, otherwise, I would be borderline becoming insane lol.

garlin · May 6, 2026

DarkShadowMD said:
You would assume that Microsoft, taking charge of the process would avoid that kind of problems, but reality tells otherwise.

I really hope their way of handling things for the rest of the people really solves this, because we are gonna see an armaggedon of unbootable devices (unless they disable Secure Boot) because they couldn't handle this properly.

MS is in charge of carrying out the update process. But the ultimate burden falls on the OEM's to provide an updated BIOS release, or provide a signed KEK file to MS for a live update. MS has to play a delicate game. They can't call out the OEM's for being flakes, that's bad for business.

So MS and the OEM's do this ridiculous dance where they pretend they don't know the update process will fail, because you don't have a supported BIOS. It's kinda of utterly stupid.

But the reality is MS will never stop Windows from working because you can't enable Secure Boot. There's a lot of legitimate reasons for enterprise (paid) customers needing to run some legacy HW device with an "insecure" driver. And therefore can't run Secure Boot.

The problem will come from your FPS game which is plagued by online cheaters. To battle the cheats, the game publishers want to enable Secure Boot and Virtualization Based Security (which requires SB) as the first line of defense to block cheat code. MS isn't going to force you to run Secure Boot, they will undoubtedly keep nagging you every chance they get... but your games is what pushes users to embrace Secure Boot.

No Secure Boot = no games protected by anti-cheats.

A game doesn't need Secure Boot to run. A game plagued by cheaters wants Secure Boot for help. It's harder for cheaters to get signed code that passes Code Integrity rules.

otnert · May 6, 2026

SaliesBuzz said:
Factory Default UEFI PK Cert
----------------------------
DO NOT TRUST - AMI Test PK

The whole idea of secure boot is just that, booting up securely and without signed certificates starting from the PK, the system is vulnerable.

You could update the Platform Key (PK) yourself to the Microsoft PK, more info here.

I had the same 'DO NOT TRUST - AMI Test PK' key on my GEEKOM mini PC, and used the above to update my PC.

EDIT: ! this was before I stumbled on Garlin's powershell scripts that also updates the PK!

garlin · May 6, 2026

The AMI Test PK is a valid signed PK, except it's widely believed that its private signing key was leaked (since it's part of the reference materials for all OEM's who license the same BIOS) and therefore malicious actors can create their own validated KEK certs to apply on the affected PC's.

If you delete all certs and go into Setup Mode, the update script will install the complete set of MS certs. Including the Microsoft PK, or more properly the "Windows OEM Devices" PK.

The CERT script will take care of the PK, but doesn't address the KEK CA 2023 which needs to be updated. Strangely enough, MS has provided a signed KEK CA 2023 for AMI Test PK machines. Even though everyone knows it's not secure. :facepalm:

Code:

    "9a3056b5260f628645b4d9ac61aebd8060305c3e": {
        "KEKUpdate": "AMI/KEKUpdate_AMI_PK1.bin",
        "Certificate": {
            "serial_number": "ea01f2fb64c48b8f4390e52d69123b85",
            "issued_to": "CN=DO NOT TRUST - AMI Test PK",
            "issued_by": "CN=DO NOT TRUST - AMI Test PK"
        }
    },
    "a773113bafaf5129aa83fd0912e95da4fa555f91": {
        "KEKUpdate": "AMI/KEKUpdate_AMI_PK2.bin",
        "Certificate": {
            "serial_number": "e4126c1da6b1d49f4194e0fe365059c9",
            "issued_to": "CN=DO NOT TRUST - AMI Test PK",
            "issued_by": "CN=DO NOT TRUST - AMI Test PK"
        }
    },
    "6592a50636faf8be9ae74f0f7f8bd744fa44b329": {
        "KEKUpdate": "ASUS/KEKUpdate_ASUS_PK1.bin",
        "Certificate": {
            "serial_number": "55fbef878123008447170bb3cd873af4",
            "issued_to": "CN=DO NOT TRUST - AMI Test PK",
            "issued_by": "CN=DO NOT TRUST - AMI Test PK"
        }
    },
    "2b6ccde909230f89447d8a583d03a432d686faee": {
        "KEKUpdate": "AMI/KEKUpdate_AMI_PK4.bin",
        "Certificate": {
            "serial_number": "f73d2e3c9364aeb04c8395fdf7ed32a7",
            "issued_to": "CN=DO NOT TRUST - AMI Test PK",
            "issued_by": "CN=DO NOT TRUST - AMI Test PK"
        }
    },

DarkShadowMD · May 6, 2026

garlin said:
MS is in charge of carrying out the update process. But the ultimate burden falls on the OEM's to provide an updated BIOS release, or provide a signed KEK file to MS for a live update. MS has to play a delicate game. They can't call out the OEM's for being flakes, that's bad for business.

So MS and the OEM's do this ridiculous dance where they pretend they don't know the update process will fail, because you don't have a supported BIOS. It's kinda of utterly stupid.

But the reality is MS will never stop Windows from working because you can't enable Secure Boot. There's a lot of legitimate reasons for enterprise (paid) customers needing to run some legacy HW device with an "insecure" driver. And therefore can't run Secure Boot.

The problem will come from your FPS game which is plagued by online cheaters. To battle the cheats, the game publishers want to enable Secure Boot and Virtualization Based Security (which requires SB) as the first line of defense to block cheat code. MS isn't going to force you to run Secure Boot, they will undoubtedly keep nagging you every chance they get... but your games is what pushes users to embrace Secure Boot.

No Secure Boot = no games protected by anti-cheats.

A game doesn't need Secure Boot to run. A game plagued by cheaters wants Secure Boot for help. It's harder for cheaters to get signed code that passes Code Integrity rules.

It's funny because you basically install malware (Denuvo or anything that requests Kernel access.) to combat malware or cheaters.

I want to see gamer faces when their system start showing a secure boot violation because Microsoft forgot to tell people they need a BIOS update to keep Secure Boot working as usual.

Personally, I turn off VBS because I need nested virtualization in my VM's, sometimes you need to play with stuff in Linux that requires Virtualization inside the VM as well... (Winapps, I'm looking at you ¬¬). I had it enabled before, no difference in performance (Like some gamers claim), but playing with Virtual Machines really ask you something in return lol. I still like Secure boot enabled... one never knows when it will come in handy...

I really hope this dance stops and they get serious, because I wouldn't like to be in their shoes when all those PC's stop booting... and nobody likes an angry gamer not able to play their shooter mess :V

Oh, almost forgot to tell... seems you need to update your boot media EVEN if you use Reflect X latest version (8843 or 8846 IIRC), because the WinPE built for the USB using this version partially updates the boot manager, but in a way where the script still says you have the SVN 8.0, but CA 2023 doesn't appear (Says 2011 is just not allowed). To get fully compliant, you need to run the update script for bootmedia, or do the usual partition mount, bootfile copy to the USB, unmount and call it a day... I know because I'm trying the 30 day trial and had to do this.

UrthBoundMisfit · May 6, 2026

Next noobish question from yours truly

garlin said:
There are three scripts in the release:

Check_UEFI-CA2023.ps1
Checks the current state of your UEFI certs, and the boot files for Windows and any bootable DVD or USB media. The script can provide an Audit Report, listing what steps need to be completed to be in compliance with the CA 2023 update, and what commands to run.

Update_UEFI-CA2023.ps1
Updates the UEFI certs and boot files for Windows and any bootable USB media. You have the option to only install the UEFI CA 2023 certs, and not revoke the PCA 2011 cert; or to complete the entire process in one pass.

Check_DBXUpdate.bin.ps1
Compares any submitted DBXUpdate.bin file against the current UEFI DBX variable, and informs you if there are any EFI or SVN signatures that need to be installed.

I have several bootable ISO's on a Ventoy stick (Windows installers, PE's, Macrium Recovery, Mini-Tool Part Mgr, etc...)what would be the correct procedure to update all that apply? Do I need to mount each ISO, run the script with the -BootMedia flag, recreate the ISO's & replace each one in Ventoy? Or will the script auto-magically update all if I simply mount the Ventoy stick? Forgive me if this has been asked & answered.

TIA & cheers!

anchamp65 · May 6, 2026

UrthBoundMisfit said:
View attachment 170729

Next noobish question from yours truly

I have several bootable ISO's on a Ventoy stick (Windows installers, PE's, Macrium Recovery, Mini-Tool Part Mgr, etc...)what would be the correct procedure to update all that apply? Do I need to mount each ISO, run the script with the -BootMedia flag, recreate the ISO's & replace each one in Ventoy? Or will the script auto-magically update all if I simply mount the Ventoy stick? Forgive me if this has been asked & answered.

TIA & cheers!

It fixes the boot manager of the USB drive, it can't fix the boot manager inside the ISO files contained on the USB drive.
Garlin's script will not even look at the ISO files.

UrthBoundMisfit · May 6, 2026

anchamp65 said:
It fixes the boot manager of the USB drive, it can't fix the boot manager inside the ISO files contained on the USB drive.
Garlin's script will not even look at the ISO files.

Yeah I just ran it w/ the -BootMedia flag, results:

Code:

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

Welcome to WIN10
You are logged in as XXX
Today: 5/6/2026 9:58:15 PM
PowerShell 5 awaiting your commands.
PS C:\> cd C:\SecBoot
PS C:\SecBoot> .\Check_UEFI-CA2023.ps1 -BootMedia
Secure Boot: ON
Virtualization Based Security: OFF
BitLocker on (C:) OFF

UEFI KEK Certs
--------------
    Microsoft Corporation KEK CA 2011
    Microsoft Corporation KEK 2K 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
--------------
    Microsoft Windows Production PCA 2011
    Windows BootMgr SVN 8.0

EFI Files
---------
    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.

Bootable Media
--------------
    DVD Drive E:
    USB Drive G: "Ventoy"
    USB Drive H: "VTOYEFI"
        Boot File [Microsoft Corporation UEFI CA 2011] is ALLOWED.


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

    SUCCESS: UPDATES ARE FINISHED.
    UEFI CA 2023 certs are present, PCA 2011 cert is revoked.


PS C:\SecBoot>
PowerShell 7.6.1
PS C:\Windows\System32> cd c:\SecBoot
PS C:\SecBoot> .\Update_UEFI-CA2023.ps1 -BootMedia
    Copying EFI boot file to USB Drive H: "VTOYEFI"

SUCCESS: NO UPDATES ARE REQUIRED.PS
C:\SecBoot>

garlin · May 6, 2026

DarkShadowMD said:
Oh, almost forgot to tell... seems you need to update your boot media EVEN if you use Reflect X latest version (8843 or 8846 IIRC), because the WinPE built for the USB using this version partially updates the boot manager, but in a way where the script still says you have the SVN 8.0, but CA 2023 doesn't appear (Says 2011 is just not allowed). To get fully compliant, you need to run the update script for bootmedia, or do the usual partition mount, bootfile copy to the USB, unmount and call it a day... I know because I'm trying the 30 day trial and had to do this.

I've got to figure what's the deal with Macrium boot media. It's not my main focus (getting Windows up to date), but Macrium not booting appears to be a serious trend. I guess I should allocate some time to look into it.

wabbit · May 6, 2026

On the latest Macrium X update (8843). I use the WINRE to make my rescue media. I still had to update the rescue media usb to add the ca 2023 certs. I still can't figure out why Macrium can't get the currrent ca 2023 bootloaders from the efi partition, so we aren't always making our rescue media boot with the ca 2023 certs.

UrthBoundMisfit · May 6, 2026

garlin said:
...but Macrium not booting appears to be a serious trend. I guess I should allocate some time to look into it.

As I am using Macrium Free which is EOL, that would be greatly appreciated... when you have time. :hug:

garlin · May 6, 2026

UrthBoundMisfit said:
Bootable Media
--------------
DVD Drive E:
USB Drive G: "Ventoy"
USB Drive H: "VTOYEFI"
Boot File [Microsoft Corporation UEFI CA 2011] is ALLOWED.

Ventoy's EFI partition provides a bootx64.efi, which is signed using a "Microsoft" and not "Windows" CA 2011.

MS only cares about banning Windows PCA 2011, and won't touch Microsoft UEFI CA 2011 (used by Linux). Instead it will try pushing out the SBAT, which the Linux equivalent of SVN, to ban older Linux boot files.

DarkShadowMD · May 6, 2026

garlin said:
I've got to figure what's the deal with Macrium boot media. It's not my main focus (getting Windows up to date), but Macrium not booting appears to be a serious trend. I guess I should allocate some time to look into it.

Your script basically updates the boot manager in the USB so... unless you just wanna point out users they still need to do it even when updating their rescue media, there's nothing else to do, because this is Macrium's responsibility. The good part here is that your update script handles this, for convenience and less typing.

UrthBoundMisfit · May 6, 2026

DarkShadowMD said:
(Says 2011 is just not allowed)

yup.

Code:

Bootable Media
--------------
    DVD Drive E:
    DVD Drive I: "05_06_2026"
        Boot File [Production PCA 2011] is BANNED

DarkShadowMD · May 6, 2026

UrthBoundMisfit said:

Yup, to not get a security violation trying to boot that media that should say [CA 2023] is ALLOWED. That only means PCA 2011 is banned, but you have no bootable media that uses the CA 2023 Cert.

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

Well-known member

My Computer My Computer

At a glance

Active member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Peaceful Citizen

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Peaceful Citizen

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Active member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Peaceful Citizen

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Peaceful Citizen

My Computers My Computers

At a glance

At a glance

My Computer

My Computer

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computers

My Computer

My Computer

My Computer

My Computer

My Computers

My Computer

My Computer

My Computers

My Computer

My Computers