Even if you don't block it, those will still not work after June 2026 with Secure Boot Enabled.
And there I have to clear a misconception that many people seem to be having. Maybe I am misinterpreting the context, but at any rate, the following needs to be explicitly stated:
NO, if you are using a PC in past the 2011 certs expirationd date, and you haven't updated your certs, your PC will
NOT suddenly be unable to boot 2011 signed bootloaders.
THIS IS NOT HOW CERTIFICATE EXPIRATION WORKS!
Even if all the 2011 certificates from your Secure Boot database have expired, you will still be able to install Windows 11 24H2 or Windows 11 25H2 just as you did before, in 2027 or 2028 or 2029 and so on (and no, PC manufacturers are also
NOT going to start removing the 2011 DBs or KEKs on machines they release after 2027,
because these will still very much be needed). You will not see a change of behaviour just because these certificates have expired (now, if booting Windows, you may still see these bootloaders blocked through SVN, but that has nothing to do with the cert expiration and it's a completely different matter).
So, again, it needs to be stressed out, the end date you see on a digital certificate is not an indication that it's going to suddenly stop validating anything past that date. On the contrary (at least for UEFI because Windows does something a bit different where they also take into account whether there is a signed timestamp), the certificate validation is designed in a manner to continue to work, even if all your certs have expired. Else, it would just be a pretty lousy way of "bricking" everybody's system comes a specific date...
So, if I boot a system on 2027.01.01 that has the 2011 CA certs in its Secure Boot database (and only these certs, with no revocations), this is what happens during Secure Boot validation. For the sake of this example, and to avoid the additional confusion that comes from
PCA 2011 having been revoked, I will be talking about booting a Debian 13 installation media, which is compatible with Secure Boot, and whose UEFI bootloaders are signed using one of the other
2011 CA Secure Boot certificates (but
NOT PCA 2011, which is only used for Windows bootloaders):
1. Secure Boot looks at the certificate that was used in the UEFI bootloader signature. It sees that it was signed using
Microsoft Corporation UEFI CA 2011. (which, again, is
NOT the same certificate as
Microsoft Windows Production PCA 2011). It does
NOT look at when the certificate expires.
2. Then Secure Boot looks if that certificate is in the DBX list. It doesn't find it there, so it continues.
3. Then Secure Boot looks if that certificate is in the DB list. It does find it there (after checking that the specific hash of the exceutable is also not in the DBX) it signals that the binary is trusted for Secure Boot. It still does
NOT look at when that certificate expires.
Which means that you booted Debian 13, in 2027, even as you don't have the 2023 certs installed in your Secure Boot database, and even as the Debian bootloader uses certificates that have expired. And this is what you want, because (and this is the important part so I will really emphasise it)
AS LONG AS SOMETHING HAS NOT BEEN EXPLICITLY REVOKED, IT WILL NOT STOP WORKING SIMPLY BECAUSE ONE OF THE CERTIFICATE HAS EXPIRED.
Now, and this is where the confusion takes place, what the certificate expiration date actually means is that, come 2027, neither Microsoft nor Debian will be able to continue to sign bootloaders using the 2011 certs, because the part where the expiration date
actually applies is when Microsoft or Debian sign their UEFI bootloaders for Secure Boot. At signature time, the first thing that is done is checking whether the "certificate" (it should really be called a credential here, because its certificate + private key, but for the sake of keeping things simple) you are using for the signature has expired or not. And if that "certificate" has expired, the signature process bails out and reports an error (and no you can't
"just set back the clock and fool the signature process" there).
Which means that, come 2027, Microsoft and Debian have no choice but to sign their bootloaders using the 2023 version of the "certificates".
Which means that, come 2027, the expiration of the 2011 certificate
IS indeed a problem that you need to address. But that's not because existing stuff using the 2011 certs suddendly stops to boot. That's because
new stuff using the 2023 certs can't be booted.
So please, do not present the 2011 cert expiration as a new Y2K bug, where everything will suddenly stop to work on a specific date, because I can assure you that, if your Windows or Linux installation booted fine the day before the expiration date, it will still boot fine the day after the expiration date, even if your machine is completely isolated and not receiving OS updates.
The cert "apocalypse" only applies to
new stuff that you will want to boot after that date, and that has no choice but to use the 2023 certs. And the thing is that, technically, if Microsoft doesn't find a vulnerability in their Windows bootloaders and does not need to alter them, they could still release Windows 11 27H2 that uses the same 2011 signed bootloaders they used in earlier Windows version, and make sure that, even people who haven't updated their platforms at all will still be able to install 27H2...
So, no, come the 2011 expiration date (and in the absence of DBX changes, but these have nothing to do with the cert expiration), nothing extra is going to be blocked compared to what was already blocked before that date, and 2011 signed stuff will still happily be booted by your platform.
Which is very much what you want, and what the people of UEFI designed Secure Boot for.
