After applying the Kernel patch released today, at the reboot a blue MOK screen appeared – after continuing the boot the system came up but, the following investigation related to “what is MOK” revealed the following:
# mokutil --list-new
MokNew is empty
# mokutil --list-enrolled
MokListRT is empty
# mokutil --list-delete
MokDel is empty
# mokutil --sb-state
**SecureBoot disabled**
# openssl x509 -noout -fingerprint -inform der -in /etc/uefi/certs/
33CEA71B.crt 4659838C-shim.crt
# openssl x509 -noout -fingerprint -inform der -in /etc/uefi/certs/33CEA71B.crt
SHA1 Fingerprint=33:CE:A7:1B:A1:6A:67:BA:D8:6B:93:CB:DA:2E:19:A7:E9:DF:95:66
# openssl x509 -noout -fingerprint -inform der -in /etc/uefi/certs/4659838C-shim.crt
SHA1 Fingerprint=46:59:83:8C:82:03:FE:15:52:AD:19:E1:86:09:DB:21:7E:3A:D2:4F
#
“mokutil --pk”, “mokutil --kek”, “mokutil --db” and “mokutil --dbx” are all indicated keys in the various databases – included some the motherboard’s manufacturer …
The SHA1 Fingerprints of the Kernel’s certificates located in “/etc/uefi/certs/” are not listed in the MOK databases …
As long as you have secure-boot disabled, it does not much matter.
Your output is a bit puzzling. In my experience, “mokutil --list-enrolled” should show the key that is built into shim.
Maybe you are not using shim. But then you should not be seeing the Mok screen.
Maybe you are booting with the Ubuntu shim. When I last tried that, it did not list the key built into its shim.
In any case, it is fairly normal for a kernel install to install a key in “/etc/uefi/certs”. And a script that runs with the kernel install will then attempt to enroll that key, unless it is already enrolled. If you want to enroll on that blue screen, it does ask for a password. And that should be the root password.
My 15.2 update did not bring up a Mok screen, because that key was already enrolled.
Fresh Leap 15.2 installation – I upgraded the hardware parallel to the Leap 15.2 upgrade – upgraded the old system to Leap 15.2, installed Leap 15.2 on the new hardware, moved the user disks over to the new hardware …
Shim had a bug - it ignored builtin certificate if no other certificates were enrolled, but Leap 15.2 shim should contain fix for it. It really sounds like older (e.g. Leap 15.0) or non-Leap shim is used.
Except when booting with secure boot disabled. I do not really see why - for all I can tell shim should create MokListRT independently of SB state - but I can easily reproduce it by resetting MokList and disabling Secure Boot.
I found a MOK DER here: ‘/usr/share/efi/x86_64/’ – “shim-opensuse.der” …
Copied the DER file over to ‘/boot/efi/’.
Ran “mokutil --import /boot/efi/shim-opensuse.der” – gave it the “root” user’s password – which was wrong – should have used “–root-pw” on the “mokutil” command …
Rebooted and got into the UEFI/BIOS setup – took note of the setting for EFI operating system type – was “other” – changed to “Windows 10” because of the Reference Guide text:
There are two ways of getting there. One is to work with hardware vendors to have them endorse a SUSE key, which SUSE then signs the boot loader with. The other way is to go through Microsoft’s Windows Logo Certification program to have the boot loader certified and have Microsoft recognize the SUSE signing key (that is, have it signed with their KEK). By now, SUSE got the loader signed by UEFI Signing Service (that is Microsoft in this case).
The UEFI/BIOS shim setting wasn’t changed – it was always pointing to the “secure-boot openSUSE” shim …
On saving and exiting from the UEFI/BIOS setup a blue screen came up asking if the openSUSE shim could be trusted – answered “yes” …
A password wasn’t needed …
The machine is now running with the following information regarding UEFI Secure Boot:
The Mainboard is an ASUS PRIME B450-Plus with an AMD Ryzen 5 3400G CPU …
“mokutil --pk” reveals that, an ASUSTeK MotherBoard PK Certificate is present on the Mainboard …
“mokutil -kek” reveals that, an ASUSTeK MotherBoard KEK Certificate and, a Microsoft KEK as follows and, a Canonical KEK as follows, are present on the Mainboard …
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
Validity
Not Before: Jun 24 20:41:29 2011 GMT
Not After : Jun 24 20:51:29 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
Issuer: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
Validity
Not Before: Apr 12 11:12:51 2012 GMT
Not After : Apr 11 11:12:51 2042 GMT
Subject: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
Finally got around to applying the said Kernel patch yesterday afternoon to my Lenovo G505s Laptop – not so new …
Yes, “blue screen at boot with a timeout” – you need to be quick to catch it …
“Arrow down” to the correct choice – “Enroll MOK” – “Arrow down” to make the correct choice – enter the password of the user “root” – wait for the reboot …
The systemd journal entries for UEFI Secure Boot were OK before applying the Kernel patch (secureboot: Secure boot enabled) and “mokutil” found one (1) enrolled openSUSE certificate.
After applying the Kernel patch, everything was still OK except that, “mokutil” now displayed two (2) enrolled openSUSE certificates – possibly, one of them can be deleted …
[HR][/HR]How on earth is a “newbie” going to handle this situation?
Do we need to press for an urgent update to the openSUSE documentation?
