How to Set Up Secure Boot with Your Own Keys Using sbctl

Secure Boot is not a Microsoft switch, despite some firmware menus doing their best to suggest otherwise. It is a UEFI policy mechanism: firmware will execute an EFI binary only when its signature chains to a trusted certificate, or its hash is explicitly trusted.

With sbctl, you can replace the manufacturer's key hierarchy with one you control, sign your Linux boot chain and keep those signatures updated. The awkward bit is that a mistake can leave the machine unable to boot. This is therefore a job for a keyboard, physical access and a recovery USB, not an unattended server several hundred miles away.

What the three keys actually do

The hierarchy has three relevant layers:

• PK, the Platform Key, establishes who controls the platform.
• KEK, the Key Exchange Key, authorises changes to the signature databases.
• db, the allowed-signature database, contains the certificate used to accept signed EFI programs.

The corresponding private db key signs your boot loader, unified kernel images and other EFI programs. The firmware receives only public certificates. Under the UEFI Secure Boot model, removing the PK puts the machine into Setup Mode, where a new hierarchy can be enrolled without authorisation from the old one.

This does not make a compromised running system trustworthy again. By default, sbctl keeps file-based private keys under /var/lib/sbctl, and its documentation states that password protection is not supported. Root can therefore steal the signing key. Secure Boot is chiefly useful against unauthorised changes to the boot path while the machine is switched off, and as one component in a measured or encrypted boot design.

Prepare an escape route first

Before changing firmware keys:

• Make a current backup and test that it can be read.
• Create a Linux recovery USB that boots on this machine.
• Confirm that the firmware can disable Secure Boot or restore factory keys.
• Record the current boot entries with efibootmgr -v.
• If Windows uses BitLocker, obtain and verify the recovery key before proceeding. Changing Secure Boot configuration can change TPM PCR measurements and trigger recovery, as described in Microsoft's BitLocker recovery documentation.

Check that Linux was booted through UEFI and that the EFI variables are available:

test -d /sys/firmware/efi/efivars || echo "Not booted in UEFI mode"
findmnt /boot /boot/efi /efi
sudo efibootmgr -v

The EFI System Partition might be mounted at /efi, /boot or /boot/efi. Do not copy example paths blindly. Firmware is remarkably literal about files which no longer exist.

Install sbctl and inspect the current state

Use your distribution's packaged version where possible. On Arch Linux:

sudo pacman -S sbctl
sudo sbctl status
sudo sbctl verify

The upstream project also documents packages for Alpine, Gentoo and openSUSE, with unofficial packaging for some other distributions. Distribution packaging matters because kernel and boot-loader hooks are what keep signatures valid after upgrades.

sbctl verify scans the ESP and its saved-file database. Its output is a useful inventory, not an instruction to sign every executable it finds. Old recovery tools and abandoned boot loaders may appear there too.

Put the firmware into Setup Mode

Reboot into the firmware interface:

systemctl reboot --firmware-setup

Names vary, but look for Secure Boot key management and choose an option such as "Clear Secure Boot keys" or "Delete all keys". Leave Secure Boot enforcement disabled while preparing the boot chain. Back in Linux, check the result:

sudo sbctl status

You want Setup Mode enabled and Secure Boot disabled. A firmware option named "Custom Mode" is not necessarily the same thing. The sbctl manual warns that some implementations use Custom Mode merely to disable verification. Trust the reported Setup Mode state rather than the marketing department responsible for the firmware menu.

Create the keys and sign the active boot chain

sudo sbctl create-keys
sudo sbctl status

This creates the PK, KEK and db material under /var/lib/sbctl. Make an encrypted offline backup of that directory now. The PK and KEK are particularly useful for later recovery or rotation; the db private key must remain available if this installation is to sign new kernels automatically. Treat the backup like any other private key store, not as a handy unencrypted tar file left on the ESP.

Now identify the files genuinely used during boot. A typical systemd-boot installation with a unified kernel image might require:

sudo sbctl sign --save /efi/EFI/systemd/systemd-bootx64.efi
sudo sbctl sign --save /efi/EFI/BOOT/BOOTX64.EFI
sudo sbctl sign --save /efi/EFI/Linux/linux.efi

Replace /efi and the filenames with the paths on your machine. The --save option is doing useful work: it records each path so that sbctl sign-all can sign replacements after an upgrade.

For GRUB, the first EFI program may instead be something like /boot/efi/EFI/Linux/grubx64.efi. Signing GRUB gets it past firmware verification, but GRUB's subsequent verification of kernels and modules depends on how that distribution built and configured it. A signed unified kernel image gives a cleaner boundary because the kernel, initramfs and command line can be packaged into one EFI executable. Use the UKI tooling supplied by the distribution's initramfs generator rather than adding another home-made build pipeline merely for sport.

Check the result:

sudo sbctl list-files
sudo sbctl verify

Every executable in the active path must be accepted. An unsigned unrelated EFI utility can remain reported, provided no boot entry or loader tries to execute it.

Decide whether to retain Microsoft certificates

There are two sensible policies. The compatibility policy enrols your own PK, KEK and db certificate while retaining Microsoft's certificates:

sudo sbctl enroll-keys --microsoft

This is the upstream recommendation because Windows, some firmware update tools and some hardware Option ROMs rely on Microsoft-signed code. You still control the platform and can sign your own images; Microsoft-signed images are simply an additional trusted set.

A strict own-keys-only policy uses:

sudo sbctl enroll-keys

Use that only after checking the hardware and accepting that Windows or an Option ROM may stop working. Graphics, storage and network adapters can contain UEFI drivers executed before the operating system. sbctl checks the TPM event log for evidence of Option ROMs and may refuse unsafe enrolment. Do not reach immediately for --yes-this-might-brick-my-machine; unusually honest flag names deserve to be believed.

After enrolment, sbctl status should show Setup Mode disabled. Secure Boot can still be disabled at this point, which is useful because the signed chain has not yet proved that it boots.

Enable enforcement and test it

Reboot into firmware setup, enable Secure Boot and select the normal user or deployed mode rather than a mode which suppresses verification. Then boot Linux and run:

sudo sbctl status
sudo sbctl verify

The desired state is Secure Boot enabled, Setup Mode disabled and all active boot-chain files signed. If the machine fails before reaching the boot loader, disable Secure Boot and inspect the first EFI executable. If the boot loader appears but the kernel fails, inspect the next stage, including GRUB policy or the UKI signature. Restoring factory keys is the last-resort route back to vendor trust.

Make updates prove themselves

A setup which works once but breaks on the next kernel upgrade is unfinished. The saved-file database allows a manual repair:

sudo sbctl sign-all
sudo sbctl verify

Confirm that your distribution installs an sbctl, kernel-install or package-manager hook, then perform one ordinary kernel or boot-loader update while Secure Boot is still easy to recover. Verify the new files before rebooting. Updates can replace an EFI binary rather than modifying it, so the replacement needs a fresh signature even when its pathname has not changed.

Keep the recovery media, offline key backup and BitLocker recovery material after the successful test. Secure Boot key ownership removes a third party from part of the trust chain, but it also removes the convenient fiction that somebody else will recover the machine when a signing hook quietly fails.