Hello all,
As you guys know Secure Boot is supported by Fedora Linux and it relies on the Microsoft signing keys. Well, recently I was looking at this month's Windows 11 cumulative update and noticed this warning:
Important: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026. This might affect the ability of certain personal and business devices to boot securely if not updated in time. To avoid disruption, we recommend reviewing the guidance and taking action to update certificates in advance. For details and preparation steps, see Windows Secure Boot certificate expiration and CA updates.
Which links to https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-ex...
My question is if we as Fedora users should worry....
I guess that users with devices that actively receive BIOS updates should receive a update with the new certificates included, but it's unknown what will happen for devices that are basically out of support.
I believe that fwupd should be able to update that certificate, but at least on my system the Microsoft certificate isn't shown on it (I believe on a UEFI Secure Boot VM it's shown)
Should we worry about this?
For instance, my device, a Dell laptop, for which fwupd recognizes: the firmware (which I update via a built in Bios flash utility), the dbx (updated via fwupd) and a mysterious "Dell Platform Key", which might be Microsoft's certificate along with some other Dell stuff.
Is Linux ready for the Microsoft certificate expiring next year?
Thanks for your time, Mateus Rodrigues Costa
On Tue, Jul 8, 2025 at 8:45 PM Mateus Rodrigues Costa mateusrodcosta@gmail.com wrote:
Hello all,
As you guys know Secure Boot is supported by Fedora Linux and it relies on the Microsoft signing keys. Well, recently I was looking at this month's Windows 11 cumulative update and noticed this warning:
Important: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026. This might affect the ability of certain personal and business devices to boot securely if not updated in time. To avoid disruption, we recommend reviewing the guidance and taking action to update certificates in advance. For details and preparation steps, see Windows Secure Boot certificate expiration and CA updates.
Which links to https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-ex...
My question is if we as Fedora users should worry....
I guess that users with devices that actively receive BIOS updates should receive a update with the new certificates included, but it's unknown what will happen for devices that are basically out of support.
I believe that fwupd should be able to update that certificate, but at least on my system the Microsoft certificate isn't shown on it (I believe on a UEFI Secure Boot VM it's shown)
Should we worry about this?
For instance, my device, a Dell laptop, for which fwupd recognizes: the firmware (which I update via a built in Bios flash utility), the dbx (updated via fwupd) and a mysterious "Dell Platform Key", which might be Microsoft's certificate along with some other Dell stuff.
Is Linux ready for the Microsoft certificate expiring next year?
I would guess varying degrees of "no." Distributions will need new shim builds signed with the "Microsoft Corporation UEFI CA 2023" certificate instead of the previous 2011 one that was introduced with Windows 8. It looks like the shim binaries on my system (Fedora 42) are still signed only with the 2011 CA certificate.
Some digging indicates that Microsoft will not begin signing with the 2023 certificate until October: https://github.com/rhboot/shim-review/issues/454#issuecomment-3000727363
So for now, we all have to wait and there's nothing we can do.
Neal Gompa venit, vidit, dixit 2025-07-09 03:22:40:
On Tue, Jul 8, 2025 at 8:45 PM Mateus Rodrigues Costa mateusrodcosta@gmail.com wrote:
Hello all,
As you guys know Secure Boot is supported by Fedora Linux and it relies on the Microsoft signing keys. Well, recently I was looking at this month's Windows 11 cumulative update and noticed this warning:
Important: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026. This might affect the ability of certain personal and business devices to boot securely if not updated in time. To avoid disruption, we recommend reviewing the guidance and taking action to update certificates in advance. For details and preparation steps, see Windows Secure Boot certificate expiration and CA updates.
Which links to https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-ex...
My question is if we as Fedora users should worry....
I guess that users with devices that actively receive BIOS updates should receive a update with the new certificates included, but it's unknown what will happen for devices that are basically out of support.
I believe that fwupd should be able to update that certificate, but at least on my system the Microsoft certificate isn't shown on it (I believe on a UEFI Secure Boot VM it's shown)
Should we worry about this?
For instance, my device, a Dell laptop, for which fwupd recognizes: the firmware (which I update via a built in Bios flash utility), the dbx (updated via fwupd) and a mysterious "Dell Platform Key", which might be Microsoft's certificate along with some other Dell stuff.
Is Linux ready for the Microsoft certificate expiring next year?
I would guess varying degrees of "no." Distributions will need new shim builds signed with the "Microsoft Corporation UEFI CA 2023" certificate instead of the previous 2011 one that was introduced with Windows 8. It looks like the shim binaries on my system (Fedora 42) are still signed only with the 2011 CA certificate.
Some digging indicates that Microsoft will not begin signing with the 2023 certificate until October: https://github.com/rhboot/shim-review/issues/454#issuecomment-3000727363
So for now, we all have to wait and there's nothing we can do.
Yes and no.
The OP's concern seems to be whether old devices even receive the new CA certificate, and rightly so. It would have to be distributed *before* MS signs shims with it, or else the signature can't be validated. And that becomes a problem if it's the only signature.
Now, users *can* add CA certificates (to a different part of the store). Some of us do that to sign self-compiled kernel modules. So, in order to keep those machines on secure-boot which don't receive vendor (lfvs) updates anymore, we could do two things:
1 Add the new MS CA manually (i.e. tell users how to, or help with a package/script). [I don't know whether we can, both technically and legally - I assume we'd need the public key only which should be fine.]
2 Cross-sign the shim with our (Fedora's) own CA certificate and do the same as 1. No legal hurdles there, and potentially better path forward: It would allow users to potentially dump MS's key and trust Fedora's signing process only.
Cheers Michael
Mateus Rodrigues Costa wrote:
Important: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026.
Ouch! Yet another epic Microsoft FAIL. Setting an expiry date (ANY expiring date) on this sort of signing key, which gets embedded into all sorts of firmware blobs, completely defies common sense. It is utterly clear that most firmware out there will NEVER be updated with the new key and will hence just refuse to boot anything as long as "Secure" Boot (Restricted Boot) is enabled, unless the firmware developers were smart enough to do the ONLY sensible thing here and completely ignore the expiry date (but I would not count on that).
Kevin Kofler
On Tue, Jul 08, 2025 at 09:44:54PM -0300, Mateus Rodrigues Costa wrote:
Hello all,
As you guys know Secure Boot is supported by Fedora Linux and it relies on the Microsoft signing keys. Well, recently I was looking at this month's Windows 11 cumulative update and noticed this warning:
Important: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026. This might affect the ability of certain personal and business devices to boot securely if not updated in time. To avoid disruption, we recommend reviewing the guidance and taking action to update certificates in advance. For details and preparation steps, see Windows Secure Boot certificate expiration and CA updates.
Which links to https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-ex...
My question is if we as Fedora users should worry....
I guess that users with devices that actively receive BIOS updates should receive a update with the new certificates included, but it's unknown what will happen for devices that are basically out of support.
We can assume that some HW will never receive BIOS updates, or BIOS updates on a very slow/delayed schedule, hence the need for fwupd to be able to deliver the new certs.
I believe that fwupd should be able to update that certificate, but at least on my system the Microsoft certificate isn't shown on it (I believe on a UEFI Secure Boot VM it's shown)
Historically fwupd wasn't able to cope with this, but recent releases have been enhanced to handle the updates that Linux users will need to see, which should mitigate the worst of the impact. There's a reasonable overview of the situation here:
https://fwupd.github.io/libfwupdplugin/uefi-db.html
Should we worry about this?
To some extent. Users should be "aware" of the potential for trouble, but hopefully the worst of the "worry" part is handled by the OS vendors and maintainers.
Is Linux ready for the Microsoft certificate expiring next year?
Even with the fwupd enhancements, users are still liable to see some level of disruption. eg if new hardware /only/ has the new 2023 cert present, no existing OS release will be able to install in SecureBoot mode.
I'm unclear if fwupd would push the /old/ SB certs out to new HW which only has the new SB certs - i'm guessing probably not ?
Existing OS which are still under support will probably (hopefully) get updates at some point, but there will be plenty of OS that are never updated to be signed by new certs.
With regards, Daniel
On Wednesday, 9 July 2025 at 09:52, Daniel P. Berrangé berrange@redhat.com wrote:
Historically fwupd wasn't able to cope with this, but recent releases have been enhanced to handle the updates that Linux users will need to see, which should mitigate the worst of the impact. There's a reasonable overview of the situation here: https://fwupd.github.io/libfwupdplugin/uefi-db.html
Agreed -- I was about to add a link to that exact page.
I'm unclear if fwupd would push the /old/ SB certs out to new HW which only has the new SB certs - i'm guessing probably not ?
We wouldn't be able to, we'd have to have a KEK *update* which included the old db key -- which vendors won't do.
The tl;dr: is:
* You might get a "BIOS" update that adds the new db, otherwise * You might get a new KEK update (this is per-vendor, so only vendors cooperating with Microsoft have updates available -- as more get added I'll add them to the LVFS) * Once you've deployed the new KEK (and rebooted) you should get the new db update too (shared between vendors)
The KEK updates are going out at ~98% success, and db update is ~99% success -- but even 1% multiplied by millions of people is a fair few failures to deploy -- the "failed to write efivarfs" thing. What fixes it for some people is rebooting and clearing the BIOS to factory defaults -- this has the effect of triggering a "de-fragmentation" of the available efivar space so that there's enough contiguous space to deploy the update. The older your BIOS the more likely you are to hit this.
In the cases where even a factory default reset doesn't fix it, it's probably because the system vendor never actually tested if the db update works -- usually the more you pay for the system the more QA for things like this was done.
In the pathological case at least one vendor has lost the private key used for signing their PK, so they're having to issue firmware updates to replace the PK on the running system -- which could be a terrible idea from an attestation point of view. Those kind of vendors are also not the kind of vendors that usually issue bios updates (usually because of "cost") so the solution there is to turn off secure boot. If you're running a 7 year old system firmware then UEFI secure boot certificates are probably quite low on your compliance list.
Richard.
Em qua., 9 de jul. de 2025, 10:38, Richard Hughes via devel < devel@lists.fedoraproject.org> escreveu:
On Wednesday, 9 July 2025 at 09:52, Daniel P. Berrangé < berrange@redhat.com> wrote:
Historically fwupd wasn't able to cope with this, but recent releases have been enhanced to handle the updates that Linux users will need to see, which should mitigate the worst of the impact. There's a reasonable overview of the situation here: https://fwupd.github.io/libfwupdplugin/uefi-db.html
Agreed -- I was about to add a link to that exact page.
I'm unclear if fwupd would push the /old/ SB certs out to new HW which only has the new SB certs - i'm guessing probably not ?
We wouldn't be able to, we'd have to have a KEK *update* which included the old db key -- which vendors won't do.
This is interesting, Neal mentioned earlier that the shim is currently only signed with the 2011 and Microsoft will only start singing with the new CA when the old one is close to expiring (9 month earlier I think?). So I would guess for some OEMs we could have systems with only the new cert and for the ones with the old one one we would need both the legacy and the newer one at the same time unless we want to risk breaking stuff.
Of course waiting seems to be an option as well.
The tl;dr: is:
- You might get a "BIOS" update that adds the new db, otherwise
- You might get a new KEK update (this is per-vendor, so only vendors
cooperating with Microsoft have updates available -- as more get added I'll add them to the LVFS)
- Once you've deployed the new KEK (and rebooted) you should get the new
db update too (shared between vendors)
The KEK updates are going out at ~98% success, and db update is ~99% success -- but even 1% multiplied by millions of people is a fair few failures to deploy -- the "failed to write efivarfs" thing. What fixes it for some people is rebooting and clearing the BIOS to factory defaults -- this has the effect of triggering a "de-fragmentation" of the available efivar space so that there's enough contiguous space to deploy the update. The older your BIOS the more likely you are to hit this.
In the cases where even a factory default reset doesn't fix it, it's probably because the system vendor never actually tested if the db update works -- usually the more you pay for the system the more QA for things like this was done.
In the pathological case at least one vendor has lost the private key used for signing their PK, so they're having to issue firmware updates to replace the PK on the running system -- which could be a terrible idea from an attestation point of view. Those kind of vendors are also not the kind of vendors that usually issue bios updates (usually because of "cost") so the solution there is to turn off secure boot. If you're running a 7 year old system firmware then UEFI secure boot certificates are probably quite low on your compliance list.
Good point about the firmware age (which I assume is based on last update). Devices from the Windows 8(.1)-era come to mind and might have most issues. While probably Windows 10 and 11-era devices might either still receive BIOS updates or at very least have a not so buggy last firmware.
Richard.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
---
Mateus Rodrigues Costa
On Wed, 2025-07-09 at 13:38 +0000, Richard Hughes via devel wrote:
In the pathological case at least one vendor has lost the private key used for signing their PK, so they're having to issue firmware updates to replace the PK on the running system -- which could be a terrible idea from an attestation point of view. Those kind of vendors are also not the kind of vendors that usually issue bios updates (usually because of "cost") so the solution there is to turn off secure boot. If you're running a 7 year old system firmware then UEFI secure boot certificates are probably quite low on your compliance list.
In theory wouldn't we also have the option to ship an old shim for such cases? If the whole chain is old it should work, right? Of course, we'd then need some heuristic to figure out if we're on the old MS cert and install the old shim...
I don't know if this is *worth it* vs just advising people to turn off SB...
On Wed, Jul 09, 2025 at 08:38:09AM -0700, Adam Williamson wrote:
On Wed, 2025-07-09 at 13:38 +0000, Richard Hughes via devel wrote:
In the pathological case at least one vendor has lost the private key used for signing their PK, so they're having to issue firmware updates to replace the PK on the running system -- which could be a terrible idea from an attestation point of view. Those kind of vendors are also not the kind of vendors that usually issue bios updates (usually because of "cost") so the solution there is to turn off secure boot. If you're running a 7 year old system firmware then UEFI secure boot certificates are probably quite low on your compliance list.
In theory wouldn't we also have the option to ship an old shim for such cases? If the whole chain is old it should work, right? Of course, we'd then need some heuristic to figure out if we're on the old MS cert and install the old shim...
That approach might work for a while, but will break with the first security-related shim update which gets signed with the new microsoft keys only. Continuing running shim with known security bugs makes it kida pointless to have secure boot turned on ...
I don't know if this is *worth it* vs just advising people to turn off SB...
I'd suggest the latter.
take care, Gerd
On Wed, 2025-07-09 at 13:38 +0000, Richard Hughes via devel wrote:
In the pathological case at least one vendor has lost the private key used for signing their PK, so they're having to issue firmware updates to replace the PK on the running system -- which could be a terrible idea from an attestation point of view. Those kind of vendors are also not the kind of vendors that usually issue bios updates (usually because of "cost") so the solution there is to turn off secure boot. If you're running a 7 year old system firmware then UEFI secure boot certificates are probably quite low on your compliance list.
In theory wouldn't we also have the option to ship an old shim for such cases? If the whole chain is old it should work, right? Of course, we'd then need some heuristic to figure out if we're on the old MS cert and install the old shim...
I don't know if this is *worth it* vs just advising people to turn off SB...
Hi,
(I believe on a UEFI Secure Boot VM it's shown)
The default secure boot variable store template shipped by fedora includes the 2023 keys for roughly one year, so VMs younger than that and fresh installs should have them.
For instance, my device, a Dell laptop, for which fwupd recognizes: the firmware (which I update via a built in Bios flash utility), the dbx (updated via fwupd) and a mysterious "Dell Platform Key", which might be Microsoft's certificate along with some other Dell stuff.
The update is a two-step process. First enroll the new microsoft KEK key, which needs a signature with the platform keys of the vendor.
Microsoft has published tons of updates for various vendors here: https://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/...
Second enroll the new microsoft db keys, with the update being signed with the new microsoft KEK key.
fwupd should be able to handle both updates. I'm not sure whenever that is live already or still in the testing phase.
If you are up for experiments you can try apply the updates manually using the signed files from the repo listed above. efi-updatevar (efitools.rpm) should be able to do it.
Problem with that is not so much linux, but that a KEK update has never happened before so there are chances that bios vendors messed up things and updating the KEK doesn't work. Also not sure how good older hardware is covered.
take care, Gerd
On Wed, Jul 9 2025 at 11:28:19 AM +02:00:00, Gerd Hoffmann kraxel@redhat.com wrote:
Problem with that is not so much linux, but that a KEK update has never happened before so there are chances that bios vendors messed up things and updating the KEK doesn't work. Also not sure how good older hardware is covered.
I received a KEK update for my laptop just yesterday via GNOME Software. Checking with 'fwupdmgr get-history' I can see the update description: "This updates the UEFI Signature Database (the "KEK") to the latest release from Microsoft, signed by LENOVO." Nice when things just work.
But it's clearly a Thinkpad-specific update, so this does no good for most of our users.
Em qua., 9 de jul. de 2025, 09:06, Michael Catanzaro mcatanzaro@redhat.com escreveu:
On Wed, Jul 9 2025 at 11:28:19 AM +02:00:00, Gerd Hoffmann kraxel@redhat.com wrote:
Problem with that is not so much linux, but that a KEK update has never happened before so there are chances that bios vendors messed up things and updating the KEK doesn't work. Also not sure how good older hardware is covered.
I received a KEK update for my laptop just yesterday via GNOME Software. Checking with 'fwupdmgr get-history' I can see the update description: "This updates the UEFI Signature Database (the "KEK") to the latest release from Microsoft, signed by LENOVO." Nice when things just work.
But it's clearly a Thinkpad-specific update, so this does no good for most of our users.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
IMHO I believe there's no reason that Lenovo can't send the kek update to all UEFI and Secure Boot-supported devices regardless of whether those devices are normally lvfs supported. Same for Dell.
At least for me it seems to be a extremely generic update that doesn't rely on hardware specific characteristics as is with a full BIOS update.
---
Mateus Rodrigues Costa
Hi,
At least for me it seems to be a extremely generic update that doesn't rely on hardware specific characteristics as is with a full BIOS update.
Correct. It's literally just the new ms kek key with a pkcs7 signature from the hardware vendor's PK key. No code update.
take care, Gerd
* Gerd Hoffmann:
At least for me it seems to be a extremely generic update that doesn't rely on hardware specific characteristics as is with a full BIOS update.
Correct. It's literally just the new ms kek key with a pkcs7 signature from the hardware vendor's PK key. No code update.
Still it needs to go through QA because it has a significant risk of corrupting the boot path.
Thanks, Florian
On Wed, Jul 09, 2025 at 05:42:23PM +0200, Florian Weimer wrote:
- Gerd Hoffmann:
At least for me it seems to be a extremely generic update that doesn't rely on hardware specific characteristics as is with a full BIOS update.
Correct. It's literally just the new ms kek key with a pkcs7 signature from the hardware vendor's PK key. No code update.
Still it needs to go through QA because it has a significant risk of corrupting the boot path.
Sure. It's a first in the secure boot world and has the potential to break a bunch of stuff. Specifically I think with the boot signature chain changing some TPM PCR measurements will change too, so TPM being is used for LUKS disk encryption most likely is affected and will need some extra attention.
But it shouldn't be the "broken bios update might brick the machine" level of risk.
take care, Gerd
Em qui., 10 de jul. de 2025, 12:42, Gerd Hoffmann kraxel@redhat.com escreveu:
On Wed, Jul 09, 2025 at 05:42:23PM +0200, Florian Weimer wrote:
- Gerd Hoffmann:
At least for me it seems to be a extremely generic update that
doesn't rely
on hardware specific characteristics as is with a full BIOS update.
Correct. It's literally just the new ms kek key with a pkcs7 signature from the hardware vendor's PK key. No code update.
Still it needs to go through QA because it has a significant risk of corrupting the boot path.
Sure. It's a first in the secure boot world and has the potential to break a bunch of stuff. Specifically I think with the boot signature chain changing some TPM PCR measurements will change too, so TPM being is used for LUKS disk encryption most likely is affected and will need some extra attention.
Would it be the same root cause from when every so often Microsoft releases a update related to Secure Boot and Windows users get thrown into the BitLocker recovery asking for a key that many of them have no idea how to get? (And they also can't use the Microsoft account backup because they have no access)
But it shouldn't be the "broken bios update might brick the machine" level of risk.
take care, Gerd
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi,
Sure. It's a first in the secure boot world and has the potential to break a bunch of stuff. Specifically I think with the boot signature chain changing some TPM PCR measurements will change too, so TPM being is used for LUKS disk encryption most likely is affected and will need some extra attention.
Would it be the same root cause from when every so often Microsoft releases a update related to Secure Boot and Windows users get thrown into the BitLocker recovery asking for a key that many of them have no idea how to get? (And they also can't use the Microsoft account backup because they have no access)
Probably. Different things (certificates used, binaries loaded, ...) are measured to different PCRs though, so you can have different effects depending on what exactly has been updated.
When binding keys to the TPM it is possible to define which PCRs are expected to have specific values. I don't know how bitlocker uses the TPM, so I can't go deeper into details here.
It is also possible to (a) calculate the new PCR measurements beforehand, and (b) update the TPM policies, so in theory the update process should be able handle that without requiring users to reach for the recovery keys. But it's software, and bugs happen ...
take care, Gerd
On Friday, 11 July 2025 at 07:44, Gerd Hoffmann kraxel@redhat.com wrote:
It is also possible to (a) calculate the new PCR measurements beforehand
That's exactly what Microsoft want to ask from vendors in the future, but I really wish them luck because when I asked them for the new PCR0 "golden hashes" for LVFS updates only one vendor complied, and and only for a few models. Asking for multiple PCR hashes is going to be even harder. Maybe Microsoft asking will have more luck than little me.
Richard
On Fri, Jul 11, 2025 at 10:33 AM Richard Hughes via devel devel@lists.fedoraproject.org wrote:
That's exactly what Microsoft want to ask from vendors in the future, but I really wish them luck because when I asked them for the new PCR0 "golden hashes" for LVFS updates only one vendor complied, and and only for a few models. Asking for multiple PCR hashes is going to be even harder. Maybe Microsoft asking will have more luck than little me.
Well, Microsoft has their Windows certification requirements, and they have used them in the past to get PC manufacturers to implement what they wish the industry to do. If Microsoft really wants/needs it, I have no doubt it will happen.
On Wednesday, 09 July 2025 at 14:06, Michael Catanzaro wrote:
On Wed, Jul 9 2025 at 11:28:19 AM +02:00:00, Gerd Hoffmann kraxel@redhat.com wrote:
Problem with that is not so much linux, but that a KEK update has never happened before so there are chances that bios vendors messed up things and updating the KEK doesn't work. Also not sure how good older hardware is covered.
I received a KEK update for my laptop just yesterday via GNOME Software. Checking with 'fwupdmgr get-history' I can see the update description: "This updates the UEFI Signature Database (the "KEK") to the latest release from Microsoft, signed by LENOVO." Nice when things just work.
But it's clearly a Thinkpad-specific update, so this does no good for most of our users.
Well, I got one from Linux Foundation:
│ └─Secure Boot KEK Configuration Update: │ New version: 2023 │ Remote ID: lvfs │ Release ID: 114286 │ Summary: UEFI Secure Boot Key Exchange Key │ Variant: MCJ │ Licence: Proprietary │ Size: 2.5 kB │ Created: 2025-04-29 │ Urgency: High │ Vendor: Linux Foundation │ Release Flags: • Trusted metadata │ • Is upgrade │ Description: │ This updates the UEFI Signature Database (the "KEK") to the latest release from Microsoft, signed by Root Agency. │ Checksum: 36ea945cf1cf357df5ff30096e228dcab4c83f9e3438ecb475a3e10af19ff44f
I can't install it, however: failed to write-firmware: failed to write (null): failed to write data to efivarsfs: Error writing to file descriptor: Invalid argument
Is this one of the cases of firmware/mainboard vendor messing up? Or do I need to disable SecureBoot to update the KEK?
Regards, Dominik
On Wednesday, 09 July 2025 at 14:38, Michael Catanzaro wrote:
Your problem is: https://github.com/fwupd/fwupd/wiki/LVFS-Triaged-Issue:-dbx-efivarfs-IO-erro...
Thanks. I went into firmware setup and reset the SecureBoot keys and now the update is not showing as available at all. I'm not sure I understand what happpened here.
I still have the failed update in fwupdmgr history, but I'm unable to redo it.
Regards, Dominik
On 7/8/25 7:44 PM, Mateus Rodrigues Costa wrote:
For instance, my device, a Dell laptop, for which fwupd recognizes: the firmware (which I update via a built in Bios flash utility), the dbx (updated via fwupd) and a mysterious "Dell Platform Key", which might be Microsoft's certificate along with some other Dell stuff.
My Supermicro server motherboard from 2019 has a KEK with only the 2011 CA. Latest UEFI released Dec 2024. My Gigabyte desktop motherboard from 2022 has a KEK with both 2011 and 2023 CAs. Latest UEFI released Apr 2025.
It's going to be interesting.
Once upon a time, Michael Cronenworth mike@cchtml.com said:
My Supermicro server motherboard from 2019 has a KEK with only the 2011 CA. Latest UEFI released Dec 2024. My Gigabyte desktop motherboard from 2022 has a KEK with both 2011 and 2023 CAs. Latest UEFI released Apr 2025.
How can I tell what my systems have (ideally from within Linux)?
On Wednesday, 9 July 2025 at 15:51, Chris Adams linux@cmadams.net wrote:
How can I tell what my systems have (ideally from within Linux)?
If you need to script it "fwupdmgr get-devices --json" assuming you have fwupd >= 2.0.12 -- or just use gnome-firmware if you want something with a UI.
Richard.
On 7/9/25 9:51 AM, Chris Adams wrote:
How can I tell what my systems have (ideally from within Linux)?
There might be a better way, but I used "efivar" from the package with the same name.
# dnf install efivar $ efivar --list | grep -i kek $ efivar -p -n <kek name from previous command>
It will be a hexdump so you will need to look at the ASCII output for "Microsoft Corporation KEK CA 2011" or "Microsoft Corporation KEK 2K CA 2023".
Hi Michael, Chris, and devel folks,
On Wed, Jul 9, 2025, 11:16 Michael Cronenworth mike@cchtml.com wrote:
On 7/9/25 9:51 AM, Chris Adams wrote:
How can I tell what my systems have (ideally from within Linux)?
There might be a better way, but I used "efivar" from the package with the same name.
I usually use mokutil to list keys: (it should be installed by default)
$ mokutil -l --kek $ mokutil -l --db
To see all UEFI keys, databases and MOKs:
$ mokutil -l -a
For more detailed results:
$ mokutil -l -a --verbose-listing
Best, Alexander F. Lent lx@xanderlent.com
On 7/9/25 11:21 AM, Alexander F. Lent wrote:
I usually use mokutil to list keys: (it should be installed by default)
$ mokutil -l --kek $ mokutil -l --db
Thanks! This list showed I missed the CA in the hexdump. My Supermicro server has the 2023 CA.
However, when I ran the same commands on my Gigabyte motherboard there was no output.
My server has secure boot enabled, but the desktop does not. Does mokutil depend on Secure Boot being enabled? The efivar command dumped without secure boot.
$ mokutil -l -a [MokListRT] 2bb010e24d fedoraca [MokListXRT] 0000000000 (sha256) [PK] [KEK] [db] [dbx]
*sigh* UEFI. :(
Em qua., 9 de jul. de 2025 às 13:21, Alexander F. Lent lx@xanderlent.com escreveu:
Hi Michael, Chris, and devel folks,
On Wed, Jul 9, 2025, 11:16 Michael Cronenworth mike@cchtml.com wrote:
On 7/9/25 9:51 AM, Chris Adams wrote:
How can I tell what my systems have (ideally from within Linux)?
There might be a better way, but I used "efivar" from the package with the same name.
I usually use mokutil to list keys: (it should be installed by default)
$ mokutil -l --kek $ mokutil -l --db
Tested this on my Dell laptop and got this:
``` $ mokutil -l --kek d4884608ae Dell Inc. Key Exchange Key 31590bfd89 Microsoft Corporation KEK CA 2011 $ mokutil -l --db 15254b199b Dell Inc. UEFI DB 46def63b5c Microsoft Corporation UEFI CA 2011 580a6f4cc4 Microsoft Windows Production PCA 2011 ```
I assume that since the last BIOS update available for me (and currently installed) is from November 2023, there's some chance Dell might ship a new BIOS version with the new certificate. I wouldn't count on it though and I probably should wait for fwupd to be able to add the new CA to my system.
To see all UEFI keys, databases and MOKs:
$ mokutil -l -a
There's interesting stuff here, like the Fedora CA and the akmods keys. The only other interesting thing however is the Dell Platform Key I mentioned earlier.
For more detailed results:
$ mokutil -l -a --verbose-listing
Best, Alexander F. Lent lx@xanderlent.com -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Once upon a time, Michael Cronenworth mike@cchtml.com said:
# dnf install efivar $ efivar --list | grep -i kek $ efivar -p -n <kek name from previous command>
It will be a hexdump so you will need to look at the ASCII output for "Microsoft Corporation KEK CA 2011" or "Microsoft Corporation KEK 2K CA 2023".
Thanks, that works, and also handles curiousity on the systems with SecureBoot disabled (where mokutil doesn't).
Looking at my systems, looks like neither of my Thinkpads have the 2023 key yet (although the newest one is a BIOS version behind due to power-management issues in the latest). Those are my only systems with SB enabled (due to still having factory Windows on there; I never use it but keep it around "just in case").
A couple of systems I do find the new key on are a 5+ year old Gigabyte motherboard and an Intel/ASUS NUC (both of which have had BIOS updates released this year).
I'm not familiar with the intricacies of the signing; can a single shim be signed by multiple keys? And if so... will MS still sign with the old key for a while once they start signing with the new key?
On Tue, Jul 8, 2025, at 8:44 PM, Mateus Rodrigues Costa wrote:
I guess that users with devices that actively receive BIOS updates should receive a update with the new certificates included, but it's unknown what will happen for devices that are basically out of support.
I have a Lenovo Thinkpad, just a few years old I suppose. It has received firmware updates as recently as end of last year and it has
[ 1.072253] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
But the boot scroll doesn't say the expiration date. This system does have UEFI Secure Boot enabled and it booted today.
I see a newer firmware update May 12 this year, I'll apply that and see if the certificate changes.
On Wed, Jul 9, 2025, at 4:42 PM, Chris Murphy wrote:
I have a Lenovo Thinkpad, just a few years old I suppose. It has received firmware updates as recently as end of last year and it has
[ 1.072253] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
mokutil reports more details:
Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root Validity Not Before: Jun 27 21:22:45 2011 GMT Not After : Jun 27 21:32:45 2026 GMT Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
I'm confused why I'm able to boot. Seems like shim should fail verification if the public key is expired.
*shrug*
Once upon a time, Chris Murphy lists@colorremedies.com said:
Not After : Jun 27 21:32:45 2026 GMT
<snip>
I'm confused why I'm able to boot. Seems like shim should fail verification if the public key is expired.
Are you posting from the future? :)
On Wed, Jul 9, 2025, at 5:14 PM, Chris Adams wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
Not After : Jun 27 21:32:45 2026 GMT<snip> > I'm confused why I'm able to boot. Seems like shim should fail verification if the public key is expired.
Are you posting from the future? :)
I'm not supposed to admit that. ;)
OK so after firmware update the system unsurprisingly still boots, because it is apparently still 2025. But none of the certificates have changed. I guess they'll get around to it in the next 11 months?
Meanwhile I've (re)experienced a "feature" of my Lenovo firmware. Whereupon loading BIOS defaults and saving them, there are no more boot entries listed in the firmware boot menu. Not Windows. Not Fedora. Both have bootloaders found on the EFI System partition but apparently this firmware won't list them unless they're also found in efivars? Upon choosing the nvme raw device (it doesn't list partitions) it boots... Windows.
root@fovo:/boot/efi/EFI/BOOT# sha256sum BOOTX64.EFI 4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1 BOOTX64.EFI root@fovo:/boot/efi/EFI/BOOT# sha256sum ../fedora/shimx64.efi 4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1 ../fedora/shimx64.efi
Windows recovery boot menu likewise won't list Fedora, I guess because it's not found in efivars.
Track down a Fedora install USB stick, and I'm able to fix this with efibootmgr, but... what a swig of sour milk. I'd put this in the soft fail category of how these sorts of updates can go sideways.
On Wed, 2025-07-09 at 17:58 -0400, Chris Murphy wrote:
On Wed, Jul 9, 2025, at 5:14 PM, Chris Adams wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
Not After : Jun 27 21:32:45 2026 GMT<snip> > I'm confused why I'm able to boot. Seems like shim should fail verification if the public key is expired.
Are you posting from the future? :)
I'm not supposed to admit that. ;)
OK so after firmware update the system unsurprisingly still boots, because it is apparently still 2025. But none of the certificates have changed. I guess they'll get around to it in the next 11 months?
Meanwhile I've (re)experienced a "feature" of my Lenovo firmware. Whereupon loading BIOS defaults and saving them, there are no more boot entries listed in the firmware boot menu. Not Windows. Not Fedora. Both have bootloaders found on the EFI System partition but apparently this firmware won't list them unless they're also found in efivars? Upon choosing the nvme raw device (it doesn't list partitions) it boots... Windows.
root@fovo:/boot/efi/EFI/BOOT# sha256sum BOOTX64.EFI 4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1 BOOTX64.EFI root@fovo:/boot/efi/EFI/BOOT# sha256sum ../fedora/shimx64.efi 4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1 ../fedora/shimx64.efi
Windows recovery boot menu likewise won't list Fedora, I guess because it's not found in efivars.
Track down a Fedora install USB stick, and I'm able to fix this with efibootmgr, but... what a swig of sour milk. I'd put this in the soft fail category of how these sorts of updates can go sideways.
That all sounds more or less 'as it should be', I think :/ The current contents of the UEFI boot manager is usually considered 'configuration' that will be wiped by a reset-to-default. It kinda has to be, because it can cause problems - my very old test motherboard has some kind of bug which causes boot manager entries to pile up until the system actually can't boot any more, and resetting to defaults is the only way to clear it if you let it get that far without pruning them manually, for instance.
Fedora automatically re-adds itself to the boot manager config if you boot it via the fallback path, which is a very cool trick, but of course won't work if Windows is occupying the fallback path.
Chris Murphy writes:
I'm able to fix this with efibootmgr, but... what a swig of sour milk.
That pretty much describes my kneejerk reaction about a decade ago when I first read about secure boot, and how great it is to have each boot stage signed by an all-mighty cert.
I swear that my immediate thought was "and what happens when the certs expire"? How likely is that a hardware manufacturer will release a firmware update for a decade-old laptop? I have one.
On Wed, 2025-07-09 at 20:10 -0400, Sam Varshavchik wrote:
Chris Murphy writes:
I'm able to fix this with efibootmgr, but... what a swig of sour milk.
That pretty much describes my kneejerk reaction about a decade ago when I first read about secure boot, and how great it is to have each boot stage signed by an all-mighty cert.
Nothing Chris wrote about actually has anything to do with Secure Boot, really. It's just about how the UEFI boot manager works.
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
On Wed, 2025-07-09 at 20:10 -0400, Sam Varshavchik wrote:
Chris Murphy writes:
I'm able to fix this with efibootmgr, but... what a swig of sour milk.
That pretty much describes my kneejerk reaction about a decade ago when I first read about secure boot, and how great it is to have each boot stage signed by an all-mighty cert.
Nothing Chris wrote about actually has anything to do with Secure Boot, really. It's just about how the UEFI boot manager works.
Different Chris, but... it sounds like Windows gets a "fallback" position for when the firmware has no boot entries; is there a way to get Fedora into that position instead (in a dual-boot setup)? Or is it a case of the firmware just explicitly looking for the Windows loader?
Em qua., 9 de jul. de 2025, 22:11, Chris Adams linux@cmadams.net escreveu:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
On Wed, 2025-07-09 at 20:10 -0400, Sam Varshavchik wrote:
Chris Murphy writes:
I'm able to fix this with efibootmgr, but... what a swig of sour
milk.
That pretty much describes my kneejerk reaction about a decade ago
when I
first read about secure boot, and how great it is to have each boot
stage
signed by an all-mighty cert.
Nothing Chris wrote about actually has anything to do with Secure Boot, really. It's just about how the UEFI boot manager works.
Different Chris, but... it sounds like Windows gets a "fallback" position for when the firmware has no boot entries; is there a way to get Fedora into that position instead (in a dual-boot setup)? Or is it a case of the firmware just explicitly looking for the Windows loader?
As a fun fact, my Dell laptop seems to have some code somewhere (likely in the BIOS itself) that when there are no boot options setup when I try to boot form the main disk it will run an auto detect mode that likely looks into the ESP and finds the boot options from there.
I had to clear all boot options for testing a few times (as well as due to changing SSDs) and I noticed that it not only is able to find the boot options for a Windows + Linux dual boot as well as Fedora only.
Though also, yes, a "Windows Boot Manager" option might be chosen as the default sometimes, likely as most users are expected to be using Windows.
---
Mateus Rodrigues Costa
-- Chris Adams linux@cmadams.net -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 7/9/25 6:11 PM, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
On Wed, 2025-07-09 at 20:10 -0400, Sam Varshavchik wrote:
Chris Murphy writes:
I'm able to fix this with efibootmgr, but... what a swig of sour milk.
That pretty much describes my kneejerk reaction about a decade ago when I first read about secure boot, and how great it is to have each boot stage signed by an all-mighty cert.
Nothing Chris wrote about actually has anything to do with Secure Boot, really. It's just about how the UEFI boot manager works.
Different Chris, but... it sounds like Windows gets a "fallback" position for when the firmware has no boot entries; is there a way to get Fedora into that position instead (in a dual-boot setup)? Or is it a case of the firmware just explicitly looking for the Windows loader?
Fedora should be in the fallback position and it will create a boot entry for itself if it gets run like that. It's possible that the BIOS specifically looks for windows if there are no boot entries. I worked on a laptop once that would always "fix" the windows boot entry if it wasn't there or was modified.
On Wed, 2025-07-09 at 20:11 -0500, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
On Wed, 2025-07-09 at 20:10 -0400, Sam Varshavchik wrote:
Chris Murphy writes:
I'm able to fix this with efibootmgr, but... what a swig of sour milk.
That pretty much describes my kneejerk reaction about a decade ago when I first read about secure boot, and how great it is to have each boot stage signed by an all-mighty cert.
Nothing Chris wrote about actually has anything to do with Secure Boot, really. It's just about how the UEFI boot manager works.
Different Chris, but... it sounds like Windows gets a "fallback" position for when the firmware has no boot entries; is there a way to get Fedora into that position instead (in a dual-boot setup)? Or is it a case of the firmware just explicitly looking for the Windows loader?
The fallback path is defined in the UEFI spec. It's essentially a magic location. On x86_64, it's EFI/BOOT/BOOTX64.EFI within the EFI system partition on a given disk; I don't recall offhand if there's a rule for which one to use if *multiple* EFI system partitions are present on a disk. The firmware will run whatever exists at that location. This is how removable media boot - it's how a Fedora USB stick or optical disc boots, when booting in UEFI mode - and also acts as a sort of 'recovery path' for permanent installs. Also some firmwares will let you say "just boot from this disk" (as opposed to picking an actual entry from the UEFI boot menu) for permanent disks as well as removable ones; that will trigger a fallback path boot.
If Fedora's bootloader is occupying that spot on the disk, then Fedora will boot, and a special self-repair mode will kick in which will recreate the "Fedora" boot menu entry. If Windows' bootloader is occupying that spot, it'll boot Windows; I don't know if Windows does any kind of self-repair.
Usually I'd expect Fedora's bootloader to be there on a dual boot install as Fedora gets installed after Windows, but there could be various reasons why Windows' bootloader would be there.
On Wed, Jul 9, 2025, at 9:11 PM, Chris Adams wrote:
Different Chris, but... it sounds like Windows gets a "fallback" position for when the firmware has no boot entries; is there a way to get Fedora into that position instead (in a dual-boot setup)? Or is it a case of the firmware just explicitly looking for the Windows loader?
I used to know these things, but it seems I have a garbage collection routine. And now the UEFI spec is > 2500 pages, which is a ... nevermind.
I thought the spec used the ESP:\EFI\BOOT\BOOTX64.EFI as one of the (final) fallback locations even on whatever the term is for "not removable media" but I'm only seeing this location and the machine type short-name naming convention mentioned in 3.5.1.1 Removable Media Boot Behavior.
So... *shrug* maybe this file isn't expected or mandated to do anything when it's on anything other than removable media?
What I can tell you is my laptop has shimx64.efi in that location but it was not used. Windows booted instead, so I guess that location is hardwired and not exposed to the user.
$ sudo sha256sum /boot/efi/EFI/BOOT/BOOTX64.EFI 4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1 /boot/efi/EFI/BOOT/BOOTX64.EFI $ sudo sha256sum /boot/efi/EFI/fedora/shimx64.efi 4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1 /boot/efi/EFI/fedora/shimx64.efi
Whereas when I booted from the USB stick, I briefly saw blue screen with red text to the effect of doing some kind of reset, followed by the GRUB menu. What I later discovered is that this added a menu entry to NVRAM for Fedora pointing to the bootloader on that specific USB stick.
UEFI 2.8 spec excerpts:
3.1.2 Load Option Processing
If all entries of BootNext and BootOrder have been exhausted without success, or if the firmware has been instructed to attempt boot order recovery, the firmware must attempt boot option recovery (see Section 3.4).
3.4 Boot Option Recovery
In the event that boot option recovery must be performed, the boot manager must first attempt OS- defined recovery, re-attempt normal booting via Boot#### and BootOrder variables, and finally attempt platform-defined recovery if no options have succeeded.
3.4.1 describes this in substantial detail.
But after skimming all that, I realize that after resetting to defaults within the firmware's setup menu, sure if BootOrder and Boot#### entries were reset (and they seem to have been), then presumably also OSRecoveryOrder and OsRecovery#### variables are reset. At least right now there aren't any. I'm also not sure if they'd matter because the restored default BootOrder early on includes Boot0011 which points to the Boot Menu. That'll always work, but it drops the problem into the user's lap before OSRecovery would even apply.
In order for OSRecovery to apply, we'd need to trim the BootOrder to make sure neither Fedora nor Windows boot success, thereby falling back to OSRecovery.
I also still don't have an explanation why Windows booted at all instead of just taking me to the boot menu. It might be some kind of hard coded thing.
Em ter., 8 de jul. de 2025 às 21:44, Mateus Rodrigues Costa mateusrodcosta@gmail.com escreveu:
Hello all,
As you guys know Secure Boot is supported by Fedora Linux and it relies on the Microsoft signing keys. Well, recently I was looking at this month's Windows 11 cumulative update and noticed this warning:
Important: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026. This might affect the ability of certain personal and business devices to boot securely if not updated in time. To avoid disruption, we recommend reviewing the guidance and taking action to update certificates in advance. For details and preparation steps, see Windows Secure Boot certificate expiration and CA updates.
Which links to https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-ex...
My question is if we as Fedora users should worry....
I guess that users with devices that actively receive BIOS updates should receive a update with the new certificates included, but it's unknown what will happen for devices that are basically out of support.
I believe that fwupd should be able to update that certificate, but at least on my system the Microsoft certificate isn't shown on it (I believe on a UEFI Secure Boot VM it's shown)
Should we worry about this?
For instance, my device, a Dell laptop, for which fwupd recognizes: the firmware (which I update via a built in Bios flash utility), the dbx (updated via fwupd) and a mysterious "Dell Platform Key", which might be Microsoft's certificate along with some other Dell stuff.
Is Linux ready for the Microsoft certificate expiring next year?
Thanks for your time, Mateus Rodrigues Costa
Hello all again, We're nearly at the end of 2025, so I believe it makes sense to revive this thread.
Well, as we have seen, thanks to LVFS and fwupd, pretty much everyone that has a UEFI system with Secure Boot had available updates. I have very specifically seen people on Reddit complaining about "why do I have a Microsoft update on the Firmware section of the system updater?" sort of messages, as an example. So, yeah, pretty much anyone who uses Secure Boot and cares about it keeping working should be good to go.
Well, by why revive the thread? As you might remember the 3 updates we had under Linux (moving from the 2011 version to 2023) were: - Microsoft Corporation KEK CA 2011 -> Microsoft Corporation KEK 2K CA 2023 - Microsoft UEFI CA 2011 -> Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023
However there's one that isn't possible to upgrade from Linux (although I might agree not everyone wants this one): - Microsoft Windows Production PCA 2011 -> Windows UEFI CA 2023
I did go through the process mentioned at https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-man... with a Windows 10 ToGo media. And there's a lot of cool info there about Microsoft's "vision" for this migration. So I tried some of the mitigations. I applied the step 1 which adds the new certificate, there's step 2 - which I have not applied yet - which allows to optionally use a bootloader signed with the new 2023 certificates, a third step about putting the 2011 Windows certs into the dbx, and a 4th step about the SVN (seems to be similar to the SBAT) There are also instructions on how to update a Windows media for the new certs (which I guess should be similar to copying a compatible shim file to the old media).
And finally the last piece of data relevant from that article, the implementation steps. This is the rationale for what Microsoft wants to do:
NOTE: Instead of trying to exhaustively list and untrust vulnerable boot managers as we did in the previous deployment phases, we are adding the “Windows Production PCA 2011” signing certificate to the Secure Boot Disallow List (DBX) to untrust all boot managers signed by this certificate. This is a more reliable method for ensuring that all previous boot managers are untrusted.
And this is when it will hit everyone:
The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins. When updates are released for the Enforcement Phase, they will include the following:
The “Windows Production PCA 2011” certificate will automatically be revoked by being added to the Secure Boot UEFI Forbidden List (DBX) on capable devices. These updates will be programmatically enforced after installing updates for Windows to all affected systems with no option to be disabled.
It seems that even though the official certificates are officially expiring in June 2026, Microsoft already has a plan to at very least blacklisting their own old Windows certificate as early as possible next year. They not only offer offer the several step for IT for the migration, but also steps on fixing and running old Windows media if needed.
Even then we on Fedora still seem to only have shims with the old certificate:
$ sbverify shim.efi --list warning: data remaining[823272 vs 949424]: gaps between PE/COFF sections? signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
After this context, I have two questions in how it concerns Fedora:
1) From my understanding of the mentioned Microsoft article, Microsoft decided to blacklist their whole 2011 Windows certificate and rely only on the new 2023 one instead of handling all blacklisted binaries on the dbx. Will the Linux world follow something similar? If Microsoft decided to do it earlier at January instead of just waiting due to CVE-2023-24932, it might be important, correct? 2) We are close to January, what's keeping us from receiving shims signed with the new 2023 certs? It seems Neal said that Microsoft would start signing with the new certs in October of last year. Am I missing something?
Thanks for your time, Mateus Rodrigues Costa
On Mon, Dec 22, 2025 at 4:53 PM Mateus Rodrigues Costa mateusrodcosta@gmail.com wrote:
- We are close to January, what's keeping us from receiving shims
signed with the new 2023 certs? It seems Neal said that Microsoft would start signing with the new certs in October of last year. Am I missing something?
I don't think the shims (grub, systemd-boot, ??) have needed to be reissued (and re-signed) for quite some time, so I it just did not happen (yet). I believe for Fedora the latest codes (16.1?) are in the process of being validated (and, for what is probably obvious reasons, the number of people who are authorized to work the process is almost certainly going to be extremely limited).
I do expect such work to ramp up in the new year (not just by Red Hat, but other Linux vendors who also need their shim's signed). Some may have already been, depending on when they requested their latest signings (any new shims after October were dual signed).
For progress, you can watch the issues at: https://github.com/rhboot/shim-review
On Wed, 2025-12-31 at 17:31 +0000, Gary Buhrmaster wrote:
On Mon, Dec 22, 2025 at 4:53 PM Mateus Rodrigues Costa mateusrodcosta@gmail.com wrote:
- We are close to January, what's keeping us from receiving shims
signed with the new 2023 certs? It seems Neal said that Microsoft would start signing with the new certs in October of last year. Am I missing something?
I don't think the shims (grub, systemd-boot, ??) have needed to be reissued (and re-signed) for quite some time, so I it just did not happen (yet). I believe for Fedora the latest codes (16.1?) are in the process of being validated (and, for what is probably obvious reasons, the number of people who are authorized to work the process is almost certainly going to be extremely limited).
16.1 is already signed for Fedora[0] and is in stable for F41 and F44. It's in testing for F42 and F43, at least according to the tags. I don't remember what's going on there, honestly. We might have just forgotten about it? Kevin? Peter?
[0]: https://github.com/rhboot/shim-review/issues/496#issuecomment-3485399818
On Wed, Dec 31, 2025 at 7:26 PM Adam Williamson adamwill@fedoraproject.org wrote:
16.1 is already signed for Fedora[0] and is in stable for F41 and F44. It's in testing for F42 and F43, at least according to the tags. I don't remember what's going on there, honestly. We might have just forgotten about it? Kevin? Peter?
When I looked, the shimx86 efi image was the one signed with the 2011 cert (not the 2023 cert). But I could be wrong (or misremembering something else).
On Wed, Dec 31, 2025 at 11:26:03AM -0800, Adam Williamson wrote:
On Wed, 2025-12-31 at 17:31 +0000, Gary Buhrmaster wrote:
On Mon, Dec 22, 2025 at 4:53 PM Mateus Rodrigues Costa mateusrodcosta@gmail.com wrote:
- We are close to January, what's keeping us from receiving shims
signed with the new 2023 certs? It seems Neal said that Microsoft would start signing with the new certs in October of last year. Am I missing something?
I don't think the shims (grub, systemd-boot, ??) have needed to be reissued (and re-signed) for quite some time, so I it just did not happen (yet). I believe for Fedora the latest codes (16.1?) are in the process of being validated (and, for what is probably obvious reasons, the number of people who are authorized to work the process is almost certainly going to be extremely limited).
16.1 is already signed for Fedora[0] and is in stable for F41 and F44. It's in testing for F42 and F43, at least according to the tags. I don't remember what's going on there, honestly. We might have just forgotten about it? Kevin? Peter?
I didn't tag it into stable updates because there was a user with a issue with it on the test list and I never got any ack that that was addressed or didn't matter.
https://forge.fedoraproject.org/releng/tickets/issues/13050 was closed, but they are not tagged into stable (yet). (I reopened it).
kevin