Secure Boot on Linux: Enroll a MOK Key and Fix "Key was rejected by service"

mokutil --sb-state
# Ubuntu
sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
# Debian and other DKMS systems
sudo mokutil --import /var/lib/dkms/mok.pub
# Fedora (akmods)
sudo mokutil --import /etc/pki/akmods/certs/public_key.der
sudo reboot

Identify your case

How Secure Boot works on Linux

The firmware trusts Microsoft's keys. Distributions ship a small bootloader, shim, signed by Microsoft. Shim contains the distribution's own key and verifies GRUB and the kernel with it. When the kernel sees it was booted with Secure Boot, it enters lockdown and refuses to load any module that is not signed by a trusted key.

Modules shipped by your distribution are signed with its key. Modules built on your machine (NVIDIA from DKMS/akmods, VirtualBox's vboxdrv, v4l2loopback, ZFS, Wi-Fi drivers from GitHub) are signed with a key generated on your machine, and that key is only trusted after you enroll it as a Machine Owner Key through shim's MokManager.

Diagnose step by step

Step 1: Check Secure Boot and lockdown

mokutil --sb-state
cat /sys/kernel/security/lockdown

Example output:

SecureBoot enabled
none [integrity] confidentiality

SecureBoot enabled and lockdown integrity mean unsigned or unknown-key modules will be refused. If Secure Boot is disabled, your module problem has another cause: check sudo dmesg | tail and dkms status.

Step 2: Find out who signed the module

modinfo -n vboxdrv
modinfo -F signer vboxdrv
modinfo -F sig_key vboxdrv

An empty signer means the module is unsigned; DKMS was not configured to sign or the build failed. A signer such as DKMS module signing key or akmods local key means it is signed and you only need to enroll the key.

Step 3: List the keys already enrolled

mokutil --list-enrolled | grep -E 'Subject:|CN='
sudo dmesg | grep -i 'x509'

The kernel log shows every certificate loaded at boot (Loaded X.509 cert '...'). If the module's signer is not among them, enroll it.

Fix: enroll the MOK

Ubuntu and Linux Mint

Ubuntu's DKMS signs modules with /var/lib/shim-signed/mok/MOK.der. Driver installers usually ask for a password during installation; if you skipped it, enroll it now:

sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
# or let Ubuntu create the key if missing and enroll it
sudo update-secureboot-policy --enroll-key

Debian

Recent DKMS generates its key at /var/lib/dkms/mok.key and /var/lib/dkms/mok.pub when it first builds a module:

sudo mokutil --import /var/lib/dkms/mok.pub

Fedora (RPM Fusion akmods)

akmods signs modules with a local key. Generate it if it does not exist, enroll it, then rebuild:

sudo kmodgenca -a
sudo mokutil --import /etc/pki/akmods/certs/public_key.der
sudo akmods --force

openSUSE

Kernel module packages from openSUSE are signed by SUSE. Third-party KMPs such as the NVIDIA driver register their certificate for enrollment during installation, so watch for the MokManager screen on the next boot. Locally built modules need a key you create (manual signing below).

Complete the enrollment at boot

1. Run the mokutil --import command and enter a one-time password twice. A simple one is fine; you need it only once.
2. Reboot. A blue Perform MOK management screen appears right after the firmware logo. Press a key within the countdown.
3. Choose Enroll MOK → Continue → Yes, type the password, then Reboot.
4. After boot, load the module: sudo modprobe vboxdrv or nvidia-smi.

If the screen did not appear, the request is still pending. Check with mokutil --list-new and reboot again, or import again. On some laptops a USB keyboard does not work in MokManager; use the built-in keyboard.

Fix: sign a module manually

For modules that are not built by DKMS or akmods, create a key once, enroll it, and sign each module after every kernel update:

# work in a root shell so the key stays in /root
sudo -i
mkdir -p /root/mok && cd /root/mok
openssl req -new -x509 -newkey rsa:2048 -nodes -days 36500 -subj "/CN=Local module signing/" -keyout MOK.priv -outform DER -out MOK.der
chmod 600 MOK.priv
mokutil --import MOK.der
# after enrolling and rebooting, sign the module (again as root, in /root/mok)
/usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 MOK.priv MOK.der $(modinfo -n mymodule)
modprobe mymodule

The sign-file path differs by distro: on Fedora it is /usr/src/kernels/$(uname -r)/scripts/sign-file. If the module file is compressed (.ko.zst or .ko.xz), decompress it, sign it, and compress it again, or point DKMS at your key instead with mok_signing_key and mok_certificate in /etc/dkms/framework.conf.

Fix: VirtualBox specifically

VirtualBox needs its host modules (vboxdrv, vboxnetflt, vboxnetadp) built for your running kernel. "Kernel driver not installed (rc=-1908)" on VM start means they are not loaded.

dkms status | grep -i vbox
sudo modprobe vboxdrv

• Distribution package (virtualbox plus virtualbox-dkms on Ubuntu, from RPM Fusion on Fedora): the modules are built by DKMS or akmods and signed with the local key, so enrolling the MOK as above is enough.
• Oracle's own package: run sudo /sbin/vboxconfig after every kernel update. Current versions sign the modules with a key they look for in the DKMS location; if loading is still rejected, sign the three modules manually with the commands in the previous section.

An alternative that avoids out-of-tree modules entirely is KVM with virt-manager or GNOME Boxes: KVM is part of the kernel and needs no signing.

After kernel updates

You enroll a MOK once. After that, DKMS and akmods sign each rebuilt module with the same key automatically, so updates keep working. Things that do require attention:

• Modules you signed by hand must be re-signed after every kernel update, because the new kernel gets a freshly built module file.
• If you reinstall the OS, the old key files are gone but the old certificate stays enrolled in MOK. Enroll the new key; optionally remove the stale one with sudo mokutil --delete old.der.
• A firmware reset to factory defaults can clear the MOK list on some machines. Re-run the import if modules suddenly stop loading after a BIOS update.

Fix: "Verifying shim SBAT data failed: Security Policy Violation"

SBAT is a revocation list for old, vulnerable shim and GRUB versions. A firmware or Windows update can write a newer SBAT policy, after which an older shim on your Linux install is refused before GRUB even starts. To recover:

1. Disable Secure Boot temporarily in the firmware setup.
2. Boot Linux and update everything, which brings in a current shim: sudo apt update && sudo apt full-upgrade, sudo dnf upgrade --refresh, or sudo zypper dup.
3. Optionally clear the stored SBAT policy so the new shim applies its own: sudo mokutil --set-sbat-policy delete, then reboot once.
4. Re-enable Secure Boot.

If the system still will not boot, use the GRUB rescue guide to reinstall the bootloader from a current live USB.

Distro notes

• Ubuntu 26.04 / 24.04: sudo ubuntu-drivers install installs prebuilt NVIDIA modules signed by Canonical for supported kernels, avoiding MOK entirely. Only DKMS-built drivers need the MOK. Details in installing NVIDIA drivers on Ubuntu.
• Debian 13: install dkms and the matching linux-headers package first; the key appears after the first build.
• Fedora 44: after enrolling, run sudo akmods --force and reboot. Wait a few minutes after installing akmod-nvidia before rebooting, so the build completes.
• Arch Linux: Secure Boot is normally set up with sbctl (create keys, enroll them in the firmware, sign the kernel and bootloader). Module signing is not enforced by default, so "Key was rejected" is rare. See the Arch Wiki Secure Boot page.
• Linux Mint: same as Ubuntu; Driver Manager prompts for the MOK password.

Last resort

Two options remove the problem at the cost of protection. Use them only on a machine you control, and prefer enrolling a MOK.

• Disable shim's validation (keeps Secure Boot on for Windows): sudo mokutil --disable-validation, confirm on the blue screen at reboot. Revert with --enable-validation.
• Disable Secure Boot in the firmware setup. If Windows uses BitLocker, have the recovery key ready first: changing Secure Boot can trigger a BitLocker recovery prompt.

Either way, the kernel leaves lockdown mode, which also re-enables hibernation and unsigned modules.

Frequently asked questions