Title says it, but I’ll give more context.
I’ve been double booting Windows 11 and Fedora for some years now on my Lenovo Thinkpad T490; current Fedora is 43. The Fedora partition is encrypted but the Windows one isn’t. I’ve had Secure Boot enabled all along (Secure Boot support was one of my reasons to install Fedora).
After a couple weeks not using it, suddenly boot fails and instead of showing Grub lands me on a black screen with an error message:
error: ../../grub-core/kern/efi/sb.c:179:prohibited by secure boot policy
Only disabling Secure Boot in the UEFI BIOS settings allows the boot process to reach Grub.
So what the heck is going on? Did some update break Secure Boot? I didn’t install any custom Grub theme nor font.
I tried the command “mokutil --list-enrolled --kek” and it shows both 2011 and 2023 keys.
I also went to the Lenovo website, downloaded and ran a BIOS update I found there before reenabling Secure Boot, but no dice.
Do you have a custom grub theme installed?
Appartently that can break grub booting.
If so you can remove the custom theme and grub should be back to working.
You should run mokutil --list-enrolled to list the certificates that would allow grub and the kernel to load. Running mokutil --list-enrolled --db list the certificates which allow the shim to be loaded, and mokutil --list-enrolled --kek lists the certificates which shows who is allowed to update the db and dbx store. Finally mokutil --list-enrolled --pk shows who can update the kek store.
There is also mokutil --list-sbat-revocations which tels which grub version is allowd. Currently it shows
I don’t know how to interpret that. The other commands produce a lot of output, equally unininteligible.
In some post somebody mentioned an “Enable Microsoft 3rd Party UEFI CA” setting, but I can’t find it. My UEFI BIOS only shows this in the “Secure Boot Configuration” page:
Enable/Disable Secure Boot
Secure Boot mode:
Standard (Only MS or Lenovo certified programs can be executed)
Custom (Any user certified programs can be executed)
Reset to Setup mode (clear Platform keys to customize Secure Boot databases)
“Standard mode” is enabled, that’s why I put it in bold.
According to the Wikipedia and ArchLinux wiki pages on Secure Boot, Fedora uses Microsoft’s keys through Red Hat’s ‘shim’ implementation and nothing needs to be set up out of the box to run Fedora unless you want to compile and sign your own kernels. Other distributions refused to support Secure Boot because they saw it as a monopolistic move from Microsoft’s side or don’t want to bother with it.
Moreover, there are reports that setting Secure Boot mode to ‘custom’ or clearing UEFI keys may brick some Lenovo laptops like this one. I have no intention to take that risk! I only clicked on the general UEFI switch to disable Secure Boot as a whole and won’t touch anything else unless I know what I’m doing.
Let’s go back to the main question: Why Secure Boot stopped working without any visible change? Is anybody else affected by this?
For more context, here are the complete results of sudo bootctl status:
systemd-boot not installed in ESP.
System:
Firmware: n/a (n/a)
Firmware Arch: x64
Secure Boot: disabled
TPM2 Support: yes
Measured UKI: no
Boot into FW: supported
Current Boot Loader:
Product: GRUB 2.12
Features:
✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
✗ Support for XBOOTLDR partition
✗ Support for passing random seed to OS
✗ Load drop-in drivers
✗ Support Type #1 sort-key field
✗ Support @saved pseudo-entry
✗ Support Type #1 devicetree field
✗ Enroll SecureBoot keys
✗ Retain SHIM protocols
✗ Menu can be disabled
✗ Multi-Profile UKIs are supported
✗ Loader reports network boot URL
✗ Support Type #1 uki field
✗ Support Type #1 uki-url field
✗ Loader reports TPM2 active PCR banks
Partition: /dev/disk/by-partuuid/2026b026-1458-4641-a20a-aa07a156c5fa
Random Seed:
System Token: not set
Exists: no
Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/2026b026-1458-4641-a20a-aa07a156c5fa)
File:
├─/boot/efi//EFI/BOOT/BOOTIA32.EFI
├─/boot/efi//EFI/BOOT/fbia32.efi
├─/boot/efi//EFI/BOOT/fbx64.efi
└─/boot/efi//EFI/BOOT/bootx64.efi
Boot Loaders Listed in EFI Variables:
Title: Fedora
ID: 0x0001
Status: active, boot-order
Partition: /dev/disk/by-partuuid/2026b026-1458-4641-a20a-aa07a156c5fa
File: └─/boot/efi//EFI/fedora/shimx64.efi
Title: Windows Boot Manager
ID: 0x0000
Status: active, boot-order
Partition: /dev/disk/by-partuuid/2026b026-1458-4641-a20a-aa07a156c5fa
File: └─/boot/efi//EFI/Microsoft/Boot/bootmgfw.efi
Title: Linux-Firmware-Updater
ID: 0x0002
Status: active, boot-order
Partition: /dev/disk/by-partuuid/2026b026-1458-4641-a20a-aa07a156c5fa
File: └─/boot/efi//EFI/fedora/shimx64.efi
Boot Loader Entry Locations:
ESP: /boot/efi (/dev/disk/by-partuuid/2026b026-1458-4641-a20a-aa07a156c5fa, $BOOT)
config: /boot/efi//loader/loader.conf: El fitxer o directori no existeix
token: fedora
0 entries, no entry could be determined as default.
Microsoft provides two certificates: one for Windows and built in drivers, and one for everything else. The Fedora system falls in the category of “Everything Else”. To improve security for Windows, some computers have an option to disable the second category, which is find for those who runs Windows only.
You need to run mokutil --list-enrolled --db --short and the list should include all four of these certificates.
46def63b5c Microsoft Corporation UEFI CA 2011
580a6f4cc4 Microsoft Windows Production PCA 2011
b5eeb4a670 Microsoft UEFI CA 2023
3fb39e2b8b Microsoft Option ROM UEFI CA 2023
7b9e6cc3c2 ThinkPad Product CA 2012 cb02597148 Lenovo UEFI CA 2014 46def63b5c Microsoft Corporation UEFI CA 2011 580a6f4cc4 Microsoft Windows Production PCA 2011 b5eeb4a670 Microsoft UEFI CA 2023 3fb39e2b8b Microsoft Option ROM UEFI CA 2023
Just to second this, I recently had automatic updates happen yesterday and I am now running into the same exact issue. I also run a Fedora 43 dual boot with Windows 11. I do have secure boot enabled on both rather than just the 1. I’ve been running this setup for about 5 months now with no issues, so something must have gotten changed in a package update that caused this.
Did you see the news that MS has been rolling out UEFI updates? [1] And that “Worst case, impacted PCs might be unable to boot, or even to access UEFI after powering on.” [2]
Thanks, I had no idea. I spent over an hour reading and trying to make sense of it.
So Windows Update is the culprit? However, I’m on Windows right now and can’t find any “Secure Boot Allowed Key Exchange Key (KEK) Update” in Windows Update’s history. Also, the PowerShell command reports “False”.
On the other hand, Windows Event Viewer started logging error messages on October 27th 2025, always the same. It seems to say that updated secure boot certificates are available but not applied to firmware. Yet I can’t pinpoint the exact update that caused everything, nor can I understand why the problem didn’t manifest itself until now, after so many months.
If I’m making sense from the long articles, should I restore factory keys? Will that plus reenabling secure boot be enough, or will I have to dabble with Windows Updates again?
Here’s the log event:
Log Name: System
Source: Microsoft-Windows-TPM-WMI
Date: 27/10/2025 22:45:18
Event ID: 1801
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: denkende-Fenster
Description:
Los certificados de arranque seguro actualizados están disponibles en este dispositivo, pero aún no se han aplicado al firmware. Revisa las instrucciones publicadas para completar la actualización y mantener la protección completa. Esta información de firma de dispositivo se incluye aquí.
DeviceAttributes: FirmwareVersion:N2IETA6W (1.84 );OEMManufacturerName:LENOVO;OEMModelSKU:LENOVO_MT_20N3_BU_Think_FM_ThinkPad T490;OSArchitecture:amd64;
BucketId: 5042b1e25bad8b48a8223ce276effe064939dcf1a4cc79125d2298d2a13c7e6d
BucketConfidenceLevel:
UpdateType: 0
Para más información, consulta
.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-TPM-WMI" Guid="{7d5387b0-cbe0-11da-a94d-0800200c9a66}" />
<EventID>1801</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2025-10-27T21:45:18.5179989Z" />
<EventRecordID>6443</EventRecordID>
<Correlation />
<Execution ProcessID="2352" ThreadID="7520" />
<Channel>System</Channel>
<Computer>denkende-Fenster</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="DeviceAttributes">FirmwareVersion:N2IETA6W (1.84 );OEMManufacturerName:LENOVO;OEMModelSKU:LENOVO_MT_20N3_BU_Think_FM_ThinkPad T490;OSArchitecture:amd64;</Data>
<Data Name="BucketId">5042b1e25bad8b48a8223ce276effe064939dcf1a4cc79125d2298d2a13c7e6d</Data>
<Data Name="BucketConfidenceLevel">
</Data>
<Data Name="UpdateType">0</Data>
<Data Name="HResult">0</Data>
</EventData>
</Event>
I’m just reading a bit about this myself, so I’m not really sure. It looks like MS started rolling out these certificate updates as early as February 13, 2024, but I guess it was opt in initially. If your system picked up the updates in October, but could not apply them due to a firmware bug, a more recent update of the firmware might have suddenly allowed the certificate update to apply. Apparently those certificate updates were set to just keep retrying every 12 hours if they didn’t succeed the first time.
Considering how early GRUB loads, there are not many things that could interfere with it. I think it would have to be a firmware update of some sort.
I haven’t encountered this problem personally, but if I did, one thing I might try would be to install the shim package from the rawhide branch. I think that package is supposed to be signed by the new MS certificate. I’m not quite sure how to do that though. Maybe sudo dnf update --repo=rawhide shim\* would work?
So somehow the kek has been updated.
The kek could be updated through windows or through fwupdmgr in linux. In either case the updates comes ultimately from the same source.
But the important cewrtificates are the ones found in db and these are also up-to-date according to the information you have provided.
That pretty much matches for when the db updates was made available from Microsoft, either through windows updates or from fwupd.
I assume that all grub packages are fully up-to-date and the shim packages as well. Older versions tends to become blacklisted at some point
On my systems, the old as well as the new Microsoft certificates are installed, and that would verify the latest version of shim from Fedora 43 as well as the one from Fedora 44.
