On 03.08.2021 16:12, Freek de Kruijf wrote:
Op dinsdag 3 augustus 2021 12:33:31 CEST schreef Freek de Kruijf:
Op dinsdag 3 augustus 2021 11:16:27 CEST schreef Andrei Borzenkov:
On Tue, Aug 3, 2021 at 12:02 PM Freek de Kruijf <freek@opensuse.org> wrote: ...
Install or force reinstall openSUSE-signkey-cert, reboot, perform certificate enrollment in MokManager screen. The password MokManager expects is operating system root user password.
Or if package is already installed just manually create enrollment request using
mokutil --import /etc/uefi/certs/BDD31A9E-kmp.crt
it will ask for password to use in MokManager. Reboot, confirm certificate enrollment in MokManager screen.
https://en.opensuse.org/openSUSE:UEFI#Enroll_MOK_certificate_with_moku ti l_.2 8x86.2A_only.29
I tried this procedure, but did not succeed.
Which of the two procedures listed above?
I should have said tried suggestions in this article.
Maybe my situation is different. It is: Secure multi-boot laptop with openSUSE 15.2, 15.3, Tumbleweed and Windows Booting 15.3 gives error, caused by wrong certificate. I used Tumbleweed for the above procedure.
At which point? BIOS cannot load shim, shim cannot load grub, grub cannot load kernel, some errors after kernel is loaded and started (although I am not sure what would display these errors during boot)?
When I boot 15.3 I from grub I get window with error ../../grub.......... bad shim signature .....
You are using openSUSE shim to boot Leap 15.3 kernel which is signed by SUSE key. So you obviously need to enroll SUSE key, because openSUSE shim only embeds openSUSE key. Unfortunately this appears extremely difficult to display actual certificate used to sign PE executable (there are a lot of tools to *sign* it, but no tool to extract signature). bor@leap15:~> openssl x509 -noout -fingerprint -subject -ext subjectKeyIdentifier -inform DER -in /etc/uefi/certs/4AAA0B54.crt SHA1 Fingerprint=4A:AA:0B:54:67:76:1E:CF:C0:0A:42:32:B1:7A:B4:8B:3E:09:A3:BF subject=CN = SUSE Linux Enterprise Secure Boot Signkey, C = DE, L = Nuremberg, O = SUSE Linux Products GmbH, OU = Build Team, emailAddress = build@suse.de X509v3 Subject Key Identifier: 5A:24:04:49:D2:9F:D0:D8:A7:A1:87:E6:FC:0E:26:B9:5D:1A:A8:7B bor@leap15:~>
I used in Tumbleweed: mokutil --import /suse153/etc/uefi/certs/BDD31A9E-kmp.crt mokutil --import /etc/uefi/certs/BDD31A9E-kmp.crt both give: Already in kernel trusted keyring.
Yes, this certificate is embedded in Tumbleweed kernel. Use "mokutil --ignore-keyring ..." to force adding it. ...
I further tried to solve the situation and used the 15.3 NET iso to upgrade 15.3 and was able to boot 15.3. Previously, after that, I could not boot 15.2 and Tumbleweed. In 15.3 I performed the suggested mokutil --import and now I did NOT get the message about already present.
mokutil in Leap 15.3 is tool old and does not check kernel keyring at all.
After that I did a reboot and now I got the MokManager, which asked for the password and to Enroll Mok, which I did.
Now I can boot all three openSUSE systems. mokutil --list-enrolled shows two keys.
Is not being able to enroll the certificate in Tumbleweed a bug? Bug report?
See above. It is not a bug. Unfortunately there is no easy way to display various certificates and where they come from; dmesg output provides information about kernel keyring like [ 0.582498] Loading compiled-in X.509 certificates [ 0.583162] Loaded X.509 cert 'Build time autogenerated kernel key: 6af17e88d143a5e927cc9982b97b8e933a9d694e' ... [ 0.587238] integrity: Loading X.509 certificate: UEFI:db ... [ 0.587415] integrity: Loading X.509 certificate: UEFI:MokListRT But they are displayed using subject keyid, so now you need to search all available certificates to match it (because certificates files are named using fingerprint).
The whole situation, in the first place, was caused by ignoring the Mok screen. I know it appeared several times and ignoring did not seem to harm anything. I don't recall having seen a warning that such screen could appear and not acting on it might cause problems.
I am not sure what happens during installation (it is very long time ago I did new installation). But it looks like installation should import certificates even though they are built into shim. If someone can check and verify it and finds that certificates are not imported *that* would certainly be valid bug report.