Don’t Let Kernel Module Signing Bite You During Upgrades

Technical Briefing | 9/6/2026

You’ve just upgraded your kernel, rebooted, and suddenly your custom network drivers or obscure hardware interfaces aren’t working. No errors on boot, just… silence where there should be activity. This is a classic sign your out-of-tree kernel modules aren’t playing nice with the new kernel image. Most of the time, it’s a simple recompilation, but not always.

The Secure Boot Shadow

Modern Linux distributions are pushing for secure boot, and a big part of that is kernel module signing. If your kernel is configured to only load signed modules, and your custom module isn’t signed, or worse, signed with a key not trusted by the running kernel, it simply won’t load. This isn’t new, but it’s something many sysadmins only encounter when a kernel update happens during a busy period.

The kernel logs (`dmesg`) are your first stop, but they might just say ‘module tainted’ or give a vague error if the signature verification fails. Most tutorials focus on building modules, not on the signing aspect that Secure Boot enforces. You’ll need to generate a keypair and tell the kernel build system to use it.

Signing Your Module

Here’s the basic workflow. You’ll generate a private key and a public certificate, then use those to sign your module after it’s compiled. You then need to enroll that public key into the kernel’s trusted store. The `mokutil` tool is your friend here, often used in conjunction with DKMS (Dynamic Kernel Module Support).

openssl req -new -x509 -newkey rsa:2048 -keyout signing_key.priv -out signing_key.x509 -nodes -days 3650 -subj '/CN=My Company Name/'
modprobe configs
cp signing_key.x509 /usr/src/module-name/
cp signing_key.priv /usr/src/module-name/
/usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./signing_key.priv ./signing_key.x509 $(modprobe -n vmlinuz)/path/to/your_module.ko

The `mokutil` Dance

After signing, you’ll often need to import that public key into the machine’s Machine Owner Key (MOK) list. This usually involves a reboot and a blue screen-like utility where you confirm you want to enroll the new key. If you’re using DKMS, it often handles this post-install, but you might have to manually trigger it or re-run the enrollment process after a kernel update if things go sideways.

• Ensure your build environment has openssl and kernel build tools.
• Generate a private key and public certificate.
• Integrate signing into your module build process (e.g., DKMS hooks).
• Use `mokutil –import` and follow the reboot prompts to enroll the key.
• Rebuild and re-sign modules after every kernel upgrade.

This whole process can be a bit fiddly, and the exact steps vary slightly between distributions. But when you’re staring at a server that won’t talk to its network card because of a signing mismatch, knowing the mechanics behind it saves you a ton of time.