Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: UEFI shim management for unknown reason

Hybrid View

  1. #1
    Join Date
    Aug 2019
    Posts
    16

    Question UEFI shim management for unknown reason

    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:

    Code:
    $ mokutil --list-new             
    MokNew is empty
    Why did this happen and have I missed something not entering that screen?

  2. #2

    Default Re: UEFI shim management for unknown reason

    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:
    Code:
    > 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

  3. #3
    Join Date
    Aug 2019
    Posts
    16

    Default Re: UEFI shim management for unknown reason

    grub2-x86_64-efi was updated indeed. I have another cert. Its validity period is:

    Code:
                Not Before: Jan  8 16:25:54 2020 GMT
                Not After : Nov 16 16:25:54 2029 GMT

  4. #4
    Join Date
    Aug 2019
    Posts
    16

    Default Re: UEFI shim management for unknown reason

    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?

  5. #5
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    14,396
    Blog Entries
    3

    Default Re: UEFI shim management for unknown reason

    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.
    openSUSE Leap 15.2; KDE Plasma 5.18.5;

  6. #6
    Join Date
    Sep 2012
    Posts
    5,903

    Default Re: UEFI shim management for unknown reason

    Quote Originally Posted by nrickert View Post
    If your system booted fine, then I guess it doesn't much matter.
    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.

  7. #7
    Join Date
    Sep 2012
    Posts
    5,903

    Default Re: UEFI shim management for unknown reason

    Quote Originally Posted by P_O_ View Post
    I thought this might have happened because of changed keys, but it doesn't seem to be the case:

    Code:
    $ mokutil --list-new             
    MokNew is empty
    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.

  8. #8
    Join Date
    Aug 2019
    Posts
    16

    Default Re: UEFI shim management for unknown reason

    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.

  9. #9
    Join Date
    Sep 2012
    Posts
    5,903

    Default Re: UEFI shim management for unknown reason

    Quote Originally Posted by P_O_ View Post
    should I delete the older key when enrolling the new one?
    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.

  10. #10
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    14,396
    Blog Entries
    3

    Default Re: UEFI shim management for unknown reason

    Quote Originally Posted by P_O_ View Post
    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.
    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).
    openSUSE Leap 15.2; KDE Plasma 5.18.5;

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •