Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: UEFI shim management for unknown reason

  1. #11
    Join Date
    Aug 2019
    Posts
    16

    Default Re: UEFI shim management for unknown reason

    Quote Originally Posted by arvidjaar View Post
    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.
    Got it, thanks!

    Quote Originally Posted by nrickert View Post
    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).
    Personally I thought that only most recent one is enrolled, but it looks like the ones actually used are enrolled.

  2. #12
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    14,275
    Blog Entries
    3

    Default Re: UEFI shim management for unknown reason

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

  3. #13
    Join Date
    Aug 2019
    Posts
    16

    Default Re: UEFI shim management for unknown reason

    Quote Originally Posted by nrickert View Post
    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").
    By enrolled I mean those listed with mokutil --list-enrolled command.

  4. #14
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    14,275
    Blog Entries
    3

    Default Re: UEFI shim management for unknown reason

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

  5. #15

    Default Re: UEFI shim management for unknown reason

    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"

  6. #16

    Default Re: UEFI shim management for unknown reason

    Forum restricted me from last edit...
    Quote Originally Posted by TriMoon View Post
    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"
    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

Page 2 of 2 FirstFirst 12

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
  •