Invalid Signature Secure Boot - Latest Kernel Update

Latest update would not boot until I disabled secure boot.
Kernel Ver: 5.14.0-362.24.1.el9_3.0.1.x86_64

These forums is for community support. Your post does not provide a question, nor logs, nor screenshots, or otherwise to assist you. If you feel this is a bug, please report it to our bug tracker with all applicable information such as packages (kernel, shim, grub) and hardware.

https://bugs.rockylinux.org

The Rocky specific updates for Apr 2024, included a new shim and grub, which COULD affect secure boot. Can you post output of:
rpm -q shim-x64
Can you also clarify the exact error message, e.g. did the error happen before the grub screen showing the list of available kernels to boot from?

It was a statement.
Error occurs before the grub menu is presented thus no opportunity for a second choice.

$ rpm -q shim-x64
shim-x64-15.8-2.el9.x86_64
$ sudo dnf history info 108 | grep shim
    Upgrade       shim-x64-15.8-2.el9.x86_64                               @baseos
    Upgraded      shim-x64-15.6-1.el9.rocky.0.2.x86_64                     @@System

I wasn’t prepared to take a screen shot as I needed to get the server up.

$ mokutil -l
[key 1]
SHA1 Fingerprint: 0e:2a:bf:72:66:32:95:3a:d2:05:b3:cd:c7:eb:24:15:8b:31:b3:bb
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            10:6c:57:1c:ee:af:29:24:c0:aa:85:e5:aa:b4:85:42:9a:b1:d8:86
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Delaware, L=Dover, O=Rocky Enterprise Software Foundation, OU=Release engineering team, CN=Rocky Linux Secure Boot Root CA/emailAddress=security@rockylinux.org
        Validity
            Not Before: Jun 20 15:05:01 2021 GMT
            Not After : Jun 18 15:05:01 2031 GMT
        Subject: C=US, ST=Delaware, L=Dover, O=Rocky Enterprise Software Foundation, OU=Release engineering team, CN=Rocky Linux Secure Boot Root CA/emailAddress=security@rockylinux.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e3:c4:6b:0f:5b:08:fd:db:51:fc:e0:49:39:e9:
                    a8:53:9b:1e:f0:57:ae:da:2c:05:33:5f:6f:2d:a4:
                    76:9e:db:63:40:86:77:a6:20:4b:35:c5:75:ca:dc:
                    5c:4b:a5:f8:ea:1a:e1:c2:47:fa:d3:c2:ef:fe:52:
                    83:94:16:42:90:b0:f2:13:2b:aa:73:22:e8:a0:42:
                    1b:35:02:a8:03:df:10:49:bd:a0:3d:94:35:4e:44:
                    25:78:08:44:99:c0:23:58:63:cc:56:48:a0:40:8b:
                    cb:eb:a0:fd:fc:93:22:46:df:43:36:69:01:f0:1d:
                    b1:7f:62:31:a0:50:be:56:f7:78:3e:2e:22:84:6f:
                    de:8a:81:c1:49:b1:94:7e:fb:7c:d8:f7:4a:20:1e:
                    37:9e:91:05:e8:5f:bf:aa:4e:cd:67:c9:cc:9e:5d:
                    17:90:7f:fd:74:64:c4:a9:e3:1b:03:03:d2:35:a2:
                    87:2a:e4:e5:74:b8:c3:56:82:71:0c:b3:e3:cc:38:
                    a3:51:bb:58:b9:97:be:36:95:9e:64:32:25:d5:a4:
                    94:9d:01:34:5e:cf:68:39:9e:56:74:72:d4:22:1b:
                    34:46:44:14:c2:14:17:88:c3:16:ac:ea:9a:f9:85:
                    f1:00:fb:d9:0e:a0:e0:cf:d1:3d:2c:24:d2:59:94:
                    a4:a5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                4C:2C:6B:D7:D6:4E:E8:15:81:CA:B8:E9:86:66:1F:65:E2:16:6F:C4
            X509v3 Authority Key Identifier: 
                4C:2C:6B:D7:D6:4E:E8:15:81:CA:B8:E9:86:66:1F:65:E2:16:6F:C4
            X509v3 Basic Constraints: 
                CA:TRUE
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        4f:b2:73:90:ad:13:07:fb:1f:66:05:65:8d:21:7e:a9:48:d3:
        92:fc:2e:14:04:9b:ff:48:7d:74:d6:89:12:af:eb:bb:51:91:
        43:9a:df:2b:fe:8c:53:9c:4a:86:96:0a:7b:d4:78:b2:b7:bf:
        c6:61:5f:d9:0c:b6:40:d4:f1:b2:1e:14:74:10:da:42:3f:a5:
        95:4b:22:e4:ec:fb:a9:6a:c9:14:c5:eb:02:f9:04:08:f8:6f:
        51:ed:48:9d:d6:c0:14:1e:00:42:d5:cb:2c:a5:a8:9e:30:8c:
        73:8c:c9:b0:d0:75:82:52:b8:ee:f2:4b:87:18:a0:09:ae:93:
        11:61:ed:62:8d:8c:cb:9e:59:05:b2:41:68:67:d6:5b:fd:17:
        6e:f4:87:59:bb:bd:d7:14:07:ca:ea:7b:45:1a:f1:fe:f5:6b:
        08:78:50:ab:29:a2:d4:41:35:96:ba:76:89:d7:53:5e:46:01:
        55:4f:0c:44:2a:7e:7d:78:49:85:2b:08:29:b5:cc:e5:f4:f4:
        78:1f:64:32:e0:9d:e3:a2:9f:0d:a6:d3:7f:29:f8:89:bb:e2:
        7d:19:65:54:3f:42:e5:a9:4b:2e:31:98:9a:2a:19:0e:b7:ed:
        c3:f9:4a:ca:63:b8:43:c3:93:7b:bb:24:50:1a:15:48:54:c3:
        9a:2a:07:33

If I’m the only one with the issue is it a bug?

Thanks for the very clear detail, we won’t know if you’re the only one until lots of people have installed the new shim and tried to reboot. Can you also say a bit about the hardware, is this on a real PC or a virtual guest?

Hardware:

$ inxi
CPU: quad core AMD Ryzen 5 3400G with Radeon Vega Graphics (-MT MCP-)
speed/min/max: 1342/1400/3700 MHz
Kernel: 5.14.0-362.24.1.el9_3.0.1.x86_64 x86_64 Up: 15h 30m 

Is there anyway to compare keys in shim with enrolled?

I do have a Rocky9 instance in a vm dual booting with Fedora39 that has not been updated in April. Secure Boot is not enabled in the vm. I could try to enable and then update if there is value to do so. This is a testing install so does not run normally.

Amending this post since I discovered that it is not possible to enable secure boot on my vm’s. I did get some output from journalctl as pasted below.

Apr 12 18:04:21 server.domain kernel: Loaded X.509 cert 'Rocky kernel signing key: 4d2b1020fffc9503b86f8624f149a91811fde20b'
Apr 12 18:04:21 server.domain kernel: Loaded X.509 cert 'Rocky Enterprise Software Foundation: Rocky Linux Driver Signing Cert 101: ce537f0c6>
Apr 12 18:04:21 server.domain kernel: Loaded X.509 cert 'Rocky Enterprise Software Foundation: Rocky Linux Driver Signing Cert 101 (aarch64):>
Apr 12 18:04:21 server.domain kernel: Loaded X.509 cert 'Rocky Enterprise Software Foundation: Rocky Linux IMA CA: 1d1cda4d16acd5196226d19e1f>
Apr 12 18:04:21 server.domain kernel: zswap: loaded using pool lzo/zbud
Apr 12 18:04:21 server.domain kernel: page_owner is disabled
Apr 12 18:04:21 server.domain kernel: Key type big_key registered
Apr 12 18:04:21 server.domain kernel: Key type encrypted registered
Apr 12 18:04:21 server.domain kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
Apr 12 18:04:21 server.domain kernel: integrity: Problem loading X.509 certificate -126
Apr 12 18:04:21 server.domain kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
Apr 12 18:04:21 server.domain kernel: integrity: Loaded X.509 cert 'Rocky Enterprise Software Foundation: Rocky Linux Secure Boot Root CA: 4c>
Apr 12 18:04:21 server.domain kernel: ima: No TPM chip found, activating TPM-bypass!
Apr 12 18:04:21 server.domain kernel: Loading compiled-in module X.509 certificates
Apr 12 18:04:21 server.domain kernel: Loaded X.509 cert 'Rocky kernel signing key: 4d2b1020fffc9503b86f8624f149a91811fde20b'
Apr 12 18:04:21 server.domain kernel: ima: Allocated hash algorithm: sha256
Apr 12 18:04:21 server.domain kernel: ima: No architecture policies found

The integrity check indicated a problem.

But the journalctl output is from a boot session where secure boot is disabled? Otherwise, it would not get that far. I think you were saying you can’t boot at all with secure boot enabled, so there’d be no journal to look at? If you’re on real hardware you’d need to enable secure boot, then try to boot and write down the exact error message (or whatever goes wrong).

When I was asking about hardware, I mean the exact motherboard model, because that’s where the UEFI lives. Are you on the latest “BIOS” for this board, and have you ever messed with the certificate databases in the “BIOS”?

Correct, I was looking for any output in the following boot.

$ inxi -M
Machine:
  Type: Desktop System: Gigabyte product: B450M DS3H v: N/A
    serial: <superuser required>
  Mobo: Gigabyte model: B450M DS3H-CF v: x.x serial: <superuser required>
    UEFI: American Megatrends v: F50 date: 11/27/2019

I won’t flash the firmware even iff there is an update. It’s a one shot deal that kills MB if it goes sideways. Secure Boot is an option not a necessity.

Over a year ago I did extract the CA certificates from a Rocky 9 kernel source and then; proceeded to enroll those in the firmware. I then discovered that you did not need to do that as shim-x86_64 did that automagically so I removed those CA’s with the mockutil. I’ve been successfully booting with secure boot for almost a year now w/o any issues till this last update and there have been several new kernels during that time period.
If no one else indicates an issue I’ll assume it is my unique setup and live with that or when I have time to do more testing I may figure it out.

I’ve resolved the issue.
It is a firmware configuration issue. This AMI firmware has multiple secure boot configuration options and one configuration option selected was “Custom” which I switched to “Standard” Saved and booted with Secure Boot enabled and I am now logged in and all is working now.

So this is not a bug.

1 Like

Good news. I’m surprised you don’t want to updat the BIOS, but I know what you mean about the risk. Sounds like something in the “Custom” was confusing the new shim.