Potential problem with machine owner key after Ubuntu install?

[Seance]

Hey everyone,

 

I recently installed a dualbooted Ubuntu on my Windows 10 laptop.

Because it has an Nvidia GPU I decided to include proprietary drivers during setup.

For this I needed to choose a secure boot password. After I did that I was unsure at one setup step and clicked "Back".

It threw me back to the secure boot password creation screen, except now when I tried to create the password I got an error message. I decided to quit the setup and start over.

When I began the second attempt it booted to a blue "MOK management" screen. There I enrolled the key using the password from the first setup attempt.

Then it booted into the normal setup. This time I did everything the same as first time, except I did not press back anywhere and the install went smoothly. I also had to do the key enrolling a second time...

 

Now my question is: Could it be problematic that I enrolled two keys? And if yes, can I undo that somehow?

 

(Otherwise everything seems to be working fine - even the proprietary drivers)

[Herr.Hoefkens]

this is quite odd , but not a really big problem, but its highly dependant on your bios how things are done. however , you should enter they systemsetup (usally hitting del or an F -key(F10/F2...) right after powering on the pc. next step is  to remove the secureboot password from the bios. it is odd the ubuntu setup asked to set one as it works perfectly without.

 

the following is an alternative procedure to use instead of the mok tool.

i use my own KEK (key exchange key) and Signing key to sign my linux kernels, however the procedure is mostly the same as ubunut also has a secureboot cert . easiest way is , to manually ad that cert to your allowed keys. (trough the bios , add one to db keys not dbx keys browse to the usb installer drive and look for the secure bootr certs, you can also use the ones that i included , (you can verify their md5's if you think i altered them in some way) once you add the keys to your db everything should work out of the box. if you dont need secure boot you may disable it and everything will work just as fine aswell. lastly if you do want to try with mok again , you need to put the system in setup mode, this can be doen by deleting all keys from the db, without any keys present ,the system will be in setup mode for the next boot, this should give the moktool access to evertything it needs, you can always the restore factory keys to reset it back to how it was (the keys from microsoft and the oem will be restored as only keys in that case)

altlinux.cer canonical-uefi-ca.cer canonical-uefi-ca.crt centossecureboot201.cer centossecureboot201.crt centossecurebootca2.cer centossecurebootca2.crt debian.cer fedora-ca.cer fedora-ca.crt microsoft-kekca-public.cer microsoft-pca-public.cer microsoft-uefica-public.cer microsoft-uefica-public.crt openSUSE-UEFI-CA-Certificate.cer openSUSE-UEFI-CA-Certificate.crt openSUSE-UEFI-CA-Certificate-4096.cer openSUSE-UEFI-CA-Certificate-4096.crt README.txt redhatsecureboot003.cer redhatsecureboot003.crt redhatsecureboot401.cer redhatsecureboot401.crt redhatsecurebootca2.cer redhatsecurebootca2.crt redhatsecurebootca4.cer redhatsecurebootca4.crt refind.cer refind.crt SLES-UEFI-CA-Certificate.cer SLES-UEFI-CA-Certificate.crt

[Seance]

Hello, thank you for the in-depth answer!

 

I'm afraid I might have explained it a litte weird... The "secure boot password" I was referring to is the password that you can create on the setup screen in the screenshot (plucked from a youtube video ).

 

In my understanding this password is designed to only be used once (That is when the MOK manager asks you to enter is on next boot).

 

It would be ideal for me if I could just somehow remove the first key I created during the failed setup attemt and be done with it...

 

Supposedly it can be done with the "mokutils" command but I don't know exactly how...

 

In other words: Could you explain in more detail how to do this with the mok tool?

 

 

[Herr.Hoefkens]

i think the installer is a  bit misleading here, in ceveral ways, as it seems, the configure secure boot + install 3rd party drivers , will result in ubunu disabling secureboot outright. if you dont mind that happening, it easier to just disable it in bios and have much less hassle, if you set a password, and you fail to enter it on reboot, ubunu should load , but minus the 3rd party drivers (if gfx ,no x wil start due to no drivers ) i think your best bet is to disable secure boot in bios and reinstall , or to add the ubunu key (cannonical ones) to the bios and leave secure boot turned on. note that in this case , you should initially disable *3rd party drivers. and install them by hand later  on....

however it has been a while since i installed a ubuntu system, well i did do KDE Neon, a while back.

 

ihave dabled with mok and shims and hashtool in the past , but if i had known that creating and signing with your own keys was as simple as it turned out to be i would have saved myself allot of headaches.

(might take a look sometime its not for ubuntu but the process is identical as far as creation and signing goes : https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot

[Seance]

Update:

I believe I've managed to solve the issue with the following process:

 

-I used "mokutil --list-enrolled" to see the enrolled keys

-There I saw three keys - Number one was the Canonical master key. Two and three were labeled "ubuntu Decure Boot Module Signature key". I figured those were the ones I created during the two setup attempts. (Their "Not Before" timestanps also matched with my two attempts).

-To delete the one from my first attempt (Key 2, the one with the earlier timestamp), I exported the enrolled keys as .der files with "mokutil --export" and requested to delete Key 2 with "sudo mokutil --delete MOK-0002.der". This prompted me to set a one-time password that I entered on the MOK manager screen that appeared on next boot.

-After this the deleted key did not show up in "mokutil --list-enrolled"

-By running glxgears on the Nvidia GPU after a reboot and checking utilization I verified that the Nvidia driver still worked.

 

Should this have fixed my issue or am I overlooking something?