Secure Boot issues on Acer system

Hello! I’ve been on and off about trying to enable Secure Boot (with Nvidia) but to no avail. I’d like to try again this time, and thought that it might be a good idea to remove the enrolled keys from previous attempts.
Running mokutil –list-enrolled gave me four keys: (1) named fedoraca, (2) named localhost.localdomain Secure Boot Module Signature Key, (3) fedora- and (4) _<random_numbers>. I had attempted secure boot also during a previous install, so I am guessing that’s what the generic fedora named ones are. With this in mind, I have a few questions then before I proceed:

  1. Do I actually need to delete these previously enrolled keys to try again?
  2. Is it safe to be deleting all of these anyways?
  3. Since I’m dual booting right now with Windows, do one of these belong to Windows? I think if one of them is, they probably shouldn’t be deleted.
  4. I actually tried deleting them before posting, but they keep asking for passwords. My sudo or bios password didn’t work for it. Whatever the passwords are, it is unlikely that I will recover them. Will I be able to delete them without it?

I am currently running on Fedora 42 KDE, and as previously stated, am also using Nvidia drivers.
Any help on this would be appreciated, thanks!

Not necessarily, but to avoid clutter, you probably should.

At the moment yes. You only need the certificate that was used to sign the nvidia modules.

Microsoft Windows uses the certificates in the db store and doesn’t use any of the certificates you installed with mokutil.

You are asked to set a self chosen password for the delete request, and when rebooting you are asked to provide that same password to actually delete the certificate. You can use a very simple password as it is never used again.

1 Like

Thank you! I managed to delete most of the keys now. However, the fedoraca one persisted. I tried –reset and –delete, but it can’t seem to delete the key. Running –reset simply gives a generic error message of not being able to delete the keys. –delete on it on the other hand says it can’t retrieve the mok list and then the same error message. Is there any way to resolve this, or perhaps it’ll be safe to start the secure boot process now despite not starting on a clean state?

That one is baked into the shim and is the one used to sign grub2 and the kernels. So in the initial situation, you have the fedoraca key as the first key and it will always be there.

Ah I see. With that then, I went ahead and attempted to allow secure boot again. Unfortunately, once again, it has ended in failure. For reference, I’ve used this guide, as the dedicated How To Secure Boot or Nvidia pages in RPM Fusion does not seem to take each other into account, though it does not stray too far from either of them much either.
Would you happen to know if there’s anything I should do differently to finally succeed here?
I also do notice there’s some left over boot entries showing up in my BIOS boot list. I hope they are not interfering with this either.

I understand that you have installed the nvidia drivers from rpmfusion. From your list of the enrolled keys it probably would be key 2, “localhost.localdomain”

With those drivers it is impossible to use secure boot until you have followed the steps from the file /usr/share/doc/akmods/README.secureboot. These instructions are repeated on the rpmfusion site.

Secureboot refuses to load the nvidia drivers until the bios has had the appropriate key uploaded and saved within the bios.

You can see if the key has been uploaded and is active with the command
sudo mokutil -t /etc/pki/akmods/certs/public_key.der
to see if the key is enrolled. It should return a result something like this. (that command is also shown in the README I listed above)

$ sudo mokutil -t /etc/pki/akmods/certs/public_key.der
/etc/pki/akmods/certs/public_key.der is already enrolled

However, if you may have reinstalled or changed the hostname then following the steps I noted above to enroll the current key might still be required. I always change the hostname to my final choice before generating the key since I never use the default “localhost.localdomain” for my systems

You can see the many options available for use with the mokutil command with mokutil -h and get more detailed info with man mokutil

This guide seems a bit over-complicated. For example, installing the akmods package will install all the other needed packages as dependencies.

But to find out what is going on we need to know the current status. If you have removed all mok certificates except key number 1, you will need to enroll the current akmods key again, that is sudo mokutil --import /etc/pki/akmods/certs/public_key.der you can check if the generated nvidia modules have been signed using the command modinfo -F signer nvidia and to check if the key is already enrolled sudo mokutil -t /etc/pki/akmods/certs/public_key.der.

If the module is created but not signed, run sudo akmods --rebuild and then check if the module is now signed.

I’ve since removed most of the other keys and enrolled the new ones. Running that command has returned me my new enrolled key.

Yes, I have enrolled the new key using that command, which was also specified in that guide.
Running modinfo -F signer nvidia has returned me the new key as well, so that should mean it is signed.

The nvidia module is signed, the key is enrolled.
Are you able to use secure boot now? or are there other issues as well?

Unfortunately, when I enable Secure Boot, it shows me the Secure Boot Fail screen. Pressing Enter on this screen will then proceed to the next Boot Manager, which is Windows, and that one will successfully to get to its lock screen.

Does the live system boot with secure boot enabled?

The reason for the question is that on some systems the microsoft certificate for third party operation systems are disable be default and must be enabled in the UEFI configuration settings.

If it was a problem with the Nvidia driver I would expect the system to go beyond the Secure Boot Fail stage.

1 Like

You said you removed some of the keys and possibly removed the required keys for secure boot to function at all.

Please once again show the output of mokutil --list-enrolled in full detail so we may see what you have enrolled. It should show something like this, and I believe keys 1, 3, & 4 are all required while key 2 is the local one for signing the nvidia driver.

[key 1]
Owner: 605dab50-e046-4300-abb6-3dd810dd8b23
SHA1 Fingerprint: 2b:b0:10:e2:4d:94:c6:32:24:58:89:ba:aa:9e:d0:f3:d5:ef:1f:68
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            22:39:af:04:13:0c:44:44:b3:f3:77:ed:be:1a:f7:86
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
        Validity
            Not Before: Jul 13 17:31:16 2020 GMT
            Not After : Jan 19 03:14:07 2037 GMT
        Subject: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)


...

[key 2]
Owner: 605dab50-e046-4300-abb6-3dd810dd8b23
SHA1 Fingerprint: 7c:88:71:9a:96:d6:c6:84:7e:a7:5e:a1:65:bb:1b:76:8f:52:1b:4f
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1c:d4:10:80:c5:f8:ba:1e:cc:54:be:b6:8f:48:32:77:58:49:79:91
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=eagle.home.domain, OU=eagle.home.domain/emailAddress=akmods@eagle.home.domain, L=None, ST=None, C=US, CN=eagle.home.domain-3731337192
        Validity
            Not Before: Jun 18 13:46:42 2023 GMT
            Not After : Jun 15 13:46:42 2033 GMT
        Subject: O=eagle.home.domain, OU=eagle.home.domain/emailAddress=akmods@eagle.home.domain, L=None, ST=None, C=US, CN=eagle.home.domain-3731337192
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)

...

[key 3]
Owner: 605dab50-e046-4300-abb6-3dd810dd8b23
SHA1 Fingerprint: 54:f4:18:74:f4:d8:84:28:09:bc:be:88:10:65:92:0a:17:56:5d:25
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b2:94:8e:b3:ca:bc:48:27:a0:a5:67:a2:b9:59:d4:63
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=grub
        Validity
            Not Before: Feb 24 22:38:00 2019 GMT
            Not After : Feb 21 22:38:00 2029 GMT
        Subject: CN=grub
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)

...

[key 4]
Owner: 605dab50-e046-4300-abb6-3dd810dd8b23
SHA1 Fingerprint: b7:57:9a:ff:e3:9e:32:3c:e2:ea:de:f0:2f:4e:b7:72:dc:9e:49:ab
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            62:e1:18:06:82:79:7a:da:d5:16:c0:f2:2d:d1:ff:3f:70:cf:a5:b0
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=fedora, OU=fedora/emailAddress=akmods@fedora, L=None, ST=None, C=US, CN=fedora-44340853
        Validity
            Not Before: Jul 29 00:01:12 2024 GMT
            Not After : Jul 27 00:01:12 2034 GMT
        Subject: O=fedora, OU=fedora/emailAddress=akmods@fedora, L=None, ST=None, C=US, CN=fedora-44340853
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)

According to your last post I need to ask about windows. Are you using bitlocker in windows? It might have an impact on what is happening.

Fedora shows the Secure Boot failed screen when booting into Fedora. But it boots into the Windows Lock Screen just fine afterwards. I have not attempted to log in after, as I was focused on getting Secure Boot working on Fedora. I will try to look for such an option now in my BIOS settings.

Running this command again, it simple shows 2 entries. Numbers before the name, the first having the name fedoraca and the other my host name followed by more numbers and letters, the latter being the key returned when running modinfo -F signer nvidia.

Almost forgot to answer too, my Windows was freshly reset/re-installed just 3 months ago back in July, and I have barely touched it since, so I would say I do not have bitlocker or any of the sort on it.

I forgot to report immediately, but I don’t think I saw anything named that seems to relate to a Microsoft specific certificate in my BIOS.

I have done some more digging. After rechecking my UEFI Settings again, I found an option called “Select an UEFI file as trusted for executing". I figured this could be related, so I attempted to add what efibootmgr reported as Fedora’s boot file (/fedora/shim.efi). Unfortunately, this did not solve it either from what I can tell. I wonder if I need to add Grub’s efi as well? Or maybe even setup Grub differently?
Windows seems to detect Secure Boot is enabled when I do boot into it, so there should definitely be no problem there. There are some efi file leftovers too around the Windows boot partition (like refind’s), but I am unsure if these are truly affecting this.
Another thing to note, is that while looking around, it seems like the hardware manufacturer might matter? In that case, mine is then an Acer Nitro 5 AN515-58 (Laptop).

Thanks again for all your help. After this though, if this still cannot be resolved, I think It’ll be the last attempt on this endeavor then.

Keep on in this direction. Perhaps the file should be specified as \EFI\FEDORA\SHIMX64.EFI or something similar.

It would have been helpful if you had stated that you were using an ACER system to begin with, as this computer is a bit special. If there are any ACER users around, they could tell you more.

I apologize for not telling about my hardware sooner. I have not thought it would have been relevant until I saw in a Linux Mint forum thread they’re a bit special.

I have tried enrolling shimx64.efi but again to no avail. However, I am actual unsure now if they’re properly being enrolled. The confirmation dialogue doesn’t actually have a proper Yes or No prompt, just an empty bar with the phrase “Boot Description” to its left. There does not seem to be any menu option for me to view enrolled efi’s on its database either, so I cannot truly discern if I’ve actually enrolled these. I could send an image of what this menu looks like if it will help.

You don’t enroll anything at the moment.

The shimx64.efi is signed by the “Microsoft Corporation UEFI CA 2011” certificate and you can get the list of builtin Microsoft certificates by running mokutil --list-enrolled --db |grep Microsoft

which would result in (on Fedora 42)

46def63b5c Microsoft Corporation UEFI CA 2011
580a6f4cc4 Microsoft Windows Production PCA 2011
b5eeb4a670 Microsoft UEFI CA 2023
3fb39e2b8b Microsoft Option ROM UEFI CA 2023

On Fedora 43 run this instead: mokutil --list-enrolled --verbose-listing --db |grep Microsoft |grep Subject:.

Again. You need to set the appropriate option in the UEFI settings which is specific to ACER hardware.