Secure boot key / MOK management

General
1

At startup I got a warning about secure boot being turned on, but not having enrolled Universal Blue’s keys. I went to the mentioned page: Introduction to Bluefin. And did

ujust enroll-secure-boot-key

This happened automatically then:

sudo mokutil --timeout -1
sudo mokutil --import public_key.der

I tested with mokutil --list-enrolled and it seems OK.
Now at startup, I get a blue screen with MOK management. I can choose between booting, enroll key, get the key from the web or getting it locally. Or something like that. Because I started Ecosia-ing what to do next, and that took to long, it went to sleep, the second time I think the “enroll key” option changed.
Anyway, what should I choose? The manual stops there and goes to Move on to system administration, which is about different things…

1 Like
2

From the docs:
After the first installation, you will be prompted to enroll the secure boot key in the BIOS.

Enter the password universalblue when prompted to enroll our key.

So in the mok enrollment, enroll the key from disk and use the password when it asks it

3

Thank you inffy, I didn’t understand that I had to make that choice (from reading the documents).
But now I’m lost again:

IMG_20240929_161157
IMG_20240929_1611571920×1440 115 KB

I can only click “enter” I guess, after which I get this screen:
IMG_20240929_161217
IMG_20240929_1612171920×1440 72.7 KB

I don’t know, I guess I can only click “enter” again. Next screen:
IMG_20240929_161225
IMG_20240929_1612251920×1440 66.4 KB

Those have these options:
IMG_20240929_161131
IMG_20240929_1611311920×1440 88.9 KB

IMG_20240929_161144
IMG_20240929_1611441920×2560 188 KB

So one of this items is a key?

1 Like
4

This is what is should be?

mokutil --list-enrolled
[key 1]
SHA1 Fingerprint:  xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
             xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
        Validity
            Not Before: Jul 13 17:31:16 2020 GMT
            Not After : Jan 19 03:14:07 2037 GMT
        Subject: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                     xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Authority Information Access: 
                CA Issuers - URI:https://fedoraproject.org/wiki/Features/SecureBoot
            X509v3 Authority Key Identifier: 
                 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:...
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:...
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:...
5

No, I don’t believe that’s the correct key. I am not in a position to check it out right now, but when I eyeball that I’m thinking it is the Redhat shim. That should’ve been installed without any input from you because they are signed by MS. The MoK is for keys from individuals or small organizations that have to appeal to your personal trust and entreat your acceptance. Again, I can’t look this up first-hand at the moment… but I believe the key you’re adding to your MoK is going to say universalblue instead of Redhat.

When the blue box pops up, the enroll option should already have the location of the key (that’s what the enroll command was for). Whatever you’ve gotten into in your BIOS is browsing the ESP: none of those things are keys.

6

Thanks again.
As you can see, it looks like with the first command (ujust enroll…), the next ones are performed automatically? I tried to repeat those (sudo mokutil …), but that doesn’t seem to work for the second command.
Should I just wait for an update, maybe there’s a bug?

❯ 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
Plaats uw vinger op de lezer
sudo mokutil --import /etc/pki/akmods/certs/akmods-ublue.der
input password: 
input password again: 
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

~ took 22s 
❯ sudo mokutil --timeout -1

~ 
❯ sudo mokutil --import public_key.der
Failed to get file status, public_key.der
7

The first part looks correct, mate. It is not clear why you are attempting to import the key immediately after the ujust script enrolled it or why you’d use different syntax. I think need only to reboot after running the script.

No offense, but I think you probably just clicked the wrong option in the blue screen on reboot. It’s easy to do because the prompts are rather terse. Someone else asked for some screenshots of the enroll process in a different thread and I linked a video walking through the process:

MOK enrollment instructions my mum can understand - #2 by MaxJanky

I recommend you give that a look and emulate it when you reboot after importing any new MoK.

8

I’m sorry MaxJanky, but I did exactly what the documentation said:

  • ujust enroll-secure-boot-key
  • Then those followed automatically:
    • sudo mokutil --timeout -1
    • sudo mokutil --import public_key.der
  • Because the manual said you had to type it, and it didn’t work, I followed the manual by the letter, so I typed it myself.

In the video you linked, they say to choose “Enroll MOK”, not “Enroll key from disk” like inffy suggested

So in the mok enrollment, enroll the key from disk and use the password when it asks it

I’ll try this and report back :wink:

9

Alas, no cigar.

Schermafdruk van 2024-09-30 22-03-45
Schermafdruk van 2024-09-30 22-03-451326×614 197 KB

To start, since it says “if prompted after your user password”, I’m not sure what I should put there. I choose “universalblue”.

afbeelding
afbeelding995×442 37.7 KB

Then, when asked for a password, I tried universalblue 3 times and my user password 3 times, but I always get
afbeelding
afbeelding699×749 70.3 KB

Can it be a querty/azerty problem?

10

The docs you linked say that you can run the mokutil commands yourself INSTEAD of the ujust script should you be in a scenario where you’re rebasing and want to enroll the key before you even have access to ujust.

That’s an excellent guess that would’ve never crossed my mind. Nice job. Seems like you’re in the home stretch, now!

11

You’re right :slight_smile: .

And it was an azerty/querty problem!

Only question left: when asked to type and retype a password when you run the script, you already have to use the universalblue password? (because the documentation says “if prompted after your user password”?
I never was asked my user password, not in the first screen and not in the blue screen.

12

I think it meant for sudo. Depending on your settings and how recently you last used sudo, you might be asked for a user password every execution or never. You can verify that you’ve installed the key the distro is asking for if you’re still apprehensive: mokutil --list-enrolled and look for ublue kernel.

13

Everything is OK, I think. Thanks again.

mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
        Validity
            Not Before: Jul 13 17:31:16 2020 GMT
            Not After : Jan 19 03:14:07 2037 GMT
        Subject: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
  		    xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
                    xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Authority Information Access: 
                CA Issuers - URI:https://fedoraproject.org/wiki/Features/SecureBoot
            X509v3 Authority Key Identifier: 
                xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
        xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
        ...

[key 2]
SHA1 Fingerprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Universal Blue, OU=kernel signing, CN=ublue kernel/emailAddress=security@universal-blue.org
        Validity
            Not Before: Jul 11 03:07:09 2024 GMT
            Not After : Jun 17 03:07:09 2124 GMT
        Subject: O=Universal Blue, OU=kernel signing, CN=ublue kernel/emailAddress=security@universal-blue.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
        xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
        xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
        ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature
            X509v3 Subject Key Identifier: 
                xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
        xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
        ...
2 Likes
14

Ok i got it now. The process worked!

For a simplest recap of the problem:
the enrollment programm (the bios looking one), doesnt understand any other keyboard layout than azerty. Which is what most of the world doesnt use by default…
So when you should put in a Password on the ujust command, you have to choose one without the switched up letters…for example a and q
in my case because i use qwertz in germany i also have to look out for y and z switching it up.

Now i have the fedora key, the ublue akmods and ublue kernel
now everything should work out fine?

15

Yep. You can probably get rid of the old akmods key, even, but I couldn’t tell you what the advantage of doing so would be.

1 Like
16

I don’t know where you got that from but that cannot be correct.

Well it could depend on device/manufacturer, but I would say that it will not use azerty but a US qwerty layout.

Just like the LUKS password prompt on these Atomic distros, it will not follow you system keymap (unless you make the imageramfs track your vconsole.conf), a known bug currently (been for a while).

1 Like