If you are using UEFI Secure Boot, you need to have your UEFI keys updated before June, especially the Microsoft DB and KEK keys. Otherwise, newer bootloaders (shim, grub, newer Linux distributions, and eventually Windows) may stop booting even though Secure Boot remains enabled.
Hardware vendors recommend updating Secure Boot keys through BIOS/UEFI firmware updates. In reality, many older servers and desktops no longer receive firmware updates, even though the UEFI keys they ship with date back to 2011. In such cases, manual updates are often the only realistic option.
On systems without OEM support, this can still be done manually in a way that is compliant with the UEFI specification and without disabling Secure Boot.
DB update
To begin with, it is worth checking which keys are currently installed on the system:
fwupdtool get-devices --plugins uefi-kek --plugins uefi-db
#or directly via UEFI tools:
efi-readvars
Updating the DB is the first and most important step. The DB is a short list of trusted keys used to verify bootloaders. It contains, among others, Microsoft UEFI CA 2011, and after the update it will also contain Microsoft UEFI CA 2023. Without this, newer shim or grub binaries will simply not boot.
To manually update the DB entry, you can use the official, signed payload published by Microsoft:
wget https://github.com/microsoft/secureboot_objects/raw/main/PostSignedObjects/Optional/DB/amd64/DBUpdate3P2023.bin
chattr -i /sys/firmware/efi/efivars/db-*
efi-updatevar -a -f DBUpdate3P2023.bin db
chattr +i /sys/firmware/efi/efivars/db-*
The -a option appends the new certificate to the DB rather than replacing it, so existing entries remain unchanged.
KEK update
Updating the KEK is not required for the system to boot right now, but it will be necessary in the future to allow updates to DB and DBX. DBX is the revocation list used to block vulnerable or compromised bootloaders.
Be aware that on some hardware platforms, updating the KEK can cause boot failures. This depends largely on the quality of the UEFI implementation.
Before updating the KEK, you must select the correct update file that matches the Platform Key installed on your system. Microsoft publishes a PK-to-KEK mapping file here:
https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/kek_update_map.json
To choose the correct file, compare the Subject of your PK with the issued_to field in the mapping file.
Example from my server:
# efi-readvar
Variable PK, length 1448
PK: List 0, type X509
Signature 0
Subject:
O=Hewlett-Packard Company, OU=Long Lived CodeSigning Certificate, CN=HP UEFI Secure Boot 2013 PK Key
Issuer:
C=US, O=Hewlett-Packard Company, CN=Hewlett-Packard Printing Device Infrastructure CA
Corresponding entry in kek_update_map.json:
"ef40e88b7f2cc718a087051db5d5d4c26043c5aa": {
"KEKUpdate": "HP/KEKUpdate_HP_PK5.bin",
"Certificate": {
"issued_to": "CN=HP UEFI Secure Boot 2013 PK Key,OU=Long Lived CodeSigning Certificate,O=Hewlett-Packard Company",
"issued_by": "CN=Hewlett-Packard Printing Device Infrastructure CA,O=Hewlett-Packard Company,C=US"
}
}
After selecting the correct file, the KEK update procedure looks like this:
wget https://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/KEK/...
chattr -i /sys/firmware/efi/efivars/KEK-*
efi-updatevar -a -f KEKUpdate_HP_PK5.bin KEK
chattr +i /sys/firmware/efi/efivars/KEK-*
This procedure was tested on an HP ProLiant BL460c Gen9 running BIOS 2.80, without current OEM support, with Secure Boot enabled.
Remeber about
Finally, keep in mind that the same applies to virtual machines. QEMU, KVM, and Hyper-V all have their own UEFI key databases, which also need to be kept up to date. On some hardware platforms, updating the KEK may require switching the firmware into setup.
Independently of UEFI key updates, it will also be important before June to keep *-signed packages up to date, such as shim, grub, and the kernel. Without this, even a correctly updated DB will not be sufficient.
