After one of recent upgrade (at least before or equal to snapshot 20180425), my laptop ask me if I want to enrol the MOK. If I try to enrol it, a password is required. But I don’t know any password to this. If I do not response, the system will boot after several seconds. This is a new thing to me.
Could anyone please tell me what is this? And what should I do to deal with it?
P.S. The key is from openSUSE Project. Fingerprint is,
18 8E A6 FA 76 FB FC FE 6F 67
24 47 20 AB 61 DF 7F 43 D1 4A
I have been seeing that message on several boots – I’m not sure why. Presumably some change in the nvram data structure cause MokManager to be loaded.
I just hit enter, and it continues booting. I do not select “Enrol MOK” from the menu.
As to what that “enroll” is: You can create your own key for signing kernels. If you that, then you need to enroll it before you can use it. The main purpose is to allow you to compile your own kernel and sign it yourself, yet still use secure-boot. There’s a description of all of that on the openSUSE wiki.
Assuming that you are not doing that, just hit enter when you see that prompt. It does not show up on every boot.
On Tue 01 May 2018 09:06:03 PM CDT, Knurpht wrote:
nrickert;2864291 Wrote:
> I have been seeing that message on several boots – I’m not sure why.
> Presumably some change in the nvram data structure cause MokManager to
> be loaded.
>
> I just hit enter, and it continues booting. I do not select “Enrol
> MOK” from the menu.
>
> As to what that “enroll” is: You can create your own key for signing
> kernels. If you that, then you need to enroll it before you can use
> it. The main purpose is to allow you to compile your own kernel and
> sign it yourself, yet still use secure-boot. There’s a description
> of all of that on the openSUSE wiki.
>
> Assuming that you are not doing that, just hit enter when you see that
> prompt. It does not show up on every boot.
Now that you’re mentioning this, I have had the impression it only shows
up after a Tumbleweed kernel update, but didn’t verify.
Hi
Correct, select enrol and enter the root password. It’s the updated
kernel signature for secure boot.
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
Tumbleweed - 20180429 | GNOME Shell 3.28.1 | 4.16.4-1-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
You’re welcome. I can finally tell my oldest son ( who tried entering a signing key dozens of times ) what to do. He also tried to enter half of the internet, but not his root password. In his case ( some Lenovo linux killer ) sometimes the whole boot process stops and he had to reset the laptop a couple of times, Texted him about this, and he just confirmed that the MOK screen doesn’t show up after reboots.
I found this thread when searching for info about the opensuse secure boot sign key and the information found here is very useful. But I still have one unanswered question: How can I verify that a key that is shown in Mok manager is really from opensuse?
I have secure boot enabled because I think it is added security. I also created my own key to be able to boot certain unsigned kernels, so I know I can enter anything in the signing certificate to make it look real, except for the fingerprint. But I find no information of what fingerprint to expect from opensuse, so if I just enroll the key I defeat the purpose of the added security. Then a hacker could somehow setup his own key so on next boot it would get enrolled by the user.
So, does anyone know where I can find the fingerprints of the opensuse public key for signing secure boot?
So I access a secure site on the web, and my browser (firefox) tells me that it is okay. I am implicitly trusting “firefox” and Mozilla.org for that. As indicated, trust has to start somewhere.
In the case of Mok, there is the initial key that was used to install your system. And, if you had secure-boot turned on, then you already accepted that key. You could only boot the installer, because it was certified by the Microsoft key that you implicitly trust.
Beyond that – if you imported a new key with a kernel update, then the packages from the openSUSE repos were signed with keys that you already accept (because the installer setup those acceptance rules).
As indicated above, there is no magic. Trust is hard and uncertain.
I agree that it has to do with trust, to a certain level. But in this case there should be some way to check a certificate, otherwise there is no use in certificates nor fingerprints. And I wanted to know how to verify those.
Thank you, that helped, I could confirm now that with today’s kernel update without having rebooted yet, that mokutil --list-new produces the same fingerprint.
Still I am somewhat surprised to see a new key, the previous two attempts I just skipped them and could still boot with secure boot enabled. What do these new keys sign? Especially since I discovered that a efi binary with two signatures won’t boot, you have to remove the first and then sign it for it to work.
It is not new key, kernel RPM unconditionally calls “mokutil --import” in postinstall. mokutil checks whether certificate is already present and if not submits enrollment request.
the previous two attempts I just skipped them
So key was not present and mokutil repeated enrollment request again and again.
and could still boot with secure boot enabled
Because file that is verified by firmware (actual initial bootloader) is signed with different key and this key is embedded in firmware of almost every system out there. And initial bootloader embeds kernel signing key. Key that you enrolled is not needed as long as both initial bootloader and kernel come from SUSE.
What do these new keys sign?
They sign kernel binary (vmlinuz UEFI signature) and kernel modules.
Especially since I discovered that a efi binary with two signatures won’t boot, you have to remove the first and then sign it for it to work.
This was bug in specific versions of firmware of specific vendor. To my best knowledge it should in the meantime have been fixed by vendor. There is no restrictions in UEFI specification itself which quite explicitly talks about “list of certificates”.