"error: /boot/vmlinuz-6.6.9-amd64 has invalid signature" with secure boot on in Kali Linux

Question

When I try to run my Kali Linux system with secure boot on, GRUB returns error: /boot/vmlinuz-6.6.9-amd64 has invalid signature. I don't want to turn off secure boot. I have followed the directions from here: https://www.reddit.com/r/archlinux/comments/10pq74e/my_easy_method_for_setting_up_secure_boot_with
I used the command grub-install --target=x86_64-efi --efi-directory=/boot/efi --modules="tpm" --disable-shim-lock to reinstall grub.
I am dual-booting Windows 11 with Kali Linux.
I run an HP Envy x360.

Answer 1

The instructions in the Reddit post you linked will only work if the grubx64.efi installed by grub-install is signed by Microsoft - and apparently Arch may have spent the time and money to do that.

Debian chose to do things differently, and since Kali is based on Debian, the same approach is probably in effect in Kali too. In Debian's Secure Boot solution, only the shimx64.efi is signed by Microsoft:

/boot/efi/EFI/debian# pesign -S -i shimx64.efi 
---------------------------------------------
certificate address is 0x7f0756f2a498
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher  <--- Microsoft!
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------

Debian actually builds the shim as a reproducible binary, so they can provide the detached Microsoft signature as a separate file together with the shim source code, and if you wish to audit the shim, you can build it yourself and add the signature to it, and if you used the correct compiler versions and the exact procedure, the resulting build will be 100% identical to Debian's, and so the signature will be valid when attached to it.

When used, it will non-persistently add Debian's Secure Boot certificate to the whitelist, and then the system can boot Debian's grubx64.efi, which is signed by Debian's certificate.

/boot/efi/EFI/debian# pesign -S -i grubx64.efi 
---------------------------------------------
certificate address is 0x7f87b4b03008
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Debian Secure Boot Signer 2022 - grub2  <- no MS, just Debian
No signer email address.
Signing time: Wed Oct 04, 2023
There were certs or crls included.
---------------------------------------------

This allows Debian more flexibility with GRUB updates, as they won't have to wait for Microsoft to sign the new version. The shim is supposed to be a very simple and thoroughly audited piece of code, so it is expected to need less updates.

Kali would have to have their distribution's own signature there, as the Kali distribution obviously won't have access to Debian's private keys.

The recipe in the Reddit post relies heavily on sbctl. It seems to be part of the systemd-boot bootloader, and by default only cares about files in the locations expected by systemd-boot. That is apparently why the Reddit poster had to do this:

Check which files need to be signed for secure boot to work:

sudo sbctl verify

Sign all unsigned files (below is what I needed to sign, adjust according to your needs):

sudo sbctl sign -s /efi/EFI/GRUB/grubx64.efi

If Kali follows Debian's model, then Kali's kernel is already signed - but not with your keys generated by sbctl. Perhaps sbctl just detected that the kernel is already signed and so did not tell you that it now needs to be re-signed with your keys?

Or perhaps it did, and the resulting kernel now has multiple signatures. This should be possible, but that is probably a poorly-tested area of the Secure Boot specification, so there might be a bug somewhere. Maybe the signature was applied incorrectly, and cannot be validated? Or maybe your UEFI firmware (which is ultimately responsible for verifying Secure Boot signatures as long as firmware routines are used for disk access - like UEFI version of GRUB does) has a bug in handling multiply-signed boot files?