Mokutil --list-enrolled explanation

Bluefin
1

Hello there,
I received a notification to enroll UB key this morning
Screenshot from 2024-09-26 09-15-58

followed the link saying
image

what I get is different…

❯ mokutil --list-enrolled
7e68651d52 Fedora Secure Boot CA
63fe4d8157 ublue akmods\ 
2be991e3b1 ublue kernel

Is it concerning that the fedora key is different and what about that extra ublue akmods\ one ?
Thank you

2

You haven’t enrolled the new key, that is the reason they are different.

2 Likes
3

This landed in :latest last night but is not in the weekly builds yet, but yeah, you need to enroll the new keys, we’re working on the announcement still.

4

Hi, first a clarifying question:

Did you receive this warning and re-enroll (ujust enroll-secure-boot-key) before checking the output of mokutil --list-enrolled?

I want to know if the script is mis-detecting, because it should only run if 2be991e3b1 ublue kernel is missing.

Second:

2be991e3b1 ublue kernel is our new secure boot signing key which we use to sign kernels as well as kmods.

63fe4d8157 ublue akmods is older and was only used for signing kmods. This is partially addressed in this announcement Autumn update: Secure Boot users, make sure you've enrolled our secure boot key , but it’s not very clear. Also, we just added a note about the old key here: Introduction to Bluefin

We’re currently signing kernels with the new key and akmods with both keys. Eventually, we’ll drop the old key and provide instructions or automation to remove it from the list of enrolled MOKs.

Third:

I haven’t had a chance to dig deep on the different Fedora CA entries. But I don’t believe that is actually stored in the UEFI MOK list, rather it’s provided by the Fedora shim. Fedora did do their own key rotation not too long ago, so I suspect that you still have the older shim and grub in your boot partition.

You can read more about that if you wish: Manual action needed to resolve boot failure for Fedora Atomic Desktops and Fedora IoT - Fedora Magazine

1 Like
5

hey @bsherman
thanks for asking for clarification, much appreciated.

Yes that’s exatly what I did:

  1. turn laptop on and was greeted by that notification
  2. ran ujust enroll-secure-boot-key
  3. checked mokutil --list-enrolled and got that result

Before doing all of this I had only:

7e68651d52 Fedora Secure Boot CA
63fe4d8157 ublue akmods\

It’s weird for that 7e68651d52 Fedora Secure Boot CA line, I never messed with Fedora shim (I would have had to load a shim file in the BIOS to have that right? I’m not a specialist as you can see)

Also while we’re at it @bsherman I have 2 questions for you:

  • I’m planning on reinstalling Bluefin one of those days. Does all the keys (those 3 ones) are deleted and I re-enroll the correct ones?
  • I created a topic few weeks back regarding an error enrolling secure boot key on another computer Error enrolling secure boot key
    Do you have any idea of what could cause this problem (HP pavillion desktop with Windows previously) ?
    Maybe it’s not related but that same computer has trouble shutting down properly Error shutting down computer

thanks a lot @bsherman

[I’m trying to learn a lot to not ask too many stupid questions I can find somewhere else but I wish there was a tag noob-question :sweat_smile:]

6

hey @j0rge , yes I use latest so I guess that’s why I got this notification today right.
I thought I had already enrolled the new key when you published Autumn update: Secure Boot users, make sure you've enrolled our secure boot key … I guess not

7

Yes that’s exatly what I did:

  1. turn laptop on and was greeted by that notification
  2. ran ujust enroll-secure-boot-key
  3. checked mokutil --list-enrolled and got that result

Great! Thank you for confirming! I wanted to make sure this wasn’t a bug report about the notification showing incorrectly.

This sounds like the behavior we expect, and the notification did its job! It was created to let users know this needs to be done, even though the old ublue akmods MOK may already have been enrolled.

It’s weird for that 7e68651d52 Fedora Secure Boot CA line, I never messed with Fedora shim (I would have had to load a shim file in the BIOS to have that right? I’m not a specialist as you can see)

You wouldn’t have messed with this, it’s would have been installed when you installed the system and not updated. It’s almost never a manual user operation.

  • I’m planning on reinstalling Bluefin one of those days. Does all the keys (those 3 ones) are deleted and I re-enroll the correct ones?

A MOK (Machine Owner Key) is actually enrolled into a database which is part of the UEFI on your motherboard. This is why it needs a reboot and that ugly UI with a password to enroll.

But, this also means you won’t need to do it again even after reinstall.

I created a topic few weeks back regarding an error enrolling secure boot key on another computer Error enrolling secure boot key

I’ll respond on those threads to keep this focused.

2 Likes
8

Ok, I really appreciate you taking the time to respond to all my questions!
Take care Ben :+1:

9

@bsherman Does the old key have an upcoming expiration date such that it will be universally recognized as invalid? The only reason I’ve seen for switching keys is “security”, so it seems kind of weird that the swap process doesn’t include removing the old key.

10

Good question.

Different dates have been thrown around, but unless I missed it or forgot (which happens), we haven’t picked a hard date for the cutover.

In part, this particular rotation of the ublue MOK is a practice run, giving us a chance to walk through it while we are NOT in a crisis.

So for this there’s a couple ideas in play:

  1. dual-signing assets (kernels and kmods) with both keys for some time gives slow adopters adequate notification and time to enroll the new key before. If it was insta-swapped, users would update and not have the required key, which could prevent booting on non-stock Fedora kernels (eg, fsync). The original post on this thread is an example of a) the notification accomplishing this goal and b) the need for uBlue team to better document and communicate some of the details (eg, that both keys would be left on the system).
  2. though less important, leaving both keys in the MOK list allows the user to rollback their system to a point where kernel/kmods were only signed with the old key, also preventing booting issues, etc.

The finally step in the key-swap process will be to stop signing with the old key, and at the same time, we’ll provide some instructions, and probably a ujust recipe, to remove the old one. Users are free to remove the old key now, if they choose, if they understand the situation and want to do it themselves.

3 Likes
11

That all sounds great. Thanks for taking the time to explain it to me even though you’ve probably had to repeat it many times already.

1 Like
12

thanks to both of you @MaxJanky and @bsherman for helping to make it more understandable, it really helps :slightly_smiling_face:

Just to make sure of the steps if we wanted to delete it manually, that would be it right? :
image

Thanks guys :pray:

1 Like
13

Just had the notice in the terminal :


   󱍢 Welcome to Bluefin                                                         
                                                                                
  󱋩  bluefin-dx-nvidia:stable                                                   
                                                                                
   Command                            │Description                             
  ─────────────────────────────────────┼────────────────────────────────────────
   ujust --choose                      │Show available commands                 
   ujust toggle-user-motd              │Toggle this banner on/off               
   ujust bluefin-cli                   │Enable terminal bling                   
   brew help                           │Manage command line packages            
                                                                                
  󰋼 Need a container?  ujust distrobox-assemble  can help you assemble a new    
  container image.                                                              
                                                                                
  • 󰊤 Issues https://issues.projectbluefin.io                                   
  • 󰈙 Documentation http://docs.projectbluefin.io/                              
  • 󰊌 Discuss https://community.projectbluefin.io/                              
  • 󰊌 Leave Feedback https://feedback.projectbluefin.io                         
                                                                                
  WARNING: This machine has secure boot turned on, but you haven't enrolled     
  Universal Blue's keys. Failing to enroll these before rebooting may cause your
  system to fail to boot. Follow this link                                      
  https://docs.projectbluefin.io/introduction#secure-boot                       
  https://docs.projectbluefin.io/introduction#secure-boot                       
  for instructions on how to enroll the keys.                                   

malix@malix-pc ~>

now, on Bluefin stable, 40.20240930

However, I tried many times but it fails with “password doesn’t match” on the MOK screen

I set “universalblue” on both the terminal and the MOK util

I tested it 4 times, but the 1st time, I set the wrong password (my user password instead of “universalblue”)

This is what I get after using ujust enroll-secure-boot-key once (so now it doesn’t prompt for a password anymore)

malix@malix-pc ~> ujust enroll-secure-boot-key
echo 'Enter password "universalblue" if prompted after your user password.'
Enter password "universalblue" if prompted after your user password.
sudo mokutil --timeout -1
sudo mokutil --import /etc/pki/akmods/certs/akmods-ublue.der
SKIP: /etc/pki/akmods/certs/akmods-ublue.der is already in the enrollment request
echo 'When you reboot your computer, follow the instructions to start MOK util'
When you reboot your computer, follow the instructions to start MOK util
echo 'by pressing a key, then enroll the secure boot key and enter "universalblue" as the password'
by pressing a key, then enroll the secure boot key and enter "universalblue" as the password
malix@malix-pc ~> mokutil --list-enrolled
2bb010e24d fedoraca
63fe4d8157 ublue akmods\ 
malix@malix-pc ~ > sudo mokutil --timeout -1
malix@malix-pc ~> mokutil --list-new
malix@malix-pc ~ > sudo mokutil --timeout -1
malix@malix-pc ~ >

Notice that mokutil --list-new outputs nothing, butujust enroll-secure-boot-key outputs “SKIP: /etc/pki/akmods/certs/akmods-ublue.der is already in the enrollment request”

14

I just tested again with “universalblue” and it still doesn’t work

“ERROR”

“Password doesn’t match”

“OK”

I definitely typed “universalblue” correctly

Is it a bug in bluefin stable ?

15

Are you on AZERTY, by chance? This came up in a similar thread recently and evidently the MoKUtil stuff only understands QWERTY.

2 Likes
16

i have the sasme behaviour on Bluefin Stable
First i do the ujust command and set a password. (what is that for? or is it my login pw?)
and the on restart i try to enroll the key but the password doesnt match. UniversalBlue and also my login pw…

17

@twojays @Malix,
check those 2 links, it should be all you need:

1 Like
18

That solved my issue, thanks !

Added enhance: `ujust enroll-secure-boot-key` by Malix-Labs · Pull Request #328 · ublue-os/config · GitHub and enhance: introduction secure boot by Malix-Labs · Pull Request #28 · ublue-os/bluefin-docs · GitHub to document it

4 Likes
19

Sweet, good job. Cheers!

I wonder if it would be better to just change the recommended “universalblue” password to something idempotent, like “expedition”, “chocoholic”, or maybe just “ublue”.

2 Likes
20

Yes, it would save a lot of useless back and forth :slightly_smiling_face:

1 Like