How to Enable Secure Boot Ubuntu 22.04

Secure Boot isn’t one single “on/off” checkbox you flip and forget. On Ubuntu 22.04, it’s a chain: your firmware setting, the signed boot files Ubuntu provides, and, if you use third-party or out-of-tree drivers, whether those extra kernel modules are signed in a way Secure Boot will trust. If any link is missing, you can hit a boot loop or find that required modules won’t load.

Below is a step-by-step walkthrough for Ubuntu 22.04 that keeps the workflow clear: enable Secure Boot in UEFI, enroll a MOK key (Machine Owner Key), then make sure your boot components and any extra kernel modules are signed appropriately.

What Secure Boot does on Ubuntu 22.04

Secure Boot exists to stop untrusted code from running during system startup. Your UEFI firmware checks signatures before it lets parts of the boot process continue.

On Ubuntu 22.04, the important idea is this:

• Your firmware enforces signature checks.
• Ubuntu’s signed boot components (like shim, GRUB, and the kernel) are intended to pass those checks.
• If you install third-party drivers that compile kernel modules outside Ubuntu’s normal signing process, those out-of-tree kernel modules may also need signing.
• When you sign modules yourself, you typically enroll a MOK key (a key you control) so the system can trust what you signed.

So the “right” setup isn’t just “turn Secure Boot on.” It’s “turn Secure Boot on, then make sure anything Secure Boot might block is trusted.”

Check whether Secure Boot is already enabled

Before you change anything, check the current status. On many systems, Secure Boot may already be enabled even if you never set it up yourself.

1. Boot into Ubuntu 22.04.
2. Open a terminal.
3. Run:

```bash

mokutil --sb-state

```

You’re looking for a clear enabled/disabled state.

If your output shows Secure Boot is already on, you can skip the UEFI “enable validation” step and focus on the MOK enrollment and module signing parts.

Enter the UEFI firmware settings

Now you need to change settings in UEFI. The exact key and menu names vary by hardware. Some systems show “UEFI Setup,” “BIOS Setup,” or similar text during startup.

A safe approach:

1. In Ubuntu, reboot into firmware setup:

• In most cases you can do this from the power/restart menu if it offers “Firmware Settings.”
• If not, you may need to use your motherboard’s startup key (often something like `F2`, `F10`, `F12`, `Del`, or `Esc`—but don’t guess blindly. Check what your system shows at boot).

1. Once inside the UEFI menus, look for sections related to:

• Secure Boot
• Boot Security
• Authentication / Validation

Write down what you change so you can back out if something goes wrong.

Enable Secure Boot validation

You’re trying to turn on Secure Boot validation, not just any “secure” toggle.

In the UEFI firmware UI, you typically set one or both of the following (names vary):

• Set Secure Boot to Enabled
• Set Secure Boot Mode / Validation to something like Standard or the default “validated” mode

Version-specific warning for the Ubuntu 22.04 workflow: don’t start signing random things in Ubuntu until you’ve clearly enabled Secure Boot in UEFI. Otherwise you won’t know what caused the failure.

Also, be careful with Custom Mode vs Standard Mode (or similarly named options). A custom mode can change how keys are treated. Since the MOK step later is what usually handles custom trust, you want the firmware set up so it will actually enforce signature checks.

After enabling Secure Boot validation, save and reboot back into Ubuntu.

Enroll the MOK key in UEFI firmware

A MOK key (Machine Owner Key) is how you add trust for keys you control. If you sign out-of-tree kernel modules with your own key, you enroll that key so the system can verify the signatures while Secure Boot is enforced.

The flow is usually:

1. Create or identify a MOK key in Ubuntu.
2. Request enrollment.
3. Reboot.
4. Finish the enrollment in the UEFI “MOK” screen.

On Ubuntu, you’ll typically do this using `mokutil`.

General flow you’ll follow (commands vary depending on what you’re starting with and which method you used to generate a key):

• Use `mokutil` to register enrollment
• When you reboot, your firmware will show a MOK enrollment menu (often with options like enrolling a key, confirming, and entering a password you set)
• Confirm enrollment

Important details:

• You have to complete MOK enrollment in the UEFI prompt after you reboot. If you don’t, the key won’t be trusted.
• Keep track of the password or passphrase you set for enrollment. Losing it can block enrollment.

After MOK enrollment completes, reboot again into Ubuntu. At that point, the system can accept signatures created with the enrolled key.

Check Ubuntu's signed boot components

With Secure Boot enabled, Ubuntu depends on signed boot components to start normally.

In a working Secure Boot chain on Ubuntu, the key pieces include:

• shim (a small bootloader that helps bridge trust)
• GRUB
• the kernel

For Ubuntu Server setups, it helps to remember this filesystem detail (common in Secure Boot documentation):

• The EFI System Partition is mounted at `/boot/efi` in the Ubuntu Server setup described in common Secure Boot documentation.

Why this matters: Secure Boot validation is about what gets loaded from the EFI boot path. If you use custom boot entries, alternate bootloaders, or unusual storage layouts, you can break the chain even if the firmware is correct.

Practical tip: if the machine boots normally with Secure Boot enabled and reaches the desktop or login screen, the signed shim/GRUB/kernel chain is already doing its job. At that point, your attention should shift to third-party drivers and out-of-tree modules.

Handle third-party and out-of-tree kernel modules

This is where most Ubuntu 22.04 Secure Boot setups fail.

When you install drivers that build kernel modules outside Ubuntu’s normal signed packages—often called out-of-tree modules—Secure Boot may block them unless they’re signed with a key the system trusts (your MOK key).

The chain looks like this:

1. UEFI enforces Secure Boot.
2. Ubuntu’s signed boot components load the kernel.
3. The kernel tries to load your third-party module.
4. Secure Boot trust rules apply to module signatures too, so unsigned modules won’t load.
5. You sign your modules with your enrolled MOK key so they load.

What “sign the module” means in practice:

• You generate signatures for the built `.ko` module files using your key.
• You ensure those signatures match the key you enrolled via MOK.
• After that, the kernel can verify the signature and load the module.

Where to focus:

• Any module built from source for hardware support (common with specialized NICs, storage controllers, VPN tools, capture cards, and other vendor drivers).
• Any DKMS-built module that compiles during install.

If you’re not sure which modules are affected, check what fails to load:

• Look at `dmesg` output around the time you start the module or reboot.
• Many module load errors include “signature” or “unsigned.”

Keep this boundary in mind:

• Firmware setup = Secure Boot on/validation settings + MOK enrollment prompt in UEFI
• Ubuntu setup = signing modules after you build them (using the enrolled MOK key)

Trying to do both at once makes debugging harder.

Troubleshoot installation and boot issues

If you enable Secure Boot and your system doesn’t boot, or third-party hardware stops working, use this order to troubleshoot. Don’t start by reinstalling.

1) First confirm Secure Boot state after changes

• Reboot back into Ubuntu if you can.
• Re-check Secure Boot status with `mokutil --sb-state`.
• Make sure it’s really enabled when you think it is.

2) If you can’t boot at all

This usually means the boot chain isn’t trusted.

Things to check:

• You enabled Secure Boot validation correctly in UEFI (not just a partial setting).
• You didn’t swap the bootloader path to something unsigned.
• Your firmware is pointing to the expected Ubuntu EFI boot entry.

Because Ubuntu’s shim/GRUB/kernel chain is designed for Secure Boot, “can’t boot” often points to a boot-path mismatch rather than a kernel module problem.

3) If Ubuntu boots, but third-party drivers don’t work

This usually comes down to module signing or MOK enrollment.

Common causes:

• You enabled Secure Boot validation but didn’t complete MOK enrollment in the UEFI prompt after requesting enrollment.
• You signed modules with the wrong key (or signed before enrolling).
• You installed out-of-tree modules without repeating the signing step after rebuilds.

Tip: DKMS modules can rebuild after kernel updates. After every kernel update, assume you may need to re-sign modules with the enrolled MOK key.

4) If module errors mention signatures

When the kernel refuses to load modules, focus on:

• Whether the MOK key is actually present
• Whether the module signatures exist and match the key
• Whether you signed the module you’re trying to load (it’s easy to sign an older build)

5) Make sure you’re separating steps

A lot of pain comes from mixing steps out of order. For Ubuntu 22.04, follow this order:

1. UEFI Secure Boot validation enabled
2. MOK key enrollment completed in UEFI
3. Confirm Ubuntu reaches the login screen
4. Build third-party modules
5. Sign out-of-tree modules with the enrolled MOK key
6. Reboot and verify module load

If you stick to that order, failures are much easier to pinpoint.

A quick sanity check workflow (complete chain)

If you want a simple checklist that matches the full Secure Boot chain (instead of treating it as one toggle), use this:

• In Ubuntu: confirm current Secure Boot state (`mokutil --sb-state`)
• In UEFI:
• enable Secure Boot validation
• reboot and complete MOK enrollment when prompted
• Back in Ubuntu:
• boot to the desktop/login screen (shim/GRUB/kernel chain works)
• install/build third-party drivers
• sign any out-of-tree `.ko` modules with the enrolled MOK key
• reboot again and confirm the modules load

Before you restart, verify the right step happened

Do yourself a favor and verify Secure Boot status first. Then confirm you completed the correct MOK or driver-signing step before restarting again. If you enable Secure Boot and only do part of the chain, you’ll usually find out the hard way—either the system won’t boot, or your out-of-tree driver won’t load.