Did you manually update your Secure Boot Keys ?

KevTech · Sep 16, 2025

Glad I just used Microsoft instruction instead of Mosby.
Did you go into bios and make sure secure boot set to UEFI and CSM is disabled?

garlin · Sep 16, 2025

Here's a Mosby-compatible version of my script, which does a plain string match.

It's not 100% authoritative, since someone could create a single cert named:

Code:

Microsoft Corporation UEFI CA 2011 Microsoft Windows Production PCA 2011 Microsoft UEFI CA 2023 Windows UEFI CA 2023 Mosby

UPDATE 2025-09-25: Removed script. The reported failure of the original script was traced back to an user misunderstanding on how to properly use the Mosby tool.

garlin · Sep 16, 2025

AK6DN said:
IDK I used Mosby v2.3 release from Jun 11 2025. Everything works fine on my system, it is the Check_EFIBootFile.ps1 script that is misbehaving.

You shouldn't say the script is misbehaving... The script uses a 3rd-party GitHub function that's been published and referenced in UEFI circles. It's never failed me until encountering this PC's output.

AK6DN · Sep 16, 2025

KevTech said:
Glad I just used Microsoft instruction instead of Mosby.
Did you go into bios and make sure secure boot set to UEFI and CSM is disabled?

Yes, secure boot is set to to UEFI and CSM is disabled. It does secure boot to Win10 no problem.

Mosby has an option to insert new private platform key certificates unique to your system when updating the standard cert's.
You can enable it or not. I enabled it, so it overwrote the standard manufacturer BIOS resident key certificates.
That is what the 'MosbyKey' is that is causing the Check_EFIBootFile.ps1 script to go sideways.
There is also the option in Mosby to leave the current system BIOS certificates alone (maybe that would have been a better choice IDK).
If I get up enough energy and courage to (possibly) brick my system (IDK) I may try resetting the BIOS to default keys and rerun Mosby
to not generate new keys but use the existing BIOS keys. We;ll see,

AK6DN · Sep 17, 2025

garlin said:
Here's a Mosby-compatible version of my script, which does a plain string match.

It's not 100% authoritative, since someone could create a single cert named:

Code:

Microsoft Corporation UEFI CA 2011 Microsoft Windows Production PCA 2011 Microsoft UEFI CA 2023 Windows UEFI CA 2023 Mosby

Well, it is not generating what I would expect to see. Here is the original output I saw from your original script (left),
and the output just now from your revised Mosby-compatible script.

Originally I saw 2xKEK 4xDB 0xDBX entries (left). Now I see 0xKEK 4xDB 4xDBX entries (right). DB and DBX entries are the same. KEK entries are gone.

Code:

C:\WINDOWS\system32>powershell -nop -ep bypass -f D:\Check_EFIBootFile\CheckCertificates.ps1

DEBUG:    3+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK CA 2011'
True
DEBUG:    4+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
True
DEBUG:    5+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Mosby'
False

DEBUG:    7+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'
True
DEBUG:    8+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Windows Production PCA 2011'
True
DEBUG:    9+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2023'
True
DEBUG:   10+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
True
DEBUG:   11+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Mosby'
True

DEBUG:   13+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Corporation UEFI CA 2011'
False
DEBUG:   14+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
False
DEBUG:   15+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft UEFI CA 2023'
False
DEBUG:   16+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Windows UEFI CA 2023'
False
DEBUG:   17+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Mosby'
False

C:\WINDOWS\system32>pause done
Press any key to continue . . .

garlin · Sep 17, 2025

Oops. My bad, copy & paste error. Re-download the script again.

AK6DN · Sep 17, 2025

garlin said:
Oops. My bad, copy & paste error. Re-download the script again.

Ok, lets try again ... here is what the updated script produces ... exact same as your original script produced for me yesterday,
but now with the addition of the 'Mosby' DB certificate entry.

IDK why after using Mosby and rebooting the system yesterday and running your original script there was no Mosby entry.
But today for some reason IDK why there is now a Mosby entry in DB. Why it magically appeared overnight IDK.

Thanks for all your help in getting this resolved.

Code:

C:\WINDOWS\system32>powershell -nop -ep bypass -f D:\Check_EFIBootFile\Check_Mosby_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 Windows Production PCA 2011
    Microsoft UEFI CA 2023
    Windows UEFI CA 2023
    Mosby

UEFI DBX Certs
--------------

EFI Files
---------
    Disk 1: Boot Manager [Production PCA 2011] is ALLOWED.

    Registry: WindowsUEFICA2023Capable = 1
        [Windows UEFI CA 2023] is in UEFI DB.

C:\WINDOWS\system32>pause done

garlin · Sep 17, 2025

This is a provisional workaround, it's not a fix. I can't read the full name of the Mosby cert until the parsing issue gets resolved.
Checking a raw binary object for expected substrings is very security challenged.

Almighty1 · Sep 17, 2025

Speaking about Mosby, anyone here actually using a Dell machine because on my Dell XPS 15 9570 which has the following layout:

I had it on Audit Mode and I tried both Enable Custom Mode enabled and disabled under Expert Key Management and in all instances, all I get is:
"Failed to set Secure Boot variable: Security Boot violation" even after setting Secure Boot Enable to off:

@KevTech - What exactly is CSM as I had been seeing that when I search on Google but I am not sure if my bios setup even has that option.

Scott · Sep 17, 2025

@Almighty1

I also read that on Dell systems CSM is called Legacy Option ROMs, maybe under General>Advanced boot options.

Almighty1 · Sep 17, 2025

Scott said:
@Almighty1
View attachment 145668

I also read that on Dell systems CSM is called Legacy Option ROMs, maybe under General>Advanced boot options.

Thanks, that is unchecked already.

RJARRRPCGP · Sep 17, 2025

Almighty1 said:
Thanks, that is unchecked already.

Yeah, on ASRock B550 PG Velocita, that bull pucky is enabled by default!

OTOH, on Asus ROG Strix B550-F Gaming, CSM is not enabled by default.

antspants · Sep 18, 2025

So yesterday I used the microsoft corporation kek 2k ca 2023.der Garlin provided and loaded it in my BIOS. I could only do it via BLOB (Whatever that is, as the other secure (whatever) option failed

Code:

Secure Boot: ON
BitLocker on (C:) OFF

UEFI KEK Certs
--------------
    Microsoft Corporation KEK CA 2011

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

UEFI DBX Certs
--------------

EFI Files
---------
    Disk 4: 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.

And now I see this from Microsoft, what is it and should it be added as I cannot see it in the UEFI KEK Certs above?

Microsoft Corporation KEK 2K CA 2023
microsoft corporation kek 2k ca 2023.crt

SHA-1 cert hash: 459AB6FB5E284D272D5E3E6ABC8ED663829D632B.
SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
Microsoft will provide the certificate to partners and it can be added either as an EFI_CERT_X509_GUID or an EFI_CERT_RSA2048_GUID type signature.
The Microsoft KEK certificate can be downloaded from: [URL]https://go.microsoft.com/fwlink/?linkid=2239775[/URL]

antspants · Sep 18, 2025

mccmw said:
My check cert output looks just like yours after running the script at the beginning of this thread. I assume I need the 2023 cert under KEK as well? If so, what is the safe way/commands/script to do that? Thanks.

It’s just a query on my part, it maybe should be ignored and will sort itself out by a Windows Updat or load of an ISO with the correct Cert.
But yeah, I’d like to know. also.

antspants · Sep 18, 2025

antspants said:
Microsoft will provide the certificate to partners and it can be added either as an EFI_CERT_X509_GUID or an EFI_CERT_RSA2048_GUID type signature.

I’m guessing it’s for vendors and the likes, for inclusion in BIOS updates and what not.

mccmw · Sep 18, 2025

Here is my output:

D:\Downloads>powershell -nop -ep bypass -f Check_EFIBootFile.ps1
Secure Boot: ON
BitLocker on (C:) OFF

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011

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

UEFI DBX Certs
--------------

EFI Files
---------
Disk 0: Boot Manager [Production PCA 2011] is ALLOWED.

Registry: WindowsUEFICA2023Capable = 1
[Windows UEFI CA 2023] is in UEFI DB.

Do I need to take any further action? I noticed earlier that someone also had a Microsoft UEFI CA 2023 certificate, and there is a KEK as well. Are those necessary and, if so, what are the commands to install/update those? Much appreciated to everyone helping out in this thread.

Almighty1 · Sep 18, 2025

Almighty1 said:
Speaking about Mosby, anyone here actually using a Dell machine because on my Dell XPS 15 9570 which has the following layout:
View attachment 145642
View attachment 145643
View attachment 145644
View attachment 145645
I had it on Audit Mode and I tried both Enable Custom Mode enabled and disabled under Expert Key Management and in all instances, all I get is:
"Failed to set Secure Boot variable: Security Boot violation" even after setting Secure Boot Enable to off:
View attachment 145646

@KevTech - What exactly is CSM as I had been seeing that when I search on Google but I am not sure if my bios setup even has that option.

I got it working thanks to someone answering my question on reddit at:

https://www.reddit.com/r/archlinux/comments/ut78iq/comment/neuiwqt

Basically, Setup Mode on the Dell is basically:
Secure Boot Enabled = off, Audit Mode, Delete All keys in Expert Key Management after enabling Custom Mode.

However, I ran into a different issue when I did:
Secure Boot Enabled = on, Deployment Mode which is needed so system boots with Secure Boot Mode = On, Expert Key Management after enabling Custom Mode:

Anyone have a script to check what Platform Keys is actually on the system?

Script provided by @garlin in post here:

Act now: Secure Boot certificates expire in June 2026

UPDATE: https://www.elevenforum.com/t/updating-microsoft-secure-boot-keys-before-expiration-in-june-2026.22477/ Windows IT Pro Blog: Prepare for the first global large-scale certificate update to Secure Boot. The Microsoft certificates used in Secure Boot are the basis of trust for operating...

www.elevenforum.com

Mosby works but I am still missing the Microsoft Option ROM UEFI CA 2023

Update:
I used secureboot_objects/PostSignedObjects/Optional/DB/amd64/DBUpdateOROM2023.bin at main · microsoft/secureboot_objects and amended db from file in Custom Keys in the UEFI BIOS Setup to get the Microsoft Option ROM UEFI CA 2023 installed.

garlin · Sep 19, 2025

OK. I found a possible explanation for the "exactly 16 bytes" error:

https://gist.github.com/out0xb2/f8e...malink_comment_id=4552082#gistcomment-4552082

If you get the error:

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

Click to expand...

...it's because your passing the wrong '.bin' file, like 'x64_DBXUpdate.bin'.

That leads me to believe possibly the wrong file got pushed.

antspants · Sep 19, 2025

I have no idea if I am progressing...

Code:

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 Windows Production PCA 2011
    Windows UEFI CA 2023

UEFI DBX Certs
--------------

EFI Files
---------
    Disk 4: 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.

Bootable Media
--------------
    USB J: ""

antspants · Sep 19, 2025

[Windows UEFI CA 2023] is in UEFI DB, and Windows is starting from CA 2023 Boot Manager.

No boot manager repair needed

Did you manually update your Secure Boot Keys ?

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

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

My Computers

Like a rolling drone.

My Computers

Like a rolling drone.

My Computers

Like a rolling drone.

My Computers

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Like a rolling drone.

My Computers

Like a rolling drone.

My Computers

Similar threads