Testing Leap 42.2 Alpha on my main notebook and unable to use SecureBoot whatever I try.
Had the same problem with 42.1 but gave up since I didn’t bother to sign the several VBox, VMWare, Nvidia kernel modules routinely used there.
But the 42.2 test install is “fresh and clean”, no proprietary SW (and no broken shim.efi as happened with 42.1 BTW).
So maybe I’m missing something obvious? Currently enrolled certificates are as follows; please note that everything “non OpenSUSE” is from the manufacturer default install.
Notably, I see a Canonical certificate in KEK, but no OpenSUSE counterpart; but I don’t know if it does really matter.
I can live (better, maybe) without SecureBoot, but would like to learn something more about this animal.
bruno@LT_B:~>** mokutil --test-key /usr/lib64/efi/shim-opensuse.der
/usr/lib64/efi/shim-opensuse.der is already enrolled**
bruno@LT_B:~> **mokutil --test-key /usr/lib64/efi/grub.der
/usr/lib64/efi/grub.der is already enrolled**
bruno@LT_B:~> **mokutil --pk**
[key 1]
Issuer: CN=ASUSTeK Notebook PK Certificate
bruno@LT_B:~> **mokutil --kek**
[key 1]
Issuer: CN=ASUSTeK Notebook KEK Certificate
...
[key 2]
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
...
[key 3]
Issuer: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
...
bruno@LT_B:~> **mokutil --db**
[key 1]
Issuer: CN=ASUSTeK Notebook SW Key Certificate
...
[key 2]
Issuer: CN=ASUSTeK MotherBoard SW Key Certificate
...
[key 3]
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
...
[key 4]
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
...
[key 5]
Issuer: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
...
**[key 6]
Issuer: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
**...
bruno@LT_B:~>
Secure boot is false security. Yes it protects against changes in the boot stack but any agent that can reach and change the stack owns the system anyway.
Unfortunately this is rather vague. You cannot install with secure boot enabled? You cannot boot if secure boot is enabled after installation? What exact error at which point you get?
I was able to install and boot with secure-boot enabled.
“mokutil --kek” shows only a Microsoft key.
“modutil --db” shows a microsoft key and a Lenovo key (on a Lenovo computer).
On another computer, where I have not attempted to install 42.2, “mokutil --db” shows only two Microsoft keys.
As far as I know, “shim.efi” is signed by a Microsoft key, with a second signature by opensuse. The Microsoft signature should be sufficient.
In some computers, the firmware does not support two signatures. My Lenovo was that way until a BIOS update. In that case, I could only get secure-boot to work by removing the opensuse signature from “shim.efi”, leaving only the Microsoft signature. Is it possible that you have a system with that restriction?
This page:
openSUSE:UEFI
has a section “Booting the Machine that supports only one signature with vendor provided Keys” which explains how to remove the opensuse signature from “shim.efi”.
Installed (EFI) with SecureBoot disabled, but with “Enable SecureBoot support” enabled.
Then enabled SecureBoot: at reboot no “EFI boot” option works (Grub2 doesn’t even show up) with error “Invalid signature found. Check setup” or similar.
Thanks, will try that and report back.
Indeed I was missing something obvious… to nrickert! lol!
Stripping the OpenSUSE signature from “shim.efi” did the trick for both Leap 42.1 (proprietary drivers and VBox modules notwhistanding) and Leap 42.2 Alpha.
Just for the records, we might take note that the following BIOS (and possibly other ASUS BIOSes) supports only single signatures despite being fairly recent.
LT_B:~ # dmidecode
...
BIOS Information
Vendor: American Megatrends Inc.
Version: N551JW.209
Release Date: 03/04/2016
...
BIOS Revision: 4.6
...
LT_B:~ #
I’m glad that worked. And it is surprising that a BIOS this recent has such a problem.
I think I have heard something like it. This needs bug report to document this; may be we should ship it by default.