There is currently a lot of FUD regarding the expiration of Microsoft’s UEFI Secure Boot certificates this June. Many Linux users are understandably concerned that their machines will refuse to boot if Secure Boot remains enabled. I spent some time this morning sorting through the noise. Here is what you actually need to know:

👉 Expiration dates aren’t strictly enforced by default The UEFI specification and its reference implementation (Tianocore) do not mandate checking the expiration dates of certificates. The reasoning is practical: a computer needs to be able to boot even if the CMOS battery dies and the real-time clock (RTC) is broken. The caveat: Your specific motherboard or UEFI vendor might have implemented their firmware differently, which is where the uncertainty comes from.

👉 To be on the safe side, you can verify that the new Microsoft certificate is present in your system’s UEFI Secure Boot database. You can extract and inspect this directly from your Linux terminal:

# Extract the db variable
efi-readvar -v db -o db.esl

# Convert the signature list to certificates
sig-list-to-certs db.esl db_cert

# Inspect each generated db_cert-*.der file
openssl x509 -inform der -in db_cert-NNN.der -noout -subject -issuer -dates

(Check your specific db_cert-N.der files). You are looking for an output where the Common Name (CN) is “Microsoft UEFI CA 2023”.

👉 To ensure a smooth transition, your bootloader should be signed by both the old and the new Microsoft certificates. In my case, using shim from OpenSUSE, you can verify the signatures with sbverify:

sbverify --list /boot/efi/EFI/opensuse/shim.efi

@rw Thanks, my /boot/efi/EFI/ubuntu/shimx64.efi is only signed by the "Microsoft Corporation UEFI CA 2011: certificate. What's next?
Note that this machine was installed only last year.
The older machine doesn't even have the 2023 certificate.

@geert I'm not using Ubuntu, but I think they'll ship an updated shim sooner or later. OpenSUSE did so in March. To get the new Microsoft CA Cert, you need an update from your mainboard vendor. With some luck with fwupd.
Finally, there is a good chance that this a nothing-burger, since your UEFI is unlikely to enforce the expire date.

@geert FYI:
https://discourse.ubuntu.com/t/microsoft-uefi-ca-rotation-what-it-means-for-ubuntu-users-and-vendors/82652#p-214189-impact-3

@rw efi-readvar is not included in Linux Mint (not even the Ubuntu edition), FYI.

@USBTypeSteve huh? It's part of `efitools`, just install the package.

@rw
do we know of any implementation that does expiration checks?

use mokutil, no need to decode by hand and installed on any system booting from a Microsoft signed loader.

there is a small number of systems failing with dual signed. Debian tracks them somewhere.

@waldi I don't know of any. Thanks for the mokutil hint!

@rw If `mokutil` is installed, `mokutil --db --short` will show the certificates.

@rw Just saying that should be part of the instructions, if you are looking for simplicity. The problem with all of these guides is they are lacking steps or guidance if the command doesn't exist, "just run it" doesn't fly.

@USBTypeSTeve @rw At least Ubuntu tells you:
$ efi-readvar -v db -o db.esl
Command 'efi-readvar' not found, but can be installed with:
sudo apt install efitools

@rw

> Expiration dates aren’t strictly enforced by default The UEFI specification and its reference implementation (Tianocore) do not mandate checking the expiration dates of certificates

That's not quite true: Expiration dates are specifically mandated to be ignored by the UEFI spec, so *every* UEFI should continue to operate with expired certificates. The origin of this was concern the UEFI clock was probably inaccurate and could be subject to tampering anyway.

@jejb Thanks for pointing this out!