Solved I am getting an error about the secure boot

epoch32 said:

Do I have to use the PK, KEK, DB, DBX from Microsoft ?

Click to expand...

MOSBY includes all of the Microsoft 2023 keys (including KEK) with it's distribution and loads them into firmware. You only have to dl MOSBY v2.8 from GitHUB and install it on a bootable UEFI shell USB, then run it after putting your system's Secure Boot into SETUP MODE. Read the instructions on GitHUB and the README's in the distribution.

But to Secure Boot Windows 11 you have to use Microsoft's secure boot chain of trust, therefore use Microsoft's keys. You can install your own chain of trust for other OS's, even creating/signing your own custom keys that work with your own custom boot loader; I am pretty sure there are more than a few Linux users who do just that.

But also, I'm not sure the registry entry you did is "final" for the Windows scheduled task to push ALL the keys into firmware. It may have more to come... or might not due to being problematic. But if your firmware can be updated, MOSBY will update all the keys and get latest SVN and revocations.

epoch32 said:

Do I have to use the PK, KEK, DB, DBX from Microsoft ?

Click to expand...

What method did you use to install the KEK on your Lenovo IdeaPad with an unsupported 7th generation Intel processor?

Dirtyflash said:

What method did you use to install the KEK on your Lenovo IdeaPad with an unsupported 7th generation Intel processor?

Click to expand...

fwupdmgr on linux, I had to reset to factory keys and that's it. It's an IdeaPad 320-14IKB running Fedora 42. It kept prompting me to install the uefi stuff but wouldn't when I reboot. I read somewhere that I had to reset the uefi keys to default before trying again and that's that.

Buddywh said:

I think other Acer Aspire owners have reported problems with updating / appending to the 2023 KEK key.

Have you tried MOSBY? It's author has reported there are several BIOS' he has run across that simply do not allow updating/appending to KEK. Whether due to poor UEFI implementation or by design it's obviously a problem for owners if the OEM/manufacturer has abandoned it for BIOS updates. He has implemented a work-around in v2.8 of MOSBY that can help in some cases.

A proper BIOS update would be best, but if all-else has failed and Acer isn't forthcoming with one this might be worth trying.

Click to expand...

I'm getting full checkmarks here after running MOSBY:

When I use Check-SecureBootCerts.ps1:

And on event viewer:

Not sure what I have to do now. I read somewhere that I should replace the EFI files but idk.

epoch32 said:

I'm getting full checkmarks here after running MOSBY:
View attachment 157997
When I use Check-SecureBootCerts.ps1:
View attachment 157998
And on event viewer:
View attachment 157999
Not sure what I have to do now. I read somewhere that I should replace the EFI files but idk.

Click to expand...

That shows it has a full complement of keys... and even the latest SVN. You're gold, nothing more to do.

Don't worry the eventlog event's. It's notoriously slow in getting up-to-date with what's actually in firmware, especially if you used any method other than its scheduled task to get the keys installed (which it seems you did by using MOSBY!)

epoch32 said:

I'm getting full checkmarks here after running MOSBY:
View attachment 157997
When I use Check-SecureBootCerts.ps1:
View attachment 158000
And on event viewer:
View attachment 157999
Not sure what I have to do now. I read somewhere that I should replace the EFI files but idk.

Click to expand...

Here are my reg keys now:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing


The CA status used to be stuck in InProgress.

epoch32 said:

Here are my reg keys now:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing


The CA status used to be stuck in InProgress.

Click to expand...

I'd just ignore those registry entries. It will resolve itself in time as the Microsoft process realizes you have all the secure boot keys in firmware.

Buddywh said:

I'd just ignore those registry entries. It will resolve itself in time as the Microsoft process realizes you have all the secure boot keys in firmware.

Click to expand...

Thanks, I saw mosby before but shook it off. It was much easier than I thought.

So this is what they say when some manufacturers have terrible BIOS implementations.

I feel more at ease with this machine using keys not made by the oem. I wish I could donate to the mosby author with their tremendous work.

epoch32 said:

No matter what I do, I am unable to install the KEK CA on my main PC. I do not understand how, meanwhile my IdeaPad laptop running a 7th gen CPU is up-to-date with all 2023 certs. I'm not sure why this PC is struggling. It's a coffee lake machine from 2020. I keep getting Error 1801 for no reason. I even tried fwupdmgr on fedora and even it says that the KEK CA has no updates.:

I ran these two:

Code:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

And I get these:

Click to expand...

Your are nearly there. All you need is to run is "Apply DBX update.cmd" to fix your DBX and "Apply 2023 KEK, DB and bootmgfw update.cmd" to solve your UEFI KEK, DBX issue and update the SVN part. Rerun "Check UEFI PK, KEK, DB and DBX.cmd" If Current UEFI KEK is Green, DBX shows SUCCESS and SVN=7.0 or 5.0, 3.0, 3.0 Then your done. (if 5.0 instead of 7.0; you are not on the latest build yet. When you are on 26200.7462 it will be 7.0)

I can see the updating of the secure boot keys when MS decide to roll it out to the public will become a nightmare.

epoch32 said:

I feel more at ease with this machine using keys not made by the oem.

Click to expand...

That was my feeling too. Even for my machines the OEM supported with a BIOS update adding all the necessary 2023 keys. I noticed that they installed another Chain of Trust (one MSI and two Gigabyte boards, their own KEK and DB keys) alongside the Microsoft Chain of Trust allowing to secure boot something of their own. I'm not sure why they'd want that and got a bit spooked... so I used MOSBY even for those machines.

I honestly don't know how far I can trust OEM's that have so much invested in countries with authoritarian governments that spy on their own citizens' computer useage.