[Feature]: Provide a KEK 2011 signed update package for the "Microsoft Corporation UEFI CA 2011" cert

[pbatard]

Feature Overview

https://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/Optional/DB/amd64/ provides official KEK 2011 signed update packages for the 2023 DB certificates, including 3rd Party and Option ROM which is great, as it means people can install the new 2023 certificates either from their OS, or outside the OS (using the UEFI Shell for instance) without having to place the platform in Setup Mode to do so.

However, it does not contain similar signed installation packages for the 2011 DB certificates, namely Microsoft Windows Production PCA 2011 (for current Windows bootloaders) and Microsoft Corporation UEFI CA 2011 (for current 3rd party bootloaders).

While not providing a signed installation package for Microsoft Windows Production PCA 2011 is not a major issue, since that certificate should ultimately be revoked, not providing a package for Microsoft Corporation UEFI CA 2011 that is signed by Microsoft Corporation KEK CA 2011 actually is as there are multiple critical scenarios where also having the signed installation package for the 2011 3rd party certificate is paramount.

For instance, there do exist platforms where the 3rd party cert(s) (be it the 2011 or 2023 version) are not present by default and can not be enabled in the UEFI settings, either due to OEMs having overlooked providing that capability or because the user may have used Setup Mode to reinstall the DB themselves and chosen not to add that certificate at the time. And on these platforms, the user may not want to enter Setup Mode again to re-install all the certs or may not be able to get the platform into Setup Mode at all, if the OEM doesn't provide the feature (and there do exist real-life examples of such platforms where both the 3rd party certs are missing and where Setup Mode cannot be enabled by the user).

And whereas one can use the signed packages to install the 2023 certs to remedy this without having to enter Setup Mode, doing the same for the 2011 certs is not possible as (to my knowledge) Microsoft has yet to publish signed installable version of those, in the same way as they do for the 2023 certs.

This is extremely problematic if, say, the user wants to be use a PCIe device with an Option ROM that has been signed using the 2011 3rd party certificate, especially as one can not expect the manufacturers of said device, which might be long gone, to provide a new ROM signed with the 2023 certs, or if the user wants to run 3rd party Secure Boot signed bootloaders.

Which means that, on the same ground as the signed 2023 cert packages are a welcome addition to this repository, as they allow users to install the 2023 certs without having to invoke Setup Mode, there is a real need for Microsoft to also provide signed cert packages for the 2011 certs or at the very least, for the Microsoft Corporation UEFI CA 2011 3rd party certificate.

An additional bonus (though I have to stress out that this is not my primary reason for requesting this) is that it would enable OS-independent application like Mosby that aims at dealing with the issue of the 2023 cert upgrade, with the ability to install/fix missing certs, including the 2011 ones, again, without having to first ask the user to place the platform in Setup Mode, which, even if the platform does provide the option, a lot of users find difficult.

Solution Overview

Just as https://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/Optional/DB/ provides signed installation packages for the 2023 certs, that were signed with the Microsoft Corporation KEK CA 2011 KEK credentials, we ask that it also provides signed installation packages for the 2011 3rd party cert, namely Microsoft Corporation UEFI CA 2011, so that users of platform that might be missing the certificate can install it.

At Microsoft's discretion (again, considering that this is a certificate that should ultimately be revoked), it may also want to provide a similar signed installation package for Microsoft Windows Production PCA 2011, though this is of course less critical, but we could envision that there may exist scenarios where the user might be missing that cert and want to install it so they can run current Windows.

Alternatives Considered

There are no alternatives achievable on platforms that are missing Microsoft Corporation UEFI CA 2011 in their DB and that are also missing the means to place the platform in Setup Mode.

This means that the lack of provision of such a signed installation package from Microsoft would result in users of these platforms not being able to use some of their devices or run alternative (non Windows) bootloaders with Secure Boot enabled.

And considering that Microsoft is already providing the 2023 version of what we request, we see no valid reason (outside of it not having be requested before) not to also provide the 2011 version of similar signed cert packages. The Microsoft Corporation UEFI CA 2011 certificate is trusted and not being revoked, therefore there is no security risk posed by allowing users, who might be lacking said certificate on their platform, to install it manually should they choose to do so.

Urgency

High

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

Obviously, since this requires access to the Microsoft KEK credentials, this is not something anybody else but Microsoft can accomplish.

Also, we are tagging this HIGH PRIORITY because the current KEK expires in exactly a month (2026.06.24) and the assumption is that the platform will have MS KEK 2011 installed but it may not have MS KEK 2023, so getting a signed package from MS KEK 2023 would be more problematic than one with MS KEK 2011. And judging from #396 and #255, in which Microsoft took more than a month to coordinate between its internal teams, we are obviously very worried that, if this takes the same amount of time, it will no longer be possible for Microsoft to create a signed package from the 2011 KEK...

[Wack0]

There are no alternatives achievable on platforms that are missing Microsoft Corporation UEFI CA 2011 in their DB and that are also missing the means to place the platform in Setup Mode.

Windows bootloader exploit. That's what you have, and thanks to MS's solution to mass vulnerability discovery in grub being "OEMs can remove the third party cert by default if not required", that's probably all you're going to have.

I will be very surprised if this ever happens, after all MS says "just buy a new PC with Windows 11"...

[pbatard]

Well, one could argue that, were Microsoft to refuse to provide these, and considering that one can very much purchase a "locked down" PC in the EEC that one could qualify as actively degrading the Linux experience by forcing its users to run it with Secure Boot disabled (in which case in a very circuitous way, Microsoft could also state that Linux is less secure than Windows... due to its forcing Linux users to run their OS with Secure Boot disabled and therefore making it more vulnerable), this could legally be construed as anticompetitive behaviour, similar to the ones Microsoft got pinned for in the past by the European Union.

So I will state that it is in fact in Microsoft's interest to provide such a signed package, given that there are no actual technical or security constraints in doing so, and that, should Microsoft's refuse to provide one without proper justification, that refusal could very much be used against them in a court of law.

In other words, if it has to become a legal matter, I am going to point out that I am an EEC resident (Irish national), and that, as the owner of such a locked down machine (purchased from an Irish electronics retailer), I believe that would have some ground to challenge the decision not to provide such an installation package or, at the very least, to ask for an investigation into whether the practice of (seemingly intentionally) degrading the experience of competing software could not be construed as anticompetitive. Obviously, since this is still very much a technical request, I hope it doesn't have to come to that...

And also @Wack0, you should realise that, once Linux distros start to sign the Shim with the 2023 3rd party cert, and given that Microsoft, through the 2023 cert upgrade, does provide the ability for users of locked down machines to actually install said certificate and therefore boot such distros with Secure Boot enabled, even an intentional attempt from Microsoft to degrade the ability to run Linux on some platforms is going to become moot, as users will be able to install the 2023 3rd party cert and boot the Shim and other modern Secure Boot signed bootloaders as they please. As a matter of fact, I very much plan to make it easy for users to accomplish just that action through my Mosby application, per pbatard/Mosby#35, which is in part why I made this request.

So really, considering that (in a few months, once the Shim has switched to the 2023 signing credentials) even an intentional Microsoft effort to lock down some OEM machines, if it is indeed a corporate decision, will have become moot as it will be super easy to work around. Therefore, there is little point not to also provide the signed 2011 3rd party cert installation package as, besides benefiting folks who want to run Linux, and as I also explained above, it would benefit Windows users who want to use existing Option ROMs, so in the end, not providing such a package will probably do more harm than good to the very users Microsoft should care about.

[Wack0]

as users will be able to install the 2023 3rd party cert and boot the Shim and other modern Secure Boot signed bootloaders as they please

unfortunately this is incorrect. newer systems will use the new KEK only and a db update for the new third party cert hasn't been signed using the new KEK, only the old one. see 1.3.4.3 Microsoft KEK on the Windows Secure Boot Key Creation and Management Guidance page

that said, Linux distros have started to sign shim with the 2023 cert (latest fedora shim package is signed by both).

[pbatard]

I think you are misunderstanding how it works.

1. KEK 2011 is not being deprecated or revoked. I am not aware of any platform that plans to remove MS KEK 2011. Therefore having a KEK 2011 signed package is not an issue, on the contrary. And yes, I did test installing the 2023 third party cert on a locked platform, which was fine, since that platform does have MS KEK 2011 and MS KEK 2023. The installation went absolutely fine.
2. Even if some OEMs start to remove MS KEK 2011 and only keep MS KEK 2023, then we can ask for signed packages using KEK 2023. But, unlike getting anything signed with MS KEK 2011, this is not an urgency, especially, again, as I am not aware of any platform where on MS KEK 2023 is available.

So, again, as long as OEMs aren't forcibly removing MS KEK 2011 (but really, why would they?), my statement that "users will be able to install the 2023 3rd party cert and boot the Shim and other modern Secure Boot signed bootloaders as they please" is correct. And I did validate it in practice on a "locked down" platform.

[pbatard]

Also, @Wack0, is there any way you could try to be constructive with this issue, instead of trying to shut down this request for no apparent good reason? Unless you are working for Microsoft, I really fail to see what you are trying to accomplish in trying to promote the idea that this is something foolish to request. I explained at length the various reasons why this would be helpful for all users (not just Linux ones), yet I get the feeling that you are somehow rooting for this request to be shot down even before Microsoft gets a chance to look into it. This seems exceedingly counter-productive and, when the ultimate goal is to help users, downright unhelpful.

Or are you arguing that manufacturers should just be entitled to lock down platforms and do as they please, and that we should just accept the erosion of our freedoms?

[Wack0]

KEK 2011 is not being deprecated or revoked.

on existing systems this is true, as far as I am aware KEK 2011 will indeed stay. but MS are advising OEMs that new systems should only have the new KEK 2023.

as long as OEMs aren't forcibly removing MS KEK 2011

It's very much possible that a UEFI firmware update will replace KEK 2011 in the defaults with KEK 2023. Not necessarily removing it immediately, but removing it when changing secure boot settings back to default. And new systems that come with the updated UEFI firmware will therefore have only KEK 2023 and not KEK 2011, as the newest guidelines state.

you are somehow rooting for this request to be shot down even before Microsoft gets a chance to look into it

I would love for this request to happen. But unfortunately, there's existing documentation enough to show that it most likely won't happen.

[pbatard]

but MS are advising OEMs that new systems should only have the new KEK 2023.

Then, as I said, we will ask for KEK 2023 signed packages.

I would love for this request to happen.

Then help push for it, instead of dangling some unreferenced documentation that, as we all know in any large corporation, may have been written by somebody who does not understand all the consequences of what they are advising, and that might not reflect the actual interests of the corporation once technical people start looking into it. Policies that may look good to some on paper may prove disastrous in practice. Especially, if users have to start a legal case or make noise, as happened with the not so dissimilar WinRT Secure Boot ARM lockdown that Microsoft once tried to enforce, which, AFAIK, did force Microsoft to review its stance.

And if we have to prepare to go through a legal challenge, and since you mention existing documentation that appears to indicate that Microsoft is pushing OEM to lock down their platforms, care to provide URLs to said documentation? Coz, at least to me, that looks like anticompetitive behaviour that would warrant investigation, in a similar way as bundling a browser or a media player with your OS might warrant investigation and legal proceedings.

[Wack0]

I'm not saying that MS has documentation to indicate that OEMs are being pushed to lock down their platforms (other than the thing with "3rd party UEFI CA not trusted by default, with BIOS option for enabling trust" for "secured core PCs" that's well known and well documented at this point).

What I'm trying to say is that MS has documentation specifying that new systems will not have the KEK 2011 present, only the KEK 2023. The required KEK certs changed over time from 2011 only to 2011+2023 to 2023 only, the change to remove 2011 KEK happened between April and July of 2025 as per Wayback Machine. And thanks to the thing with "3rd party UEFI CA not trusted by default, with BIOS option for enabling trust", that's the most likely reason why I don't think any of the 3rd-party CAs will be signed by KEK 2023, not the old one by KEK 2011. Personally, I am of the opinion that requiring "enabling the option to boot third-party bootloaders" was a piece of obvious security theatre, and shouldn't have happened, especially now considering the new policy changes for even getting a third-party bootloader signed in the first place...

[pbatard]

And thanks to the thing with "3rd party UEFI CA not trusted by default, with BIOS option for enabling trust", that's the most likely reason why I don't think any of the 3rd-party CAs will be signed by KEK 2023

I don't see how that follows or make a future request for 3rd-party CAs signed by KEK 2023 a NO_GO prospect.

We have modern PC platforms, that consumer can purchase, that go way further than Secured-core and that, as opposed to Secure-core do not provide a "BIOS option for enabling trust" (for 3rd party CA).

So, in the absence of other public documentation related to more "secure" than Secure-core platforms, wehave two alternatives here, and only two:

• Either the OEM of these PCs made a mistake and went beyond what Microsoft currently stipulates to ensure the "security" of Secure Boot, by not providing the means to enable 3rd party CA. In that case, contacting the OEM technical support has to result in that OEM providing a firmware update, that enables that option. But also, if that is the case, then there is no reason for Microsoft not to provide us with signed 3rd party update packages (with either the 2011 or the 2023 KEK), since it wasn't a matter of public policy that led the OEM not allow the user to install the 3rd party cert(s), in which case, there is zero legal or political obstacle for Microsoft to satisfy our request.
• Either the OEM got a directive from Microsoft not to add the means to enable 3rd party CA, which, since you (or someone else) hasn't pointed to public documentation to that effect, would go well beyond what Microsoft publicly documents in terms of Secure Boot guidelines, and, if confirmed by the OEM (in case, when contacting them for a firmware update, they indicate that they can not satisfy that request, by policy, since they will have to provide some form of justification if legally challenged), in which case we would have strong circumstantial evidence that there exists a secret undocumented policy from Microsoft, that goes way further than what their public requirement states, in asking OEM not to provide a feature that, again publicly, Microsoft states an OEM should provide.

Again, in the first case, then there is no reason for Microsoft not to satisfy our request, be it for 2011 or 2023 KEK signed 3rd party certs. They may of course indicate that it should primarily be the job of the OEM to sort it out and add the certs themselves, but, if we can demonstrate that, for one reason or another, the OEM is declining to do that or that there exists scenarios where it will be helpful not to have to rely on OEMs that, for one reason or another, might be unwilling to do so, it should follow that Microsoft would want to help users match its current platform security guidelines.

In the second case, then things are a lot more dicey for Microsoft, because then, with the uncovering circumstantial evidence of private/secret directives, that look downright anticompetitive (which would also explain the reason for their secrecy), users of said platforms now have a legal challenge against Microsoft, which, while it might not yield the signed packages we request, would yield something a lot more "interesting", that I would assert Microsoft is unlikely to want to face...

Which means that (again, in the absence of public documentation from Microsoft that states that, in the matter of securing platforms for Secure Boot, it advises OEM not to even allow the optional provision of third party certs in the Secure Boot DB), Microsoft should be eager to satisfy our request either way, as it will have an awfully hard time justifying why it does not see it as an option, and the scrutiny associated with not satisfying our requests may not at all be in Microsoft's legal interests.

Hence why I don't see how you come to the conclusion that Microsoft should be unwilling to do so. On the contrary, with the many question marks and conditionals being raised with regards to potential shady practices, that would go contrary to Microsoft's official public documentation with regards to what it considers proper for the implementation of Secure Boot, Microsoft should be eager to squelch the mounting speculation we have here,by satisfying this request and demonstrate that:

1. The guidelines you reference are still the official guidelines Microsoft pushes when it comes to OEM implementation of Secure Boot.
2. If an OEM deviates from said guidelines and goes way further than what Microsoft officially advises, Microsoft is willing to help users go back to the official guidelines.