mokutil --sb-state SecureBoot disabled Platform is in Setup Mode - Tumbleweed

English Install/Boot/Login
1

Hello fellow openSUSErs,

I opted for SecureBoot and I verified it was working after install. I decided to check the status after I suspected it was no longer active and indeed that was the case.

mokutil --sb-state
[FONT=monospace]SecureBoot disabled
Platform is in Setup Mode
[/FONT]

I’m afraid that if I

mokutil --revoke-import

I’ll need to turn off SecureBoot to boot. Currently there is only one cert installed:

sudo mokutil --list-enrolled  
[key 1] 
SHA1 Fingerprint: 33:ce:a7:1b:a1:6a:67:ba:d8:6b:93:cb:da:2e:19:a7:e9:df:95:66 
Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
            fa:be:d8:bf:40:9a:5e:63 
        Signature Algorithm: sha256WithRSAEncryption 
        Issuer: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=buil
d@opensuse.org 
        Validity 
            Not Before: Aug  3 12:35:39 2020 GMT 
            Not After : Jun 12 12:35:39 2030 GMT 
        Subject: CN=openSUSE Secure Boot Signkey, C=DE, L=Nuremberg, O=openSUSE Project/emailAddres
s=build@opensuse.org 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
                RSA Public-Key: (2048 bit) 
                Modulus: 
                    00[FONT=monospace]...(truncated) 
                Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            X509v3 Basic Constraints: critical 
                CA:FALSE 
            X509v3 Subject Key Identifier:  
                C8:BD:C7:AC:1A:1D:85:96:62:17:FD:93:EB:FC:14:F4:A2:00:B8:14 
            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/emailAddres
s=build@opensuse.org 
                serial:01 

            X509v3 Key Usage: critical 
                Digital Signature 
            X509v3 Extended Key Usage:  
                Code Signing 
    Signature Algorithm: sha256WithRSAEncryption 
         4b...(truncated)
[/FONT]

How can I get my SecureBoot working again? Please note, I can still currently boot and use the OS. Many thanks! :slight_smile:

2

I’m pretty sure that has to do with your BIOS (UEFI firmware) setup and not with openSUSE.

I have not tried it, but I think I will get to setup mode on my current desktop if I tell the BIOS to reset to factory state.

On a different computer (a Lenovo ThinkServer), I did reset to factory state and that just set it up with the Microsoft key. It did not go to setup mode. But I think my main desktop (a Dell system) does go to setup mode on factory reset.

I’m afraid that if I

mokutil --revoke-import

I’ll need to turn off SecureBoot to boot. Currently there is only one cert installed:

I don’t think that’s right.

If you used “mokutil --import” to enroll a certificate, and that certificate has not yet been enrolled, then “–revoke-import” cancels that request. If there is not an outstanding request, I don’t think it does anything. It won’t delete any key that is already enrolled.

How can I get my SecureBoot working again? Please note, I can still currently boot and use the OS. Many thanks! :slight_smile:

I honestly don’t know what to do to get out of setup mode. That’s why I avoided resetting to factory state on my Dell system.

3

In my opinion Secure boot is security theater. If someone or a program can modify the boot stack then you are already owned and it is too late for secure boot to do any meaningful protection. :open_mouth:

4

Thanks for your reply nrickert!

I’m pretty sure that has to do with your BIOS (UEFI firmware) setup and not with openSUSE.

I should have explained this more. I’ve noticed that when performing a zypper dup that Tumbleweed will sometimes send a new mokutil --import request to install a new cert. Why does it do this? I have no idea! I can confirm that Kubuntu never did this. It would install the SecureBoot certs (I believe there were two) at the time of install and that was it, you were good. So what I’m pretty sure happened here is that upon rebooting after a zypper dup I missed the Enroll MOK screen (which happens at the UEFI level) or maybe for some reason the Enroll MOK screen wasn’t displayed. So now I have a pending cert request. From previous experience I know these pending cert requests cause the SecureBoot state to go to Platform is in Setup Mode.

It won’t delete any key that is already enrolled.

Agreed! Just delete pending requests.

5

It is due to a decision somebody made.

I haven’t looked closely at all the details, so this might be wrong.

As far as I know, all Ubuntu kernels (including Kubuntu) are signed with the canonical key.

openSUSE is doing it differently. They have the openSUSE secure boot CA key. And, in turn, that signs a kernel-signing key. There is a separate repo for kernel builds, which uses a different key to sign the kernel.

Thus when a kernel in installed, the signing key for that kernel is imported. In the early days of UEFI (say openSUSE 12.3), if I installed a kernel from that kernel repo, then I had to disable secure-boot to boot that kernel. Or I had to find the signing key and enroll that. So now it is automated. When I install a kernel, its signing key is stored in “/etc/uefi/certs” and is enrolled. When I remove an old kernel, that removes the file in “/etc/uefi/certs”. More accurately, it decrements the use-count for that file, and removes it if the use count is zero. And if the file is removed, then that certificate is delete (unenrolled).

And yes, the new key is not enrolled until “shim” next runs and presents a blue screen to enroll.

So what I’m pretty sure happened here is that upon rebooting after a zypper dup I missed the Enroll MOK screen (which happens at the UEFI level) or maybe for some reason the Enroll MOK screen wasn’t displayed. So now I have a pending cert request.

It is easy to miss that blue screen if you are not expecting it or if you don’t know what to do with it.

As far as I know, it does not leave a pending request. The request to enroll is just lost if you ignore that screen.

From previous experience I know these pending cert requests cause the SecureBoot state to go to Platform is in Setup Mode.

Hmm, I doubt that. But I think I can test that in a virtual machine.

6

As far as I know, all Ubuntu kernels (including Kubuntu) are signed with the canonical key.
openSUSE is doing it differently. They have the openSUSE secure boot CA key. And, in turn, that signs a kernel-signing key. There is a separate repo for kernel builds, which uses a different key to sign the kernel.

Thank you nrickert, this is very good to know. I REALLY wish they wouldn’t do it that way, but good to know nonetheless.

Hmm, I doubt that. But I think I can test that in a virtual machine.

OK, so you are right. Under Acer UEFI I:
BIOS > Restore Secure Boot to Factory Default
BIOS > Erase all SecureBoot Setting
BIOS > Select an UEFI file as trusted

And now it boots and shows as SecureBoot enabled. That being said:

  1. I was expecting shimx64.efi
    when selecting the trusted file (\efi\distro\shimx64.efi) but it was just shim.efi 1. I get two errors at boot for integrity: Problem loading X.509 certificate -65

I’m hoping the X.509 cert error will go away once Tumbleweed installs a cert after a zypper dup. Strangely though, it doesn’t prevent the system from booting nor from showing SecureBoot as enabled.

7

Yes, openSUSE calls it “shim.efi” while Ubuntu uses “shimx64.efi”.

8

You get errors where​?

9

Yes, openSUSE calls it “shim.efi” while Ubuntu uses “shimx64.efi”.

Ah, I see. Glad to hear that’s expected for Tumbleweed.

At boot. See (blurry) image below:

Imgur

UPDATE: I’ve tried two image sites and both aren’t working. Anyways, the errors stay on screen because it pauses for me to enter the passphrase to unlock the disk. To give the exact messages:**
1.497151] integrity: Problem loading X.509 certificate -65
1.497172] integrity: Problem loading X.509 certificate -65**

10

What about MokManager.efi in /boot/efi/EFI/ ?

11

What about MokManager.efi in /boot/efi/EFI/ ?

Sorry Svyatko, what do you mean? What should I check? Thanks! :slight_smile:

12

In EFI boot environment you may run .efi executables before running bootloaders boot.efi, grub*.efi or shim.efi.

13

Ah, I see what you’re saying now Svyatko. Thank you! I tried both:

HDD0 > EFI > boot > MokManager.efi
HDD0 > EFI > opensuse > MokManager.efi

but these just led me to the MOK enrollment screen and I couldn’t find any new key to install.

I’m hoping that once I get a kernel update from a zypper dup that this will get sorted. So far no kernel update to test.

14

OK, so I’ve realized that when doing zypper dup,I’m getting the kernel updates, as I can see them under /boot however when I do a uname -a I’m stuck on 5.10.1.-1. I guess the cert error
**1.497151] integrity: Problem loading X.509 certificate -65
1.497172] integrity: Problem loading X.509 certificate -65
**is preventing the new kernels from booting. I think I need to redeploy my SecureBoot from scratch (without completely redeploying the OS), but I don’t know how to do that as I’ve always let the OS installer take care of it. Anyone have something they can point me to, or other ideas?

BTW, to clarify, I’m going back to my original hypothesis: the problem started when a cert didn’t get installed during MOK Management at boot after a zypper dup (for whatever reason). I don’t believe this to be a UEFI problem.

15

So I can’t get rid of the X.509 cert errors on boot but the kernel is now updating after running efibootmgr -v and deleting about a million boot entries (they persisted over all previous installations). This is good enough, as other than the cert errors at boot, Secure Boot is working fine (and the kernel is updating).

16

I’m not sure why you are seeing X.509 cert errors during boot. I am not seeing any of those.

Here’s the output that I get when I check for that:


% dmesg | grep -i x.509
    1.589368] Loading compiled-in X.509 certificates
    1.589410] Loaded X.509 cert 'openSUSE Secure Boot Signkey: c8bdc7ac1a1d85966217fd93ebfc14f4a200b814'
    1.595491] integrity: Loading X.509 certificate: UEFI:db
    1.595519] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
    1.595520] integrity: Loading X.509 certificate: UEFI:db
    1.595536] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
    1.595812] integrity: Loading X.509 certificate: UEFI:MokListRT
    1.596106] integrity: Loaded X.509 cert 'rickert: 52746c083a41398bdc35230819193ea9a4c6de50'
    1.596107] integrity: Loading X.509 certificate: UEFI:MokListRT
    1.596128] integrity: Loaded X.509 cert 'openSUSE Secure Boot Signkey: c8bdc7ac1a1d85966217fd93ebfc14f4a200b814'
    1.596129] integrity: Loading X.509 certificate: UEFI:MokListRT
    1.596149] integrity: Loaded X.509 cert 'SUSE Linux Enterprise Secure Boot Signkey: 4ab0c697c91073276c27deff3c220fb007e1de61'
    1.596150] integrity: Loading X.509 certificate: UEFI:MokListRT
    1.596346] integrity: Loaded X.509 cert 'openSUSE Secure Boot CA: 6842600de22c4c477e95be23dfea9513e5971762'

Hmm, you probably won’t see all of those keys. The Microsoft keys come from the firmware. You probably have some Microsoft key, but maybe not exactly the same ones. The “rickert” key is one that I installed myself (when I was experimenting with signing kernels). The SUSE Enterprise key is because I have a test Leap 15.3 system installed on the same machine. The “OpenSUSE Secure Boot CA” key comes from “shim.efi” and you should see that. The “openSUSE Secure Boot Signkey” is used to sign the kernel, and you should see that.

Incidentally, your secure-boot setup should have been reinstalled in an update over the last 2 weeks, due to an update of grub2.

17

You must remove old EFI boot entries also manually manage the EFI boot partition. This is not done auto-magically since there is no remove this OS options you simply replace OS’s and the install will add new entries.

18

Thanks gogalthorp! I was not aware of this!

nrickert, this is what I get when I run the same command. We see the certs that failed to load in the list, but they’re not identified so I don’t know how to delete them.

dmesg | grep -i x.509
    1.494416] Loading compiled-in X.509 certificates
    1.494444] Loaded X.509 cert 'openSUSE Secure Boot Signkey: c8bdc7ac1a1d85966217fd93ebfc14f4a200b814'
    1.500529] integrity: Loading X.509 certificate: UEFI:db
    1.500571] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
    1.500572] integrity: Loading X.509 certificate: UEFI:db
    1.500589] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
    1.500590] integrity: Loading X.509 certificate: UEFI:db
    1.500604] integrity: Loaded X.509 cert 'Acer Database: 84f00f5841571abd2cc11a8c26d5c9c8d2b6b0b5'
    1.500604] integrity: Loading X.509 certificate: UEFI:db
    1.500606] integrity: Problem loading X.509 certificate -65
    1.500631] integrity: Loading X.509 certificate: UEFI:db
    1.500632] integrity: Problem loading X.509 certificate -65
    1.502814] integrity: Loading X.509 certificate: UEFI:MokListRT
    1.502847] integrity: Loaded X.509 cert 'openSUSE Secure Boot Signkey: c8bdc7ac1a1d85966217fd93ebfc14f4a200b814'
    1.502848] integrity: Loading X.509 certificate: UEFI:MokListRT
    1.503128] integrity: Loaded X.509 cert 'openSUSE Secure Boot CA: 6842600de22c4c477e95be23dfea9513e5971762'
   13.109713] cfg80211: Loading compiled-in X.509 certificates for regulatory database
   13.109972] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7
19

Post full output of “mokutil --db”.

20

Hello arvidjaar!

Post full output of “mokutil --db”.

Whoa, soooo much stuff! It’s gotta be here! I truncated the output so that it isn’t too long, please let me know if that’s a problem.

mokutil --db 
[key 1] 
SHA1 Fingerprint: 58:0a:6f:4c:c4:e4:b6:69:b9:eb:dc:1b:2b:3e:08:7b:80:d0:67:8d 
Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
            61:07:76:56:00:00:00:00:00:08 
        Signature Algorithm: sha256WithRSAEncryption 
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010 
        Validity 
            Not Before: Oct 19 18:41:42 2011 GMT 
            Not After : Oct 19 18:51:42 2026 GMT 
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
                RSA Public-Key: (2048 bit) 
                Modulus: 
                    00:dd:0c:bb:a2:e4:2e:09:e3:e7:c5:f7:96:69:bc: 
                    Truncated ....
                    48:03 
                Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            1.3.6.1.4.1.311.21.1:  
                ... 
            X509v3 Subject Key Identifier:  
                A9:29:02:39:8E:16:C4:97:78:CD:90:F9:9E:4F:9A:E1:7C:55:AF:53 
            1.3.6.1.4.1.311.20.2:  
                . 
.S.u.b.C.A 
            X509v3 Key Usage:  
                Digital Signature, Certificate Sign, CRL Sign 
            X509v3 Basic Constraints: critical 
                CA:TRUE 
            X509v3 Authority Key Identifier:  
                keyid:D5:F6:56:CB:8F:E8:A2:5C:62:68:D1:3D:94:90:5B:D7:CE:9A:18:C4 

            X509v3 CRL Distribution Points:  

                Full Name: 
                  URI:http://crl.microsoft.com/pki/crl/products/MicRooCerAut_2010-06-23.crl 

            Authority Information Access:  
                CA Issuers - URI:http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt 

    Signature Algorithm: sha256WithRSAEncryption 
         14:fc:7c:71:51:a5:79:c2:6e:b2:ef:39:3e:bc:3c:52:0f:6e: 
         [FONT=monospace]Truncated ....
[key 2] 
SHA1 Fingerprint: 46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3 
Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
            61:08:d3:c4:00:00:00:00:00:04 
        Signature Algorithm: sha256WithRSAEncryption 
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root 
        Validity 
            Not Before: Jun 27 21:22:45 2011 GMT 
            Not After : Jun 27 21:32:45 2026 GMT 
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
                RSA Public-Key: (2048 bit) 
                Modulus: 
                    Truncated .... 
                Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            1.3.6.1.4.1.311.21.1:  
                ..... 
            1.3.6.1.4.1.311.21.2:  
                ....k..wSJ.%7.N.&{. p. 
            X509v3 Subject Key Identifier:  
                13:AD:BF:43:09:BD:82:70:9C:8C:D5:4F:31:6E:D5:22:98:8A:1B:D4 
            1.3.6.1.4.1.311.20.2:  
                . 
.S.u.b.C.A 
            X509v3 Key Usage:  
                Digital Signature, Certificate Sign, CRL Sign 
            X509v3 Basic Constraints: critical 
                CA:TRUE 
            X509v3 Authority Key Identifier:  
                keyid:45:66:52:43:E1:7E:58:11:BF:D6:4E:9E:23:55:08:3B:3A:22:6A:A8 

            X509v3 CRL Distribution Points:  

                Full Name: 
                  URI:http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl 

            Authority Information Access:  
                CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt 

    Signature Algorithm: sha256WithRSAEncryption 
         Truncated .... 

[key 3] 
SHA1 Fingerprint: 61:aa:ed:0e:d5:86:b5:fa:72:7b:c9:31:8c:15:7f:6a:a9:e8:be:00 
Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
            1e:16:be:4f:3d:d6:c1:8a:47:01:1c:ff:a1:07:0c:cf 
        Signature Algorithm: sha256WithRSAEncryption 
        Issuer: C=Taiwan, ST=TW, L=Taipei, O=Acer, CN=Acer Root CA 
        Validity 
            Not Before: Jul 10 03:35:15 2013 GMT 
            Not After : Jul 10 03:45:15 2033 GMT 
        Subject: C=Taiwan, ST=TW, L=Taipei, O=Acer, CN=Acer Database 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
                RSA Public-Key: (2048 bit) 
                Modulus: 
                    00:a0:c1:35:9d:39:ba:87:2b:c0:15:ed:aa:b5:45: 
                    Truncated .... 
                Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            X509v3 Key Usage: critical 
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment 
            X509v3 Authority Key Identifier:  
                keyid:15:73:D0:91:98:D7:D0:59:C2:0C:E6:02:DC:F7:A0:1F:75:70:38:88 

            X509v3 Subject Key Identifier:  
                84:F0:0F:58:41:57:1A:BD:2C:C1:1A:8C:26:D5:C9:C8:D2:B6:B0:B5 
    Signature Algorithm: sha256WithRSAEncryption 
         Truncated .... 

[key 4] 
SHA1 Fingerprint: 1e:01:92:56:78:f9:12:a6:13:b4:fa:42:76:8b:39:c7:fc:b0:bf:12 
Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
             (Negative)09:fb:55:60:bd:75:e5:54:b6:9d:d9:50:7d:c8:f0:5f 
        Signature Algorithm: sha1WithRSA 
        Issuer: CN=DisablePW 
        Validity 
            Not Before: Dec 31 16:00:00 2012 GMT 
            Not After : Dec 31 16:00:00 2039 GMT 
        Subject: CN=DisablePW 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
                RSA Public-Key: (2048 bit) 
                Modulus: 
                    00:bc:80:6f:bb:37:14:3c:75:6f:48:34:61:cb:08: 
                    Truncated .... 
                Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            2.5.29.1:  
                0<..P...)....d..c.X...0.1.0...U....DisablePW......B...Ib&..7.. 
    Signature Algorithm: sha1WithRSA 
         Truncated .... 

[key 5] 
SHA1 Fingerprint: 69:47:40:53:4d:ab:d6:96:20:54:bc:40:46:51:6c:df:4b:5f:a3:bc 
Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
            43:06:d6:5b:60:55:8c:88:44:df:d7:a5:8f:ea:ff:50 
        Signature Algorithm: sha1WithRSA 
        Issuer: CN=ABO 
        Validity 
            Not Before: Dec 31 16:00:00 2010 GMT 
            Not After : Dec 31 16:00:00 2039 GMT 
        Subject: CN=ABO 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
                RSA Public-Key: (2048 bit) 
                Modulus: 
                    00:e2:e8:55:c1:be:51:9e:54:40:df:a9:1f:50:14: 
                    Truncated .... 
                Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            2.5.29.1:  
                06.....%xE....,.?.....0.1.0 
..U....ABO..C..`U..D......P 
    Signature Algorithm: sha1WithRSA 
         Truncated .... 

[key 6] 
  [SHA-256] 
  f5e892dd6ec4c2defa4a495c09219b621379b64da3d1b2e34adf4b5f1102bd39
[/FONT]