Did you manually update your Secure Boot Keys ?

Almighty1 · 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...

I thought it was a PK because from what @garlin told me to do in the comment 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

I tried it using the Reset to Default keys and this is what it showed:

and then this is what it showed when Mosby was ran:

So at least that command is showing Mosby as a Generated PK but I am not having problems.

The only problem I am having is how to use the -db switch as I tried:

Mosby -db microsoftoptionromuefica2023.der
with the file on the UEFI Shell Drive which popped up a screen saying security violation and I needed to get to Setup mode again if I choose yes but Setup mode on Dell means deleting all the keys or the PK.

So what I ended up doing was as you had mentioned I can use DBUpdateOROM2023.bin so the methods which I tried is the UEFI Custom Key Management where I did a Amend from file and it added it without any issues. Just trying to learn how to use the -db switch so it can add the DB to the existing Mosby added keys.

AK6DN · Sep 24, 2025

Indeed I see Mosby entries in both DB and PK databases on my system ...

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:   19+  >>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI pk).bytes) -match 'Mosby Generated PK'
True

DEBUG:   21+  >>>> [System.Text.RegularExpressions.Regex]::Replace([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).Bytes), '[^\w\s]', '')
YJrF
Y00h
05091500H000Z20550914235959Z010U♀Mosby Generated PK 2025091500
NglZ7
nXI8VXoSOhLI  rFIFf23aeclrG52
bq3ocjqz_9Ne2FKXxlOCbekW0P13V6dBqSm8tQPV♀plO3

C:\WINDOWS\system32>pause done

Akeo · Sep 24, 2025

1. Mosby being in the text of the PK is normal (because, we want to identify that the PK was generated by the Mosby application). But it doesn't mean it's the MosbyKey (which it isn't). As a matter of fact if you look at the Canonical Name (CN) of the MosbyKey cert, you will find that it's different from the CN of the PK, which, as you found above, is Mosby Generated PK <YYYYMMDD>. Please don't be surprised to see the Mosby name reused in data created by an application with that name. The fact that the DB credentials are called MosbyKey is unrelated to the PK having Mosby in its name. It just means that both were generated by Mosby. It'd be like calling one key PK Key and the other DB Key and then trying to state that "Well, These must be the same, because they have 'Key' in their name", which is not correct. We're just very deliberately identifying all the stuff that's been generated by Mosby by making sure it does state "Mosby" somewhere in it, even if it's completely independent certs/creds used for completely different purposes.

2. I'm trying to test the DB MosbyKey, but for some strange reason, despite Get-SecureBootUEFI db reporting 4 certs (and the UEFI firmware settings also reporting that 4 certs are present in DB), as evidenced in the output I posted earlier, the Check_EFIBootFile.ps1 script only reports 3 on my platform and appears to leave out the MobsyKey DB variable entirely...

AK6DN · Sep 24, 2025

Akeo said:
2. I'm trying to test the DB MosbyKey, but for some strange reason, despite Get-SecureBootUEFI db reporting 4 certs, as evidenced in the output I posted earlier, the Check_EFIBootFile.ps1 script only reports 3 on my platform and appears to leave out the MobsyKey DB variable entirely...

After originally running Mosby, the first time I rebooted and ran the Check_EFIBootFile.ps1 script it worked OK, did not fail, and reported
only the expected entries. I saved the output, and here it is ...

Code:

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

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

it was only later after another reboot that when I ran this same script it now failed, because a MosbyKey entry appeared
under the DB category, and the script complained about the format of that entry being invalid. Here is what I got then....

Code:

C:\WINDOWS\system32>powershell -nop -ep bypass -f D:\Check_EFIBootFile\Check_EFIBootFile_Mosby.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
    MosbyKey

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
Press any key to continue . . .

using the 'Mosby' flavor of the script.

Akeo · Sep 24, 2025

AK6DN said:
I saved the output, and here it is ...

Thanks, because this also appears to confirm what I am seeing.

AK6DN said:

Code:

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

Well, since you did not use option -x on this run (since PCA 2011 is in the DB) there should actually be 5 certs listed here, and not 4, in the same way as on my platform (with -x, and therefore without PCA 2011 in the DB) there should be 4 instead of 3. Yet the Mosby DB cert is not listed by the script, despite being reported by Get-SecureBootUEFI db (at least in my case, and if Mosby did ran without producing an error, you should also have had Mosby cert listed)...

So this appears to confirms at least one of the issue I am seeing with the PS1 script, even if somehow you later managed to get the DB MosbyKey cert listed.

I am planning to investigate this some more, but it might take a little while.

AK6DN · Sep 24, 2025

Akeo said:
Thanks, because this also appears to confirm what I am seeing.

Well, since you did not use option -x on this run (since PCA 2011 is in the DB) there should actually be 5 certs listed here, and not 4, in the same way as on my platform (with -x, and therefore without PCA 2011 in the DB) there should be 4 instead of 3. Yet the Mosby DB cert is not listed by the script, despite being reported by Get-SecureBootUEFI db (at least in my case, and if Mosby did ran without producing an error, you should also have had Mosby cert listed)...

So this appears to confirms at least one of the issue I am seeing with the PS1 script, even if somehow you later managed to get the DB MosbyKey cert listed.

I am planning to investigate this some more, but it might take a little while.

I booted and ran Mosby exactly one time. And I used no command line options when invoking it in the UEFI shell.

garlin · Sep 24, 2025

The last released script only filters for "Microsoft", I've changed it to include Microsoft or Mosby.

Code:

262 try {
263     $KEK_Certs = @((Get-SecureBootUEFI KEK | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
264     $db_Certs  = @((Get-SecureBootUEFI db  | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
265     $dbx_Certs = @((Get-SecureBootUEFI dbx | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
266 }

neldog · Sep 24, 2025

garlin said:

The last released script only filters for "Microsoft", I've changed it to include Microsoft or Mosby.

Code:

262 try {
263     $KEK_Certs = @((Get-SecureBootUEFI KEK | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
264     $db_Certs  = @((Get-SecureBootUEFI db  | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
265     $dbx_Certs = @((Get-SecureBootUEFI dbx | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
266 }

Is there a link for your new script? I'm just wondering. Thanks.

garlin · Sep 24, 2025

neldog said:
Is there a link for your new script? I'm just wondering. Thanks.

Not yet, because you guys keep jumping faster than I can do reasonable testing.
Remember, this thread started with "How do we do the update by following MS's exact instructions?".

But you can scroll down this block:

Code:

    $KEK_Certs = @((Get-SecureBootUEFI KEK | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
    $db_Certs  = @((Get-SecureBootUEFI db  | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
    $dbx_Certs = @((Get-SecureBootUEFI dbx | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })

And replace those lines with:

Code:

    $KEK_Certs = @((Get-SecureBootUEFI KEK | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
    $db_Certs  = @((Get-SecureBootUEFI db  | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })
    $dbx_Certs = @((Get-SecureBootUEFI dbx | Get-UefiDatabaseSignatures).SignatureList.SignatureData.Subject | where { $_ -match 'Microsoft|Mosby' } | foreach { $null = $_ -match $CN_regex; $Matches[2] })

garlin · Sep 24, 2025

Almighty1 said:
I thought it was a PK because from what @garlin told me to do in the comment 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

No. I said I can't figure out why the PS function doesn't decipher the returned bytes from the PK variable. There's a spec for the encoding format, so I didn't expect a proper tool like Mosby to help create an error. Now that it's strongly believed to be an usage error, it makes sense.

The "Mosby-only" script was a workaround until @Akeo was available to answer questions. There shouldn't be two versions of the script, the original should have worked in the first place. It threw an error, but since I'm not an UEFI expert, it wasn't possible for me to understand what would be the reason.

Let's remember this thread started with "this is how MS wants you to proceed", and the original script helped to address that approach. I didn't test with Mosby because most of the users are following the official Windows guide, or people who are giving the same advice.

Akeo · Sep 24, 2025

As far as I can tell, this looks like a script issue then.

For people experiencing the issue, please download the original Check-UEFISecureBootVariables/Get-UEFIDatabaseSignatures.ps1 at main · cjee21/Check-UEFISecureBootVariables and then run the following from an elevated powershell (in the same directory where you have the .ps1):

Code:

. .\Get-UefiDatabaseSignatures.ps1
Get-SecureBootUEFI db | Get-UefiDatabaseSignatures | Format-List

On my system, I see no issue whatsoever, and it properly reports the MosbyKey DB cert (along with its SignatureOwner GUID):

Code:

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


SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=45a0fa32-6047-73c8-2433-c3b7d59e7466; SignatureData=[Subject]
                  CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US

                [Issuer]
                  CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Serial Number]
                  330000001A888B9800562284C100000000001A

                [Not Before]
                  13/06/2023 19:58:29

                [Not After]
                  13/06/2035 20:08:29

                [Thumbprint]
                  45A0FA32604773C82433C3B7D59E7466B3AC0C67
                }

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=46def63b-5ce6-1cf8-ba0d-e2e6639c1019; SignatureData=[Subject]
                  CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Issuer]
                  CN=Microsoft Corporation Third Party Marketplace Root, O=Microsoft Corporation, L=Redmond,
                S=Washington, C=US

                [Serial Number]
                  6108D3C4000000000004

                [Not Before]
                  27/06/2011 22:22:45

                [Not After]
                  27/06/2026 22:32:45

                [Thumbprint]
                  46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3
                }

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=b5eeb4a6-7060-4807-3f0e-d296e7f580a7; SignatureData=[Subject]
                  CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US

                [Issuer]
                  CN=Microsoft RSA Devices Root CA 2021, O=Microsoft Corporation, C=US

                [Serial Number]
                  330000001636BF36899F1575CC000000000016

                [Not Before]
                  13/06/2023 20:21:47

                [Not After]
                  13/06/2038 20:31:47

                [Thumbprint]
                  B5EEB4A6706048073F0ED296E7F580A790B59EAA
                }

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=73e4ab21-55a9-2ab6-9a33-82c77f95acda; SignatureData=[Subject]
                  CN=MosbyKey [2025.09.09]

                [Issuer]
                  CN=MosbyKey [2025.09.09]

                [Serial Number]
                  68BF72A9

                [Not Before]
                  09/09/2025 01:00:00

                [Not After]
                  09/09/2055 00:59:59

                [Thumbprint]
                  73E4AB2155A92AB69A3382C77F95ACDA537CAEEC
                }



PS C:\SB>

garlin · Sep 24, 2025

Akeo said:
As far as I can tell, this looks like a script issue then.

For people experiencing the issue, please download the original Check-UEFISecureBootVariables/Get-UEFIDatabaseSignatures.ps1 at main · cjee21/Check-UEFISecureBootVariables and then run the following from an elevated powershell (in the same directory where you have the .ps1):

Code:

. .\Get-UefiDatabaseSignatures.ps1 Get-SecureBootUEFI db | Get-UefiDatabaseSignatures | Format-List

On my system, I see no issue whatsoever, and it properly reports the MosbyKey DB cert (along with its SignatureOwner GUID):

Code:

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

It's not an issue, but a design choice. At the time, this thread was focused on following the MS guides. And so I filtered only for MS certs, because Mosby or other means didn't enter the thread. I realize there's a lot more possible certs that exist, but they're not relevant to the Secure Boot revocation for Windows.

My original question is still valid, what would cause the borrowed function to barf on "malformed" byte data? If the user can end up doing something bad, ideally a tool should try its best to protect against it. The script threw an exception like it's supposed to, I just couldn't confidently say "well you did something weird, because I don't see the same problems".

gunrunnerjohn · Sep 24, 2025

Akeo said:
As far as I can tell, this looks like a script issue then.

For people experiencing the issue, please download the original Check-UEFISecureBootVariables/Get-UEFIDatabaseSignatures.ps1 at main · cjee21/Check-UEFISecureBootVariables and then run the following from an elevated powershell (in the same directory where you have the .ps1):

Code:

. .\Get-UefiDatabaseSignatures.ps1 Get-SecureBootUEFI db | Get-UefiDatabaseSignatures | Format-List

I'm obviously doing something wrong.

neldog · Sep 24, 2025

garlin said:
Not yet, because you guys keep jumping faster than I can do reasonable testing.
Remember, this thread started with "How do we do the update by following MS's exact instructions?".

Okay, lol

, I hear you.

I was kind of scared to ask because I knew we were hitting you hard. You are doing excellent work and we, I, appreciate it. Thanks for all you are doing.

garlin · Sep 24, 2025

gunrunnerjohn said:
I'm obviously doing something wrong.

He's talking about the original PS function in standalone form. It's embedded in my script, but I filtered the output to only return MS certs.

gunrunnerjohn · Sep 24, 2025

garlin said:
He's talking about the original PS function in standalone form. It's embedded in my script, but I filtered the output to only return MS certs.

I was referring to the instructions presented...

I put the script downloaded in a folder, then I opened an admin PS windows and changed to that folder. I ran the two lines one at a time and just pasting them in. I always get an error. I know I'm doing something stupid, just not sure what it is.

Akeo said:
As far as I can tell, this looks like a script issue then.

For people experiencing the issue, please download the original Check-UEFISecureBootVariables/Get-UEFIDatabaseSignatures.ps1 at main · cjee21/Check-UEFISecureBootVariables and then run the following from an elevated powershell (in the same directory where you have the .ps1):

Code:

. .\Get-UefiDatabaseSignatures.ps1 Get-SecureBootUEFI db | Get-UefiDatabaseSignatures | Format-List

Akeo · Sep 24, 2025

gunrunnerjohn said:
I'm obviously doing something wrong.

The obvious would be that your .ps1 script was not downloaded in C:\Users\<whatever you hid>\ whereas you are trying to run the command from there. Please make sure to cd to the directory where you actually downloaded the script...

The error tells you very explicitly that either:
- The script was not found in the current directory
- The script was not saved under the Get-UefiDatabaseSignatures.ps1 name, as it should be.

Oh and you'll probably run into the PS script execution policy restrictions, in which case I would advise to google how to to allow PS1 script execution.

AK6DN · Sep 24, 2025

gunrunnerjohn said:
I was referring to the instructions presented...

I put the script downloaded in a folder, then I opened an admin PS windows and changed to that folder. I ran the two lines one at a time and just pasting them in. I always get an error. I know I'm doing something stupid, just not sure what it is.

I was able to run it and got the following results. Had to play with script execution policy to get it to run.

Code:

PS D:\> Set-ExecutionPolicy -ExecutionPolicy Bypass

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the
about_Execution_Policies help topic at https:/go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): Y
PS D:\>
PS D:\> Get-ExecutionPolicy -list

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine          Bypass

PS D:\> . .\Get-UEFIDatabaseSignatures.ps1
PS D:\> Get-SecureBootUEFI db | Get-UefiDatabaseSignatures | Format-List

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=45a0fa32-6047-73c8-2433-c3b7d59e7466; SignatureData=[Subject]
                  CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US

                [Issuer]
                  CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Serial Number]
                  330000001A888B9800562284C100000000001A

                [Not Before]
                  2023-06-13 11:58:29

                [Not After]
                  2035-06-13 12:08:29

                [Thumbprint]
                  45A0FA32604773C82433C3B7D59E7466B3AC0C67
                }

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=46def63b-5ce6-1cf8-ba0d-e2e6639c1019; SignatureData=[Subject]
                  CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Issuer]
                  CN=Microsoft Corporation Third Party Marketplace Root, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Serial Number]
                  6108D3C4000000000004

                [Not Before]
                  2011-06-27 14:22:45

                [Not After]
                  2026-06-27 14:32:45

                [Thumbprint]
                  46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3
                }

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=580a6f4c-c4e4-b669-b9eb-dc1b2b3e087b; SignatureData=[Subject]
                  CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Issuer]
                  CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Serial Number]
                  61077656000000000008

                [Not Before]
                  2011-10-19 11:41:42

                [Not After]
                  2026-10-19 11:51:42

                [Thumbprint]
                  580A6F4CC4E4B669B9EBDC1B2B3E087B80D0678D
                }

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=b5eeb4a6-7060-4807-3f0e-d296e7f580a7; SignatureData=[Subject]
                  CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US

                [Issuer]
                  CN=Microsoft RSA Devices Root CA 2021, O=Microsoft Corporation, C=US

                [Serial Number]
                  330000001636BF36899F1575CC000000000016

                [Not Before]
                  2023-06-13 12:21:47

                [Not After]
                  2038-06-13 12:31:47

                [Thumbprint]
                  B5EEB4A6706048073F0ED296E7F580A790B59EAA
                }

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=fa139a54-feeb-6888-a581-8f29bc144fd5; SignatureData=[Subject]
                  CN=MosbyKey [2025.09.15]

                [Issuer]
                  CN=MosbyKey [2025.09.15]

                [Serial Number]
                  68C82F09

                [Not Before]
                  2025-09-14 17:00:00

                [Not After]
                  2055-09-14 16:59:59

                [Thumbprint]
                  FA139A54FEEB6888A5818F29BC144FD551CD3163
                }

PS D:\> Get-SecureBootUEFI kek | Get-UefiDatabaseSignatures | Format-List

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=31590bfd-89c9-d74e-d087-dfac66334b39; SignatureData=[Subject]
                  CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Issuer]
                  CN=Microsoft Corporation Third Party Marketplace Root, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Serial Number]
                  610AD188000000000003

                [Not Before]
                  2011-06-24 13:41:29

                [Not After]
                  2026-06-24 13:51:29

                [Thumbprint]
                  31590BFD89C9D74ED087DFAC66334B3931254B30
                }

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=459ab6fb-5e28-4d27-2d5e-3e6abc8ed663; SignatureData=[Subject]
                  CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US

                [Issuer]
                  CN=Microsoft RSA Devices Root CA 2021, O=Microsoft Corporation, C=US

                [Serial Number]
                  33000000131416B8616D82824B000000000013

                [Not Before]
                  2023-03-02 12:21:35

                [Not After]
                  2038-03-02 12:31:35

                [Thumbprint]
                  459AB6FB5E284D272D5E3E6ABC8ED663829D632B
                }

PS D:\> Get-SecureBootUEFI pk | Get-UefiDatabaseSignatures | Format-List

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=0a3ca81f-3b27-5cfc-a585-592bb010e2d8; SignatureData=[Subject]
                  CN=Mosby Generated PK [2025.09.15]

                [Issuer]
                  CN=Mosby Generated PK [2025.09.15]

                [Serial Number]
                  68C82F0A

                [Not Before]
                  2025-09-14 17:00:00

                [Not After]
                  2055-09-14 16:59:59

                [Thumbprint]
                  0A3CA81F3B275CFCA585592BB010E2D88BD17729
                }

PS D:\>

gunrunnerjohn · Sep 24, 2025

Well, I did say I was obviously doing something wrong. :think:

Almighty1 · Sep 24, 2025

Akeo said:
1. Mosby being in the text of the PK is normal (because, we want to identify that the PK was generated by the Mosby application). But it doesn't mean it's the MosbyKey (which it isn't). As a matter of fact if you look at the Canonical Name (CN) of the MosbyKey cert, you will find that it's different from the CN of the PK, which, as you found above, is Mosby Generated PK <YYYYMMDD>. Please don't be surprised to see the Mosby name reused in data created by an application with that name. The fact that the DB credentials are called MosbyKey is unrelated to the PK having Mosby in its name. It just means that both were generated by Mosby. It'd be like calling one key PK Key and the other DB Key and then trying to state that "Well, These must be the same, because they have 'Key' in their name", which is not correct. We're just very deliberately identifying all the stuff that's been generated by Mosby by making sure it does state "Mosby" somewhere in it, even if it's completely independent certs/creds used for completely different purposes.

2. I'm trying to test the DB MosbyKey, but for some strange reason, despite Get-SecureBootUEFI db reporting 4 certs (and the UEFI firmware settings also reporting that 4 certs are present in DB), as evidenced in the output I posted earlier, the Check_EFIBootFile.ps1 script only reports 3 on my platform and appears to leave out the MobsyKey DB variable entirely...

Thanks for the clarification. Here is a question, since to get Setup mode to work, the PK key has to be deleted first per UEFI specifications. So when Mosby is used as no keys exist, what PK key is actually installed on the system?

Did you manually update your Secure Boot Keys ?

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

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

Well-known member

My Computers

Well-known member

My Computer

Similar threads