You installed a driver and the kernel refused to load it
You compiled a custom kernel module or installed a proprietary driver, ran modprobe, and the terminal spat back an error. The desktop might still load, but your hardware is running in a fallback mode, or you are dropped to an emergency shell before the login screen appears. The error message points to secure boot and unsigned module. You didn't ask for this complexity. You just wanted your hardware to work.
The kernel is protecting you. Secure Boot is active on your firmware, and the kernel enforces a strict policy: no unsigned code enters kernel space. Fedora ships with a kernel signed by Red Hat keys, which your firmware trusts. Your custom module has no signature. The kernel sees the missing signature and blocks the load. This prevents malicious code from gaining root privileges during boot. You need to bridge the gap by signing your module with a key that the firmware recognizes.
What's actually happening
Secure Boot builds a chain of trust from the firmware down to the operating system. The firmware checks the signature of the bootloader. The bootloader checks the kernel. The kernel checks its modules. If any link in the chain fails, the boot process stops or the component is rejected.
Think of the firmware as a building manager with a master list of trusted contractors. Fedora is on that list. Your custom module is a new contractor showing up with no credentials. The manager refuses entry. You need to get your contractor stamped by a notary that the manager trusts. In UEFI terms, that notary is the Machine Owner Key, or MOK.
The MOK is a key pair you generate and enroll in the firmware's MOK database. Once enrolled, the firmware treats the MOK as a trusted authority. When you sign a module with the MOK private key, the kernel verifies the signature against the enrolled MOK public key. The signature matches, the module loads, and the chain of trust remains intact.
This process requires three steps. You generate the key pair. You enroll the public key in the firmware. You sign the module with the private key. The enrollment step happens in the UEFI interface, not in Linux. You will reboot and interact with a blue menu screen to complete the process.
Generate and enroll your MOK keys
Run mokutil --sb-state first. If Secure Boot is disabled, you don't need to sign anything. The kernel will load unsigned modules without complaint. If the output says SecureBoot enabled, proceed with the key generation.
Here's how to create the key pair and prepare the certificate for enrollment.
# Create a dedicated directory for MOK keys
sudo mkdir -p /etc/pki/mok
cd /etc/pki/mok
# Generate the private key used for signing modules
openssl genrsa -out MOK.priv 2048
# Generate the DER certificate from the private key
openssl req -new -x509 -key MOK.priv -out MOK.der -days 3650 -subj "/CN=Fedora MOK/"
The genrsa command creates the private key. Keep this file secure. Anyone with this key can sign modules that your system will trust. The req command creates the certificate in DER format. UEFI firmware expects DER certificates, not PEM. The -days flag sets the validity period. Ten years avoids frequent re-enrollment. The -subj flag sets the display name you will see in the firmware menu.
Here's how to queue the certificate for enrollment in the firmware.
# Import the certificate into the MOK database
sudo mokutil --import MOK.der
The --import command adds the certificate to the MOK list pending enrollment. You will be prompted for a password. Choose a strong password and write it down. You cannot recover this password later. You will type it in the UEFI MOK manager on the next reboot.
Reboot immediately after importing the key. The MOK manager waits for you at the firmware level. If you delay, some firmware implementations may reset the pending enrollment queue.
Enroll the key in the UEFI MOK manager
When the system reboots, you will see a blue screen titled "Enroll MOK" or "Manage Machine Owner Keys". This is the shim bootloader's MOK manager. It runs before the Linux kernel loads.
Select "Enroll MOK". Choose "Continue". You will be asked for the password you set during the mokutil --import step. Type the password carefully. The screen may not show characters as you type. Press Enter.
Select "Enroll the key". The manager will confirm the key is enrolled. Choose "Reboot" to continue booting into Fedora.
If you make a mistake or forget the password, the enrollment fails. You will boot into Fedora, but the key is not trusted. You must repeat the process. If you are locked out completely, you must disable Secure Boot in the BIOS/UEFI setup, clear the MOKs, and start over.
Sign your kernel module
Once the key is enrolled, you can sign the module. The kmodsign tool embeds the signature directly into the module file.
Here's how to sign a module file.
# Sign the module with your MOK private key
sudo kmodsign sha256 /etc/pki/mok/MOK.priv /etc/pki/mok/MOK.der /lib/modules/$(uname -r)/kernel/drivers/my_module.ko
The first argument is the hash algorithm. SHA256 is the standard for Secure Boot. The second and third arguments are the private key and certificate paths. The last argument is the full path to the module. The command modifies the module in place. The signature is appended to the file.
Back up the original module before signing. If the signature is malformed, you can restore the original file and try again.
Verify the signature and load the module
Here's how to confirm the module carries a valid signature.
# Check the module metadata for the signer field
modinfo /lib/modules/$(uname -r)/kernel/drivers/my_module.ko | grep signer
The output should show signer: Fedora MOK and a valid signature hash. If the signer field is missing, the signing step failed. Check the kmodsign output for errors.
Load the module and check the kernel log.
# Load the module and check for errors
sudo modprobe my_module
dmesg | tail -n 5
If the module loads successfully, dmesg will show no errors related to signatures. If you see loading module with no signature is not allowed, the signature is missing or invalid. If you see key was rejected by service, the MOK was not enrolled correctly.
Sign the module before loading it. The kernel checks the signature at load time. A module loaded without a signature will be rejected, even if you sign it afterward.
Common pitfalls and error messages
You will encounter specific errors if the process goes wrong. Recognizing these messages saves time.
If you see modprobe: ERROR: could not insert 'my_module': Operation not permitted, check dmesg. The kernel log will contain my_module: loading module with no signature is not allowed. This means the module is unsigned or the signature is invalid. Re-run kmodsign and verify the paths.
If you see key was rejected by service, the MOK is not enrolled in the firmware. You likely skipped the blue screen or entered the wrong password. Reboot and ensure you complete the enrollment in the MOK manager.
Kernel updates break signatures. When you run dnf upgrade, a new kernel is installed. The module directory changes. Your signed module remains in the old kernel tree. The new kernel loads the unsigned module from the new tree and rejects it. You must re-sign the module after every kernel update.
If you use akmods to build modules, the workflow is different. akmods can integrate with mokutil to sign modules automatically. If you are using akmods, check the akmods configuration for signing options. Manual kmodsign is for custom modules or local patches.
Lose the MOK password and you are stuck. There is no recovery mechanism. You must disable Secure Boot, clear the MOKs, and regenerate the keys. Store the password in a password manager.
When to use this approach
Use Secure Boot when you want firmware-level protection against rootkits and bootkits. Disable Secure Boot when you are running hardware that requires unsigned drivers and you cannot sign them reliably. Use akmods when you are installing proprietary drivers like NVIDIA or VirtualBox that support automated signing. Use manual kmodsign when you are compiling a custom module from source or maintaining a local patch set.
Trust the package manager for standard drivers. Manual signing is for edge cases. If a driver is available in the Fedora repositories or a trusted COPR, install it via dnf. The package maintainer handles signing and updates.