Existing systems are going to continue to boot. The expiry date is enforced for signing new binaries, not for deciding whether an already signed binary is allowed to boot (barring buggy firmware).
Shim, the first stage bootloader on Linux, is designed to be updated infrequently. Distributions embed their own signing certificate in it and have that binary signed by Microsoft. The actual bootloader (typically either grub or systemd-boot) is then signed with the distribution certificate, as is the kernel. Distributions get to set their own policy around how long that certificate lasts for, it's entirely unrelated to the Microsoft certificate expiry.
No, distros uses a shim binary that is less likely to need updates. If that shim needs an update (only signed with the new key) then we get into a situation where old machines will fail to boot it.
Comments
Existing systems are going to continue to boot. The expiry date is enforced for signing new binaries, not for deciding whether an already signed binary is allowed to boot (barring buggy firmware).
https://mjg59.dreamwidth.org/72892.html (Secure boot certificate rollover is real but probably won't hurt you)
https://wiki.debian.org/SecureBoot/CAChanges#OMG.21.21.21_Wi...
Does this means that updating my system kernel would fail or even break boot?
Shim, the first stage bootloader on Linux, is designed to be updated infrequently. Distributions embed their own signing certificate in it and have that binary signed by Microsoft. The actual bootloader (typically either grub or systemd-boot) is then signed with the distribution certificate, as is the kernel. Distributions get to set their own policy around how long that certificate lasts for, it's entirely unrelated to the Microsoft certificate expiry.
No, distros uses a shim binary that is less likely to need updates. If that shim needs an update (only signed with the new key) then we get into a situation where old machines will fail to boot it.