After recent zypper dup resulting in kernel-default-5.7.11-1.1 to kernel-default-5.7.11-1.2 update, I saw a blue screen after reboot proposing me to enter uefi shim management or something. It automatically disappeared after some time and didn’t show again on next reboot. I thought this might have happened because of changed keys, but it doesn’t seem to be the case:
$ mokutil --list-new
MokNew is empty
Why did this happen and have I missed something not entering that screen?
I have no idea either, in my case IIRC the very first time i tried a Suse version i was asked if i wanted to trust some certificate with Suse mentioned in it, never got that prompt again, and i can’t find the cert either that was trusted…
Maybe i just need to reset my SecureBoot keys to the factory ones again to check dunno.
Anyway the most logical reason would be if grub-efi was updated that is loaded by the shim, maybe check that because anything after grub should be permitted by the signature used to sign the grub-efi also…
Also check the output of: sudo mokutil --list-enrolled
In my case at moment it shows:
> sudo mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 46:59:83:8c:82:03:fe:15:52:ad:19:e1:86:09:db:21:7e:3a:d2:4f
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
Validity
Not Before: Aug 26 16:12:07 2013 GMT
Not After : Jul 22 16:12:07 2035 GMT
Subject: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:de:df:61:92:7a:a4:fe:83:d1:7d:3b:68:0e:b1:
a7:f0:4e:92:93:fc:47:3e:70:2d:4e:88:dc:9a:9e:
fa:33:b4:a6:db:0e:23:c1:0d:a8:c1:d5:65:04:84:
04:ff:3a:48:18:4f:39:32:e4:ca:4e:f9:04:9e:9f:
0f:cd:20:5d:61:ab:a7:00:d8:a5:ff:2b:7f:be:e8:
47:c3:2f:5b:02:c8:bb:de:8e:1a:e9:46:d3:86:ef:
ff:88:99:90:eb:10:89:b8:8b:3f:3e:a8:07:c6:55:
7a:6e:d3:5f:fc:83:3c:3d:16:ed:26:c5:13:73:92:
b1:70:1e:22:95:c8:00:6c:25:76:46:f1:a2:d9:d0:
b0:98:68:0f:a7:2d:b1:0d:67:89:ca:94:4a:ea:12:
c5:91:55:76:7f:6c:7a:2e:f9:18:89:9f:f8:f4:24:
43:d5:35:6a:cb:00:0e:2e:ed:4b:e2:5d:09:d8:1b:
97:70:99:9e:5a:6f:a6:81:a8:9d:a9:58:76:7d:69:
71:82:d3:ba:3a:96:43:9b:f0:da:15:c6:4e:e9:c8:
15:b9:e9:cb:c7:e4:71:ce:ea:10:1b:6b:c4:2a:70:
01:a9:52:b4:17:de:00:52:cf:7d:e4:fd:0f:4d:03:
18:b2:90:28:d4:6f:c4:ae:56:bc:36:60:49:46:8b:
6b:0b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
68:42:60:0D:E2:2C:4C:47:7E:95:BE:23:DF:EA:95:13:E5:97:17:62
X509v3 Authority Key Identifier:
keyid:68:42:60:0D:E2:2C:4C:47:7E:95:BE:23:DF:EA:95:13:E5:97:17:62
DirName:/CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
serial:01
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
8a:a3:89:c2:8e:d9:f9:82:0b:f3:33:ce:e9:19:17:17:a3:65:
80:cd:33:ae:06:51:56:29:b6:38:87:7b:f4:9d:fc:28:8e:aa:
e0:53:12:0e:3a:60:c7:06:d8:3a:61:76:3b:77:08:f4:94:a4:
8c:7c:47:3a:99:d8:84:9b:17:cc:20:62:2e:e2:76:e4:c6:36:
0d:26:e9:2e:53:35:0a:fb:3a:35:93:45:c3:93:82:c1:0b:f3:
08:e9:57:1f:59:37:a9:d0:6c:69:fb:68:ea:7f:3b:af:d3:f7:
59:27:8e:d4:c7:96:73:f4:0c:0a:f7:3e:e4:af:6c:8c:c7:7a:
6f:09:79:f4:41:1f:e3:6f:11:fb:3e:6c:b1:a0:7b:e4:92:b7:
ca:f9:32:f5:de:c3:b0:73:7d:e3:b3:82:5d:cd:ec:61:dc:fe:
0c:3e:c6:b5:e7:6c:2d:5d:92:73:ff:ed:aa:6a:a9:9b:66:9e:
5e:3a:6d:70:b0:31:c0:ce:df:2f:21:10:68:0c:87:f3:77:a0:
33:31:0a:0f:15:f6:ee:32:88:c5:9a:53:71:cd:0d:1a:a1:28:
89:d0:bf:f6:56:ac:4b:3b:36:06:2b:01:c5:eb:e5:dc:72:83:
3d:94:ac:28:83:13:fb:c1:5d:27:9c:13:f6:32:5f:f6:1f:4a:
b7:3e:53:8a
grub2-x86_64-efi was updated indeed. I have another cert. Its validity period is:
Not Before: Jan 8 16:25:54 2020 GMT
Not After : Nov 16 16:25:54 2029 GMT
And that would probably be it. There was a new uefi cert released - 33CEA71B.crt. The question now is, how to make that blue screen reappear (is it mokutil --import /etc/uefi/certs/33CEA71B.crt?) and is it fine not to do it?
I got that prompt after updating this morning. I told it to install the new key.
If your system booted fine, then I guess it doesn’t much matter.
Yes, the “mokutil” command that you suggested does look like the right one. You can add “–root-pw” as an additional option (put that just after the “–import”) if you want it to use the root password instead of “mokutil” asking you to give a password.
Enrollment (and all other key management requests) are for the next reboot only. They are cleared immediately when MokManager is started. Kernel RPM will submit new enrollment request on every update as long as it is missing.
Thanks for your help, people! One last question: may I or maybe should I delete the older key when enrolling the new one? I’m trying to bring my computer to the state that zypper dup would, had I entered shim management when first asked to.
openSUSE shim embeds openSUSE CA certificate used to sign other certificates used to sign kernels. So as long as new certificate is issued by the same openSUSE CA (it is) shim will allow kernel signed by it. New certificate is also embedded into kernel itself and used to verify kernel modules so it does not matter whether it is enrolled.
The only case when this certificate is needed is when you use non-openSUSE shim to boot openSUSE kernel with secure boot enabled.
Normally this happens automatically - kernel RPM issues delete request when last kernel using certificate is removed. You still have to manually acknowledge request on reboot.
I think the correct state should be that the enrolled keys are exactly those in “/etc/uefi/certs” plus any that you have manually add (such as a signing key that you created for yourself).
Got it, thanks!
Personally I thought that only most recent one is enrolled, but it looks like the ones actually used are enrolled.
There’s a key built into shim that shows up as enrolled, but really isn’t (though I suppose that depends on what you mean by “enrolled”).
If you boot Ubuntu live media, thus using the Ubuntu shim, that key won’t show up as enrolled, but the Canonical key from Ubuntu will show up in its place (that’s built into the Ubuntu shim).
By enrolled I mean those listed with mokutil --list-enrolled command.
Yes, that lists the one built into shim – I think that’s last on the list.
If you boot using live Ubuntu media, and run the same command there, you will see the keys that are stored in NVRAM together with the key built into the Ubuntu shim. But you won’t see the key built into the openSUSE shim. Or, at least, that’s what my tests show.
To keep terms correct, all references to “keys” that are used to verify binaries eg. enrolled ones are actually (Public) Certificates and not keys, because KEYS are used to sign/encrypt stuff only while certs are used to verify/decrypt stuff…
I know i might sound a little weird when pointing that out, but it keeps things clean on the internet…
Some people use the terms “Private key” and “Public Key” while they should actually be using “Key” and “Certificate” in those usages…
Most prominent evidence of this are “CRL’s” which stands for “Certificate Revocation List” instead of “PKRL’s, which would stand for Public Key Revocation List” 
Forum restricted me from last edit…
Most prominent evidence of this are “CRL’s” which stands for “Certificate Revocation List” instead of “PKRL’s”, which could stand for ‘Public Key Revocation List’ or ‘Private Key Revocation List’ the last not making any sense 