Where are Canonical's secure boot certificates?

This is what I found,

https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/KeyGeneration
https://ubuntu.com/blog/how-to-sign-things-for-secure-boot
https://wiki.ubuntu.com/UEFI/SecureBoot
https://wiki.ubuntu.com/UEFI/SecureBoot/Testing
https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/ImageSigning?action=show&redirect=SecurityTeam%2FSecureBoot%2FImageSigning#Canonical_master_only
https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/KeyGeneration?action=show&redirect=SecurityTeam%2FSecureBoot%2FKeyGeneration#Master_certificate.2BAC8-key

I've read all of them. None of those pages have the actual certs.

The second page contains a link to a git repository (https://git.launchpad.net/qa-regression-testing/tree/notes_testing/secure-boot), which purports to have the certificates. The repository's code signing key (/notes_testing/secure-boot/keys/canonical-signing-public.der in that repo) is outdated, no longer used to sign the bootloader, and will not work when used.

The real certificate has a CN of "Canonical Ltd. Secure Boot Signing (2017)", and the one in that repository has a CN of "Canonical Ltd. Secure Boot Signing".

https://ubuntu.com/server/docs/security-trust-store

That also doesn't have them. The ca-certificates packages and /etc/ssl only contain certs for TLS, not secure boot.

Are you looking for the keys that are used for creating the signed kernels that are accepted by secure boot?
I cannot imagine that they are publicly available, because that would invalidate the whole concept of secure booting.

see https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html

...
As announced earlier today, we've generated an Ubuntu signing key for
use with UEFI. The private half of this key will be stored securely on
our Launchpad infrastructure, which will be responsible for signing boot
loader images and distributing them in the Ubuntu archive.
...

I'm looking for the certificates, the public half of the signing process. Certificates are public so anyone can verify a signature made by the private key. For example, Microsoft makes their secure boot certificates easily available via links on its secure boot help page https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance

Embedded in the shim loader.
How UEFI Secure Boot works on Ubuntu
On Ubuntu, all pre-built binaries intended to be loaded as part of the boot process, with the exception of the initrd image, are signed by Canonical's UEFI certificate, which itself is implicitly trusted by being embedded in the shim loader, itself signed by Microsoft.
https://wiki.ubuntu.com/UEFI/SecureBoot
Secure Boot is proprietary software owned by Microsoft.
Which an agreement to use for canonical software... etc! Fact...
If question is solved press solved.
Quote: "that would invalidate the whole concept of secure booting."
embedded within the shim loader. not human readable to be secure.
https://ubuntu.com/download/server
Ubuntu Jammy Jellyfish Ubuntu 22.04 LTS is in final release: 2022-04-21

Ubuntu does it's own signing on the bootloader; see the output of the sbverify in the original question. I need the certificates that correspond to those signatures.

Ubuntu Jammy Jellyfish Ubuntu 22.04 LTS is in final release: 2022-04-21
lsb_release -a; uname -a; python --version

That still doesn't help. Maybe a better answer is a who - who on the Ubuntu team works with bootloader signing and can supply the certificates?

There is a https://launchpad.net/~canonical-signing team, but I do not know whether they are involved in the area of your question.

I could be wrong, but if I'm reading this:
"Since the shim binary embeds a Canonical certificate as well as its own trust database, further elements of the boot environment can, in addition to being signed by one of the acceptable certificates pre-loaded in firmware, be signed by Canonical's UEFI key."

(https://wiki.ubuntu.com/UEFI/SecureBoot) right then the Canonical cert is embedded inside the shim PE32+ executable:

# ls -l /boot/efi/EFI/ubuntu*/shimx64.efi
-rwx------ 1 root root 955656 Apr 9 2022 /boot/efi/EFI/ubuntu-20.04/shimx64.efi
-rwx------ 1 root root 955656 Apr 9 2022 /boot/efi/EFI/ubuntu-22.04/shimx64.efi
-rwx------ 1 root root 960472 Feb 16 12:34 /boot/efi/EFI/ubuntu/shimx64.efi

But a UEFI expert had better weigh in, as I am not one.

Running

objdump -x /boot/efi/EFI/ubuntu-22.04/shimx64.efi

definitely show a lot of sections related to certificates. Unfortunately I don't know of any specialized tools for extracting and inspecting apart from generally knowing you can use objcopy to extract the contents of a section to a separate file.

Using non default (without any Microsoft certs) boot chain is possible, but is not widely supported or encouraged. Doing this will likely prevent application of dbx revocations, and will leave your system vulnerable to attacks using otherwise publically revoked Canonical binaries. Furthermore it will render your system unable to perform automatic firmware, bios, and attached hardware firmware updates (i.e. usb-c dock). It may also cause a lot of hardware to not work due to option Roms being signed with Microsoft keys only.

A better option is to assert the state of the system, and the certs/binaries used on every boot by asserting TPM bios measurements. This can make your system tamper proof, and provide additional measure of confidentially. On Ubuntu, this is done by default on our Ubuntu Core product with TPM backed FDE with measurements of the full boot chain asserted and verified on every boot. Is this what you are trying to achieve?

Please explain in detail what you are trying to achieve.

For running VMs we do provide edk2 builds with default set of certificates enrolled, and this is also used by default in LXD VM. These do use Microsoft KEK & DB keys with uefi.org dbx which ensure that Secureboot works, with ability to rotate keys, apply revocations, and support firmware hardware upgrades.

Yes, I am trying to create a secure boot chain without Microsoft's UEFI CA key for 3rd party UEFI executables. In light of confirmation of the BlackLotus UEFI bootkit, I feel this is a reasonable mitigation.

I am fine keeping Microsoft's KEK for the purpose of accepting dbx updates. I understand this will break option ROMs signed by the Microsoft UEFI CA. I can work around by extracting the option ROM hashes from a TPM boot log and adding them to the db myself. I have done this for nVidia option ROMs and it works; for example, I can boot into Windows with an nVidia card and without the MS UEFI CA cert in the db. Option ROMs are so rarely updated that adding hashes are fine, bootloaders on the other hand ... it would be more robust to trust a 1st-party signing certificate.

For Ubuntu, I just need the public certificate that Canonical uses to sign its bootloader. They rotated the key in 2017 and have not made the certificate public. One system is a NUC that does not have a TPM for measurements, so a hardened secure boot setup is the best option.

 To boot Canonical signed artifacts, without Microsoft keys in dB, you will need Canonical Master CA in the db. You can get it by using sbattach --dettach, openssl pkcs7 -inform der -print_certs -in detached signature, x509 to convert from pem to der. Alternatively you can find our master ca certificate in the source code of shim package shipped in Ubuntu. I will not provide links to any of the above, as you should be able to verify in a trusted manner where you are getting these from.

Above will guarantee you can boot any Ubuntu current, past, future shim/grub/kernel.

For shim, you will want to divert .signed and use .dualsigned one instead. Hopefully your firmware accepts it fine. Otherwise use sbattach --dettach to strip Microsoft signature and only keep Canonical Master CA signature.

If you want to limit to booting only the most current signing certs, without any ability to boot past or long into future Ubuntu binaries, you can use sbattach --dettach to only enrol a particular signing certificate - currently various 2021, 2022 certs depending on the product and kernel you use. But these may be rotated in the future, still chained to Canonical Master CA. If enrolling individual signing certs into db, do ensure you verify it against Canonical Master CA that you have securely obtained.

You must sign/enroll the most recent dbx from uefi.org into dbx. It contains revocations of previous boot binaries that were signed by older Canonical certs, all chained to Master CA. Any future revocations from Canonical will be published to uefi.org as well. Updates there are signed by Microsoft KEK keys.

https://git.launchpad.net/qa-regression-testing/tree/notes_testing/bootloaders/keys