# New Secureboot Key

## Rolling Forward

As of X date, universal blue has been signing all kernels and kmods with two MOKs. Our previous MOK was named akmods and our current MOK is called ublue kernel. On X date we will no longer be signing our kernels and kmods with the old akmods key.

## What actions do I need to do?

Please run `ujust enroll-secureboot-key`. This will enroll the new current key. On your next reboot, MOK manager will start up. Enroll the key by selecting enroll and inputting the password. Note the keyboard maybe set to en_US and we have the password normally set to universalblue.

## Why do I have to do this?

If you are using secureboot, secureboot uses a set of public and private keys in order to ensure that only items cryptographically signed are allowed to be used for the kernel and loaded into the kernel. Without enrolling ublue's keys out of tree modules won't load and non fedora kernels won't load. Bazzite explicitly needs the key to even boot. Many of our images will not boot without enrolling our key. Since we do not compile our own grub and shim, we instead our reliant on using an extension to secureboot called Machine Owner Key. This key can only be enrolled with a user at the device prior to the Linux kernel loading meaning we cannot automate this for you. Fedora does something similar and affected users back in June/July. Fedora has a signed shim that has the distribution certificates loaded into them.

## Why are we changing keys?

As part of a commitment to best practices, we decided that we should start periodically change our signing keys. The Akmods key has been in use for over 1 year. As part of rolling forward we investigated how to sign the kernel with multiple keys and kmods with multiple keys. In fact, we been doing that for the past few months in preparation for this roll forward. We plan on turning off dual signing with the akmods key on X date to complete this roll forward process.