Did you manually update your Secure Boot Keys ?

mccmw said:

However, I was only partially successful on a Dell XPS 9350 laptop that my kids use for educational stuff. (...) I ran "Mosby" and got messages on some certificates installing, but an error at the end that a Secure Boot parameter was invalid. I restarted and went to reenable Secure Boot in the BIOS...I got the message that a Platform key was missing and that while Secure Boot would turn on, it would not be enabled.

Click to expand...

This is most likely the same issue as ASUS GL502VS: Failed to set Secure Boot variable: Invalid Parameter · Issue #14 · pbatard/Mosby (for which we will have a workaround in the next version of Mosby).

By the look of it, AMI introduced a bug in the UEFI firmware they shipped to manufacturers such as ASUS, Dell, Lenovo, MSI, about 10 years ago, that actively prevents some Secure Boot databases, such as the KEK, from being appended at all. This means that, if you try to run the current version of Mosby on such a problematic platform, it will fail when trying to append the 2023 KEK (and therefore also not write the PK, and therefore lead you to a system that reports that no PK has been installed).

From my limited testing, it also appears that such systems are also unable to complete the Secure Boot CA 2023 certificate updates from Windows itself, which is quite concerning (though, as I said earlier, the next version of Mosby should be able to accomplish that even if Windows can't), which isn't entirely surprising considering that Linux is also reporting a similar issue on affected platforms when performing a similar update with fwupdmgr...

All in all, I am starting to see quite a few reports from people running into this issue, which leads me to think that, as the 2026 "deadline" approaches, Microsoft and the affected manufacturers (as well as AMI) are going to have no choice but to issue some kind of statement about what they are planning to do to address this problem (which the cynical in me thinks is probably going to boil down to "We acknowledge there is a problem, but we're not going to do anything").

@hader and XxXxX...When I get a chance I'll try again using your steps and see if something changes. As Buddywh just mentioned my assumption was that creating and running Mosby (following the instructions exactly) was a solution for machines/motherboards that are no longer supported with BIOS updates. Thanks all for responding...I know the easy solution is just to buy a new machine...but my kids are younger...and they are using this particular laptop for education stuff...nor would I trust them (yet) on a newer/expensive machine:)

I'm just confused because Mosby ran just fine on an even older re-purposed HP laptop running Linux Mint. I was a little apprehensive about Mosby...so I used this machine in case something went wrong. It completed...I expect it to work if I ever wanted to install Windows 11 24H2+ on it.

I've also run "manual" scripts on the other machines in my household with mixed results. Either by BIOS update, or the manual scripts on a Dell XPS 15 9510 I ran prior have current 2023 KEK, PK, and DB certs installed and Windows 11 using the 2023 certificate. Likewise, a older desktop (Asus Z270/Intel i7-7700K) responded positively to manual commands and is in the same situation. I believe the only steps either of these machines requires is revocation of 2011 certificates when it's time. I ran the commands on a 2-year old HP Envy laptop (wife's) and I could get the certificates installed (excpet KEK again)...that one I suspect will get fixed via a future BIOS update.

mccmw said:

was a solution for machines/motherboards that are no longer supported with BIOS updates

Click to expand...

A possible solution only... nothing's universal in this world and most (least?) of all in the computing world where all the mfr's play fast and loose with "standards".

As @Akeo brought to our attention in the post just prior to yours, the inability to update KEK's potentially extends beyond simply getting a KEK signed by your system's PK. That may or may not be what's causing people's problems here, it just clearly illustrates my point above.

Buddywh said:

I think it's a little more nuanced....

The Microsoft UEFI 2023 KEK distributed with these secure boot updates is issued by Microsoft Corp and then signed by the system (or motherboard) manufacturer using the system's PK that they control and then returned to Microsoft to be distributed in their updates. It is also included in BIOS updates by the manufacturer.

That seems to be the reason for at least some of the problems people have experienced getting KEK's for systems where the OEM has decided to not support.

Click to expand...

Yes the documents are vague on that point that x.509 or RSA-2048 certificate can be supplied by the OEM or Windows. It seems to me that that update scripts that cjee21 is using to solve CA2023 issues and address UEFI DB and UEFI DBX updates only. Not EUFI PK or KEK. In my case they both where ok, due to a BIOS update sometime back. (?) As of now it seems that Windows don't address EUFI PK, KEK issues otherwise we should see scripts that solves those issues also.

hader said:

As of now it seems that Windows don't address EUFI PK, KEK issues otherwise we should see scripts that solves those issues also.

Click to expand...

There's not likely a whole lot Microsoft can do for people with non-compliant UEFI BIOS' when the OEM won't support with an update. I'm thinking the cynical solutions may prevail in many cases, which can go as far as just disabling Secure Boot if you want to continue using the hardware.

And if your machine has gotten the 2023 keys I wouldn't worry too much about getting the DBX updates. They will eventually come with Windows' updates as Microsoft routinely (if not frequently) manages SVN revocations.

Wasn't there a post somewhere that stated Dell will not do any bios updates to a lot of laptops

Buddywh said:

I think it's a little more nuanced....

The Microsoft UEFI 2023 KEK distributed with these secure boot updates is issued by Microsoft Corp and then signed by the system (or motherboard) manufacturer using the system's PK that they control and then returned to Microsoft to be distributed in their updates. It is also included in BIOS updates by the manufacturer.

That seems to be the reason for at least some of the problems people have experienced getting KEK's for systems where the OEM has decided to not support.

Click to expand...

My System One - Dell and System Two - Microsoft were automagically updated long ago!

@hader and XxXxX,

No joy. I just ran everything (Parts A and B) with 5-minute intervals between (and between reboots). Here is the screenshot result:

man00 said:

Wasn't there a post somewhere that stated Dell will not do any bios updates to a lot of laptops

Click to expand...

Here are the Dell computers that have and will have BIOS and those that do not:

itsme1 said:

Here are the Dell computers that have and will have BIOS and those that do not:

Microsoft 2011 Secure Boot Certificate Expiration | Dell US

Microsoft 2011 Secure Boot Certificates Expiration for Out of Scope Platforms for BIOS Updates | Dell US

Click to expand...

Thanks...that confirmed what I figured...no BIOS update coming. It is an ancient laptop:)

mccmw said:

@hader and XxXxX,

No joy. I just ran everything (Parts A and B) with 5-minute intervals between (and between reboots). Here is the screenshot result:

View attachment 156138

Click to expand...

according to that data the 2023 cert is now in the data base
so part A of the secure boot update HowTo has worked

it took another forum member several attempts at part B
for part B to work and have the system boot from the 2023 cert.

#####
so please attempt part B again
> first command in an elevated Command Prompt
> then the second command in an elevated PowerShell

give it about 5 minutes before the required restart
then check this registry key
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

in the right Window you will see ..
UEFICA2023Status which will now show 'Updated' or 'InProgress'
WindowsUEFICA2023Capable 0x00000002


best of luck Steve ..

I followed the instructions carefully and now I need to know why?
-

Pnokio said:

I followed the instructions carefully and now I need to know why?
-
View attachment 156143

Click to expand...

please try opening an elevated PowerShell and/or Command prompt as Administrator and then try the commands.

best of luck Steve ..

I used the Power Shell method.

Pnokio said:

I used the Power Shell method.

Click to expand...

link too the HowTo .. note .. your system must be online and connected to the internet.

both commands in Part A of the HowTo are run in an Administrator PowerShell
one after the other. it maybe worthwhile leaving about 5 minutes between commands
then restart the system TWICE. it maybe worthwhile leaving 5 minutes between restarts.

Part B
1> the first command in Part B is in an Administrator Command Prompt
after completing the first command close the Administrator Command Prompt

2> the second command in Part B is in an Administrator PowerShell
after completing the second command close the Administrator PowerShell

then restart the system

#####
once the system has been restarted then check this registry key
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

in the right Window you will see ..
UEFICA2023Status which will now show 'Updated'
WindowsUEFICA2023Capable 0x00000002


best of luck Steve ..

mccmw said:

@hader and XxXxX,

No joy. I just ran everything (Parts A and B) with 5-minute intervals between (and between reboots). Here is the screenshot result:

Click to expand...

Looks you EUFI DB is OK now. Now you have to fix EUFI DBX. (It's current values are the one that must be valid now. Default values are what the current value would be when reset) Did you looked at the article I wrote; How to check if your Secure Boot certs are updated. (two methods) ?
It looks to me that you must run (DOS-box, admin) "Apply DBX update (restart required).reg" and after a reboot a couple of times execute "schtasks /run /tn "\Microsoft\Windows\PI\Secure-Boot-Update" " to force the update to execute. Check on a regular interval again; "Check Windows state.cmd" to see if the status Updated will occur. When it says Updated; run "Check UEFI PK, KEK, DB and DBX.cmd"

Unfortunately I can nothing do about the UEFI KEK situation. That is something that has to solved by the OEM. (you're not the only one. Other people have also issues with Dell laptops) As you mentioned; The laptop is old; there is no chance that they will update your BIOS.

Since secure boot is an optional safety feature (it watches that crucial windows and driver files are not tampered with or loaded if something is suspicious) you have the option to turn off secure boot. Your system is then exposed to a certain risk, but if you have a good antivirusprogram; it will intercept viruses, trojans and watch for ransomware and monitors your internet activity. You laptop will function normally. (until Microsoft is pushing secure boot through everybody's throat. Unlikely...)

Note @mccmw: About the KEK issue; I saw a red cross (had trouble with reading because of the spaces issue in the screendump) at the item: "Microsoft Corporation KEK 2K CA 2023" The Dell UEFI PK and KEK of the manufacturer seems to alright; green. The current UEFI KEK from "Microsoft Corporation KEK 2K CA 2023" not. (red) I saw a document I thought would solve that issue also; Download the "Microsoft Corporation KEK 2K CA 2023" from Microsoft themself.

The doc: Windows Secure Boot Key Creation and Management Guidance

Search for Microsoft Corporation KEK 2K CA 2023. The .cer can be download by the link below. BUT... It's based on a root certificate Microsoft RSA Devices Root CA 2021 (valid until 2046) OEM's can use this to sign it based on the new CA 2023 certificate. So this is no use because that RSA certificate is not the Windows trusted certificate store. Use certmgr.msc to view all the root and intermediate certificates.

I think you have to wait until the CA2023 is implemented. This whole exercise was to prepare (on a non MS way) us until this certificate is re-signed for all programs (needs to be replaced by an Windows update) that needs be verified by the new CA2023 certificate. As far as I can see; all files now are still pointing to the old PCA 2011 certificate. The issue you can solve are the red crosses at the EUFI Current values at DB and DBX.

Retried Part A part 1, wait 5 min. Part A part 2 wait 5 min . Restart 1 wait 5 min. Restart 2
Entered into P Shell as Admin [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match "Windows UEFI CA 2023"
-
Got same result as #1,432

My Secure Boot is Enabled but not Active as in BIOS.
What does this mean????
-

Pnokio said:

Retried Part A part 1, wait 5 min. Part A part 2 wait 5 min . Restart 1 wait 5 min. Restart 2
Entered into P Shell as Admin [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match "Windows UEFI CA 2023"
-
Got same result as #1,432

Click to expand...

Remember; PowerShell must run as admin. As the screendump already said; Not enough privileges to execute the command. I don't see "Administrator: Powershell" in the powershell box screendump you are referring too. Correct it. The end-result must be; True or False.