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

anchamp65 · 2026-07-31T12:33:57-0400

nikki605 said:
Something is wrong. Now what?

I'm lost with words on why you still have the one that looks like a MStore version

But this one seems correct

Can you run these commands again to validate you are pointing at the winget version

Code:

$PSHOME
(Get-Process -Id $PID).Path
Get-Command pwsh | Select-Object Source
where.exe pwsh

They should all point to "C:\Program Files\PowerShell\7" and last 3 should point to "pwsh.exe"
If they do, you can try Garlin's command again hoping it now works as expected.

garlin said:
These two commands get the same result:

Code:

.\Check-UEFI.bat -Verbose -BootMedia .\Check_UEFI-CA2023.ps1 -Verbose -BootMedia

DJinSD · 2026-07-31T13:12:39-0400

My Dell Optiplex 9020 MT status.

As I understand things with my sandbox system not having an updated KEK CA 2023 certificate, it is possible to manually append a certificate that is at CA 2023. And, a CA 2023 KEK certificate as provided by MSFT can be found in the EFI partition. However, using the Dell Type 2 BIOS firmware requires an input format other than .der, .cer or .crt. One reference found says Dell expects .auth format.

I have found one reference which says it is possible to convert from .der to .auth but I am unclear about doing that. Between my lack of experience in doing such things and the lack of an explicit and detailed documentation for doing such a conversion, I think I'm at an impasse.

Another reference found along with a document from the DOD says it is possible to create your own self-signed certificates (all 4) and to use those to bring the Secure Boot enviroment up to CA 2023. But again this is beyond my experience level.

I guess in the meantime, the 9020 which has "one foot in the boat and the other foot on the dock", will be OK until October when the CA 2011 KEK certificate expires resulting in no more updates to db or dbx with the associated security risks.

Maybe I'll get lucky some how in the next few months and be able to salvage the use of these very solid systems as far as having a total and complete Secure Boot environment. But if I don't get lucky I guess the choices are: (1) remove them from use and recycle the electronics; (2) stop worrying about Secure Boot, disable it and continue to use my NAS/file servers without it.

Fire away!

nikki605 · 2026-07-31T13:22:44-0400

anchamp65 said:
I'm lost with words on why you still have the one that looks like a MStore version

But this one seems correct
View attachment 178091

Can you run these commands again to validate you are pointing at the winget version

Code:

$PSHOME (Get-Process -Id $PID).Path Get-Command pwsh | Select-Object Source where.exe pwsh

They should all point to "C:\Program Files\PowerShell\7" and last 3 should point to "pwsh.exe"
If they do, you can try Garlin's command again hoping it now works as expected.

Still not right.

There is no folder named C:\Program Files\PowerShell on my system.

Time for a nap.

anchamp65 · 2026-07-31T13:35:40-0400

nikki605 said:
Still not right.

View attachment 178105

There is no folder named C:\Program Files\PowerShell on my system.

Time for a nap.

You ran the commands in the MStore one, try them in the other window, this one

But have you tried Garlin's commands again ? in either one ?

EDIT:
I think I found why your not finding the new one you installed with winget.
On my systems, I uninstalled all Powershell versions except the one from winget.
So when I search for PowerShell, that's the only one it finds.
Instead of searching for "PowerShell" in the Start Menu, search for "pwsh", it should show you the one you installed with winget.
You should now see this one, right click and start as administrator and test Garlin's commands.

garlin · 2026-07-31T14:22:55-0400

DJinSD said:
As I understand things with my sandbox system not having an updated KEK CA 2023 certificate, it is possible to manually append a certificate that is at CA 2023. And, a CA 2023 KEK certificate as provided by MSFT can be found in the EFI partition. However, using the Dell Type 2 BIOS firmware requires an input format other than .der, .cer or .crt. One reference found says Dell expects .auth format.

I have found one reference which says it is possible to convert from .der to .auth but I am unclear about doing that. Between my lack of experience in doing such things and the lack of an explicit and detailed documentation for doing such a conversion, I think I'm at an impasse.

Some older Dell BIOS'es can only accept the .auth file format. The .auth format is basically an export of the Secure Boot variable's raw bytes.

A Secure Boot certificate can be presented in one of two formats: pre-signed and post-signed. For the KEK, that means it needs to be signed by the current PK (which is the Dell factory PK by default).

A pre-signed cert is any cert which hasn't been signed by the PK. If you are the PK's owner (Dell, or you created your own private PK), then you own the PK's secret key that can be used to sign this cert file, transforming it into a post-signed file. But if you're not Dell, you don't have their private key.

The .auth format assumes the cert object has already been post-signed. As Dell won't support your PC, they will not provide a post-signed KEK file. Therefore this option is closed to us, and the next option is to Delete All Keys. This removes the PK as the blocking factor, and allows us to install a replacement set of Secure Boot keys.

Fortunately, MS provides a reference set of keys ("Windows OEM Device") which can be used.

If you have "Delete All Keys" presented, choose that option. Restart Windows, and run the update script. Before you delete all keys confirm you have disabled BitLocker (if enabled) on the C: drive and Windows Hello PIN (otherwise you may be locked out because it detects security changes).

DJinSD said:
Another reference found along with a document from the DOD says it is possible to create your own self-signed certificates (all 4) and to use those to bring the Secure Boot enviroment up to CA 2023. But again this is beyond my experience level.

Every user has the option to perform self-signing, but it's too much hassle for normal users if you're only updating the CA 2023 certs this one time.

gunrunnerjohn · 2026-07-31T16:57:03-0400

garlin said:
Every user has the option to perform self-signing, but it's too much hassle for normal users if you're only updating the CA 2023 certs this one time.

Wouldn't one benefit of self-signing assure you that the key was actually not compromised like the 2022 debacle?

Compromising the Secure Boot Process - Schneier on Security

This isn’t good: On Thursday, researchers from security firm Binarly revealed that Secure Boot is completely compromised on more than 200 device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro. The cause: a cryptographic key underpinning Secure Boot on those models that was...

www.schneier.com

garlin · 2026-07-31T17:22:04-0400

You're free to use self-signed certs, and the really paranoid or technical folks do that. But you're on your own (DIY) or that app I'm not allowed to mention, or have to seek a different community (usually Linux) to support your questions.

PKFail was well known in security circles before it was named "PKFail". What Binary did was to shock the industry by trying to actively count how broad the problem was. MS already addressed this with the "Windows OEM Devices" fix here:

CERTCC/PKfail Mitigations & detection tools for VU#455367

My scripts will nag you if you have a "DO NOT [whatever]" or "Test" PK. This is more an issue of lazy engineering from some OEM's. The BIOS licensors clearly instructed everyone to create their own PK's, and not copy the reference design they gave out.

The point being if everyone used the exact same PK, then breaking the PK's encryption key means you have access to so many different vendor's PC's, instead of spending much more effort to hack each individual company's PK. For a large company like Dell, they have a lot of different PK's floating around (although some models were caught with the PKFail laziness).

Could the Windows OEM Devices PK be cracked too, and that's a new form of PKFail? True.

But short of getting into a key management mess, it's the lesser evil for non-technical users. It's the 80/20 rule. You can recommend others take a more technical route up the mountain, but are you going to help them when they get stuck halfway to the summit?

Search

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

anchamp65

Active member

My Computer

At a glance

DJinSD

Member

My Computers

At a glance

At a glance

nikki605

Well-known member

My Computers

At a glance

At a glance

anchamp65

Active member

My Computer

At a glance

garlin

Well-known member

My Computer

At a glance

gunrunnerjohn

Well-known member

Compromising the Secure Boot Process - Schneier on Security

My Computers

At a glance

At a glance

garlin

Well-known member

My Computer

At a glance

Latest Support Threads

Latest Tutorials

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

Active member

My Computer My Computer

At a glance

Member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computers My Computers

At a glance

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

My Computer

My Computers

My Computers

My Computer

My Computer

My Computers

My Computer