Just a quick note in case someone else runs into the same issue as me: I have a machine running Ubuntu 18.04 (LTS), and in order to get some of the hardware working, I used ukuu to upgrade the kernel from the Ubuntu versions (4.15.0.xx.xx) to an upstream version (4.18.20).
At first this caused me no problems, but after a while, I started to run into the following message when trying to update packages:
Cannot upgrade Secure Boot enforcement policy due to unsigned kernels
Your system has UEFI Secure Boot enabled in firmware, and the following kernels present on your system are unsigned:
4.18.20-041820-generic
These kernels cannot be verified under Secure Boot. To ensure your system remains bootable, GRUB will not be upgraded on your disk until these kernels are removed or replaced with signed kernels.
What seems to be happening is that newer versions of grub enforce more secure booting policies, which is a good thing. The problem is that the upstream kernels aren’t signed with Ubuntu’s trusted keys.
When I googled for this problem the suggestions seemed to be disabling UEFI secure booting in the BIOS, or removing the kernels. Removing the kernels would break some of my hardware, and I didn’t want to disable the secure boot setting because I sometimes boot the machine to Windows and I really don’t want any malware inserting itself secretly into the Windows boot process (I don’t want this on Linux either, but any malware that has root permissions on my Linux boot has already won).
After I realised what I needed to actually google for, I found this Ubuntu blog article which explains how to create a machine owner key (MOK), set up Ubuntu to trust it, and sign things with it. I followed the steps described starting with “Certificates in shim” to generate and enrol a certificate. (You may be able to use update-secureboot-policy directly to create and enrol the certificate, but I didn’t discover that until I got to the end of the blog article, so I haven’t tried that way.)
It’s worth noting as you read that article that you do not want to include “1.3.6.1.4.1.2312.16.1.2” in the extendedKeyUsage of your certificate or you’ll only be able to sign kernel modules and not kernel themselves.
I then used sbsign as described in the article to sign /boot/vmlinuz-4.18.20-041820-generic. I moved the original to a different directory for safekeeping and replaced it with the signed version. (Keeping both versions side by side in /boot/ is a bad idea because grub will see both and still complain about having an unsigned one there.)
I then did two final steps:
sudo dpkg-reconfigure grub-pc
This causes grub to rebuild its menus. This is probably not strictly necessary because I didn’t actually add any new kernels to /boot/, but I thought it was worth running to make sure there weren’t any errors.
sudo dpkg --configure grub-efi-amd64-signed
This fixes the installation of the package that was broken. If all goes according to plan, it should no longer show an error.