Did you manually update your Secure Boot Keys ?

neldog · Sep 23, 2025

Boy, that sounds like a handful. I would hope that Dell would just send us a new BIOS with all that done already. I know for sure that 85 percent of their customers, if left to them, would even know where to start with all that. Thanks for your help.

I will bump your post on "Guidance for blocking rollback of Virtualization" as it may have gotten lost in all my problems.

neldog · Sep 23, 2025

Almighty1 said:
Anyone tried doing this?

KB5042562 Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates

Microsoft Support: Summary Microsoft was made aware of a vulnerability in Windows that allows an attacker with administrator privileges to replace updated Windows system files that have older versions, opening the door for an attacker to reintroduce vulnerabilities to Virtualization-based...

www.elevenforum.com

Bump

gunrunnerjohn · Sep 23, 2025

andyc56 said:
I'm not garlin, but I did notice you were using PowerShell 7.5.3 to run the script. When I do that, for the EFI output section I get:

Code:

EFI Files --------- Disk 1: Boot Manager [] is BANNED. Registry: WindowsUEFICA2023Capable = 2 [Windows UEFI CA 2023] is in UEFI DB, and Windows is starting from CA 2023 Boot Manager.

My boot disk is Disk 1. When I run it from Windows PowerShell (5.1), I get:

Code:

EFI Files --------- Disk 1: Boot Manager [Windows UEFI CA 2023] is ALLOWED. Registry: WindowsUEFICA2023Capable = 2 [Windows UEFI CA 2023] is in UEFI DB, and Windows is starting from CA 2023 Boot Manager.

So there appears to be something funky going on with one of the script functions when used with PowerShell 7.x.

I'm guessing that's a compatibility problem between PS 5.1 and PS 7.5.3, not a problem with the boot manager. If that were the case, the system wouldn't boot with secure boot enabled.

gunrunnerjohn · Sep 23, 2025

neves said:
They say they will (for officially supported systems - at least), the update it set for Mid 2026. That's at least 9 months till then.

Gee, so they're going to update it at the 11th hour, and that's if nothing goes wrong!

andyc56 · Sep 23, 2025

gunrunnerjohn said:
I'm guessing that's a compatibility problem between PS 5.1 and PS 7.5.3, not a problem with the boot manager. If that were the case, the system wouldn't boot with secure boot enabled.

Yes, it was. Garlin came up with a fix for the script in a later post. I tried it out, and it did indeed fix it. It works in both 5.1 and 7.5.3 now.

neves · Sep 23, 2025

gunrunnerjohn said:
Gee, so they're going to update it at the 11th hour, and that's if nothing goes wrong!

That's just it - they're waiting for all the popular OEMs to have the BIOS/UEFI Keys ready with a stable firmware. Some (a lot of them even) - already issued this update (as can be seen even in this topic), Others, still taking their time. Like MSI, contacted support - and they said they're still to busy - so it might take some time tot release an update, If Windows was a limited OS (like Mac OSX) - designed to work only with Microsoft hardware - such as - Surface Books, we'd have this update since 2024. But most OEMs - only focus on latest hardware in terms of updates - especially since there's 9 around 9 months left till said update.

Almighty1 · Sep 23, 2025

neldog said:
Boy, that sounds like a handful. I would hope that Dell would just send us a new BIOS with all that done already. I know for sure that 85 percent of their customers, if left to them, would even know where to start with all that. Thanks for your help.

I will bump your post on "Guidance for blocking rollback of Virtualization" as it may have gotten lost in all my problems.

We have more problems on the Dell like the TPM Chip can go not detected even on a Dell notebook when there is no physical chip. My motherboard took 2 months to die. Basically Windows would seem like someone hit the physical reset button anywhere from 30 seconds to a few hours after the spinning circle. Eventually, the motherboard would have leds that flash CPU failure but in reality, the capacitor burned down and burn whatever was on the otherside of the motherboard as it's mounted upside down where the F5 key is.

man00 · Sep 23, 2025

Can someone post 1 command that will update the secure boot keys?

Akeo · Sep 24, 2025

garlin said:
@Akeo, can you help us?

@AK6DN updated his UEFI using Mosby, and it's breaking the Get-UefiDatabaseSignatures function as provided by:

Check-UEFISecureBootVariables/Get-UEFIDatabaseSignatures.ps1 at main · cjee21/Check-UEFISecureBootVariables

It's throwing an exception for:

Code:

CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US CN=MosbyKey [2025.09.15] Cannot convert value "System.Byte[]" to type "System.Guid". Error: "Byte array for GUID must be exactly 16 bytes long."

Do you guys still need help with that? My understanding (from trying to sieve through this super long thread) is that this was a script issue?

Also, PLEASE, PLEASE, PLEASE, if you want to report a potential issue with Mobsy, USE THE MOSBY ISSUE TRACKER. Do not expect me to be browsing this forum on regular basis or @notifications to work, as I only visit this forum very infrequently.

And just so you know, I am planning to add the Option ROM cert in the next release of Mosby (and therefore in the 25H2 release of the UEFI Shell, which will include the latest Mosby). But it's going to take a little more time...

Friction · Sep 24, 2025

Just updated them. Thanks for the commands

Yozaemon · Sep 24, 2025

I was very lucky to find this forum and learn about @Akeo's Mosby.

I was able to successfully update the Secure Boot keys on my old PC, which did not have the keys included in KEKUpdateCombined.bin. Initially, typing just "Mosby" didn't work, but it ran and updated everything when I typed "Mosby_x64.efi".

This PC also had a "PK Fail" issue with an AMI TEST PK, so this brings me double relief.

I would like to express my gratitude to @Akeo.

gunrunnerjohn · Sep 24, 2025

Akeo said:
And just so you know, I am planning to add the Option ROM cert in the next release of Mosby (and therefore in the 25H2 release of the UEFI Shell, which will include the latest Mosby). But it's going to take a little more time...

First off, I want to thank you again for the valuable service you've provided with Mosby, it makes a complicated procedure simple. Adding the option ROM is great news, I do have a question.

If I already have everything but the option ROM finished, can I run Mosby again and let it finish the job, or will that screw something else up.

garlin · Sep 24, 2025

Akeo said:
Do you guys still need help with that? My understanding (from trying to sieve through this super long thread) is that this was a script issue?

Also, PLEASE, PLEASE, PLEASE, if you want to report a potential issue with Mobsy, USE THE MOSBY ISSUE TRACKER. Do not expect me to be browsing this forum on regular basis or @notifications to work, as I only visit this forum very infrequently.

And just so you know, I am planning to add the Option ROM cert in the next release of Mosby (and therefore in the 25H2 release of the UEFI Shell, which will include the latest Mosby). But it's going to take a little more time...

@AK6DN used Mosby, and now the reference script Get-UefiDatabaseSignatures.ps1 can't parse the updated DB byte contents.

AFAIK, it's not a problem with the function because it's always worked for non-Mosby examples. I have kludged a workaround using basic string matching on the raw bytes to report on Mosby PC's, but obviously that's not a good method for confirming the DB's integrity.

I don't understand the nuts & bolts other than I call "Get-SecureBootUEFI db | Get-UefiDatabaseSignatures", and parse the structured data. The first part of the code looks straightforward, it's expecting to see certain byte offsets.

Maybe you can work with @AK6DN to confirm they used Mosby correctly. I don't know if this an outlier case, or all Mosby users will get broken results when running the script.

Almighty1 · Sep 24, 2025

gunrunnerjohn said:
First off, I want to thank you again for the valuable service you've provided with Mosby, it makes a complicated procedure simple. Adding the option ROM is great news, I do have a question.

If I already have everything but the option ROM finished, can I run Mosby again and let it finish the job, or will that screw something else up.

I already tried it and basically it will only replace what isn't already there.

gunrunnerjohn · Sep 24, 2025

garlin said:
@AK6DN used Mosby, and now the reference script Get-UefiDatabaseSignatures.ps1 can't parse the updated DB byte contents.

Almighty1 said:
I already tried it and basically it will only replace what isn't already there.

I don't know that he's added the additional capability yet. If Mosby didn't cause any issues when you ran it again, that's a good thing.

Akeo · Sep 24, 2025

garlin said:
@AK6DN used Mosby, and now the reference script Get-UefiDatabaseSignatures.ps1 can't parse the updated DB byte contents.

Well, I'm not seeing any issue on a platform I recently updated with Mosby -x, be it with the script posted in post 644215 or when piping to the Get-UefiDatabaseSignatures function from Check-UEFISecureBootVariables/Get-UEFIDatabaseSignatures.ps1 at main · cjee21/Check-UEFISecureBootVariables:

Code:

PS C:\SB> . .\Get-UefiDatabaseSignatures.ps1
PS C:\SB> Get-SecureBootUEFI db | Get-UefiDatabaseSignatures

SignatureType      SignatureList
-------------      -------------
EFI_CERT_X509_GUID @{SignatureOwner=45a0fa32-6047-73c8-2433-c3b7d59e7466; SignatureData=[Subject]...
EFI_CERT_X509_GUID @{SignatureOwner=46def63b-5ce6-1cf8-ba0d-e2e6639c1019; SignatureData=[Subject]...
EFI_CERT_X509_GUID @{SignatureOwner=b5eeb4a6-7060-4807-3f0e-d296e7f580a7; SignatureData=[Subject]...
EFI_CERT_X509_GUID @{SignatureOwner=73e4ab21-55a9-2ab6-9a33-82c77f95acda; SignatureData=[Subject]...


PS C:\SB> .\Check_EFIBootFile.ps1
Secure Boot: ON
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 UEFI CA 2023
    Windows UEFI CA 2023

UEFI DBX Certs
--------------
    Microsoft Windows Production PCA 2011

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

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

Maybe if the people who experience the issue could save the DB with Get-SecureBootUEFI db -OutputFilePath DB.var and post the resulting DB.var somewhere, because it sure looks like a pure environmental issue to me right now.

OldNavy · Sep 24, 2025

The latest version of Rufus out today V 4.10.2279...
Add support for creating Windows CA 2023 compatible media (requires a Windows 11 25H2 ISO).

Rufus - Create bootable USB drives the easy way

Rufus: Create bootable USB drives the easy way

rufus.ie

AK6DN · Sep 24, 2025

Akeo said:
Well, I'm not seeing any issue on a platform I recently updated with Mosby -x, be it with the script posted in post 644215 or when piping to the Get-UefiDatabaseSignatures function from Check-UEFISecureBootVariables/Get-UEFIDatabaseSignatures.ps1 at main · cjee21/Check-UEFISecureBootVariables:

...

Maybe if the people who experience the issue could save the DB with Get-SecureBootUEFI db -OutputFilePath DB.var and post the resulting DB.var somewhere, because it sure looks like a pure environmental issue to me right now.

The problem occurred because I used Mosby v2.3 to add a PK (corrected) DB entry that was named 'MosbyKey' (by default).

Code:

CN=MosbyKey [2025.09.15]
Cannot convert value "System.Byte[]" to type "System.Guid". Error: "Byte array for GUID must be exactly 16 bytes long."

In the script it shows up under the DB entry when printed out.
Your example shows only the standard certs, no custom MosbyKey certificate

I'll see if I can run the code you posted above on that system and post the data.

Akeo · Sep 24, 2025

AK6DN said:
because I used Mosby v2.3 to add a PK entry that was named 'MosbyKey' (by default).

MobsyKey is NOT a PK. It's a DB. It should NOT be used as a PK, ever.

Unless you provide your own (but then don't use MosbyKey for that as again, it is NOT meant to be used as a PK) the PK is never saved. It is generated each time, and then, after the public key is saved as the PK, discarded from memory. This is how we ensure that a platform can not be compromised from the root of the chain, ever, because, with the Mosby defaults, nobody, including yourself or your motherboard's manufacturer, has the private key associated with the PK.

MosbyKey is what you can use to sign UEFI bootloaders for Secure Boot (as documented in the README). It will be automatically reinstalled as a DB key if present on your media. But it should never, ever be used as a PK.

Therefore, if you experience an issue after installing MosbyKey as the PK, I'm afraid you misunderstood how to use Mosby, and the error is on you...

AK6DN · Sep 24, 2025

Akeo said:
MobsyKey is NOT a PK. It's a DB. It should NOT be used as a PK, ever.

Unless you provide your own (but then don't use MosbyKey for that as again, it is NOT meant to be used as a PK) the PK is never saved. It is generated each time, and then, after the public key is saved as the PK, discarded from memory. This is how we ensure that a platform can not be compromised from the root of the chain, ever, because, with the Mosby defaults, nobody, including yourself or your motherboard's manufacturer, has the private key associated with the PK.

MosbyKey is what you can use to sign UEFI bootloaders for Secure Boot (as documented in the README). It will be automatically reinstalled as a DB key if present on your media. But it should never, ever be used as a PK.

Therefore, if you experience an issue after installing MosbyKey as the PK, I'm afraid you misunderstood how to use Mosby, and the error is on you...

Well maybe I misspoke about MosbyKey being in PK. It shows up under the DB entries using the modified Check_MosbyEFIBootFile.ps1 script.
I get these entries:

Code:

UEFI DB Certs
-------------
    Microsoft Corporation UEFI CA 2011
    Microsoft Windows Production PCA 2011
    Microsoft UEFI CA 2023
    Windows UEFI CA 2023
    MosbyKey

and it is that MosbyKey entry that borked the original Check_EFIBootFile.ps1 script.

As to my misunderstanding or misusing Mosby, I followed the directions in the Mosby README.md exactly:

Code:

3. Boot the computer where you want to install the keys into the UEFI firmware settings and
   make sure that your platform is in *Setup Mode*. Please refer to your manufacturer's
   documentation if you don't know how to enable *Setup Mode*.

4. Boot into the UEFI Shell media you created and type: `Mosby` (without any extension). The
   executable relevant to your platform will automatically launch and will guide you through
   the installation of the UEFI Secure Boot keys.

5. Once the installation is complete, reboot into UEFI firmware settings, and make sure that
   Secure Boot is enabled.

In the Mosby screen dialog when it asked if I wanted to generate new platform keys, I said yes.
I got MosbyKey.crt/.pem/.pfx generated on the USB key and I saved those away.

Maybe if I had used the Mosby option to NOT generate a unique MosbyKey this whole problem would not exist. IDK.

Attached is a .zip of the DB.var file generated from running Get-SecureBootUEFI db -OutputFilePath DB.var

Did you manually update your Secure Boot Keys ?

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Member

My Computer

New member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

Attachments

My Computers

Similar threads