If you’re using older Azure Linux Virtual Machines and need to update their Secure Boot certificates, here’s what you need to know and the steps you should take.
Azure doesn’t automatically update Secure Boot certificates (the CA and KEK certificates from 2023) on existing long-running Linux VMs. Instead, these updates have to be applied manually inside the virtual machines. This is because Azure Trusted Launch and Gen2 VMs expose the virtual UEFI firmware directly to the guest operating system, meaning managing these cryptographic certificates is considered an OS-level task for the user. While new VMs created in Azure automatically include the latest 2023 certificates thanks to updated templates, existing VMs keep their original certificates until the administrator performs an update.
The best source for guidance on how to perform this update is the official documentation titled “Secure Boot certificate updates for Linux on Azure virtual machines.” Follow the step-by-step instructions exactly as laid out there. You’ll typically use tools like fwupdmgr or efi-updatevar to send the signed .auth payloads into the EFI variable store, completing the certificate update process.
However, there’s an important warning to keep in mind. If your VM is a Linux Confidential VM (CVM) deployed before April 2024, and it uses full disk encryption tied to the vTPM, do not attempt this manual update. Changing the Secure Boot database (DB) will modify PCR7 measurements, which can break the disk’s decryption seal at the next reboot. For these legacy CVMs, the safest approach is to recreate the VM with updated firmware instead of trying to update the certificates in place.
Here are some safety tips before you proceed:
– Avoid updating legacy Confidential VMs or VMs with Full Disk Encryption linked to vTPM if vendor guidance advises against it.
– Test the process first on a non-production VM that has the same setup as your active environment.
– Always back up critical data and snapshots before making changes to EFI variables.
– Use only the signed .auth payloads provided by Microsoft. Do not attempt to craft unsigned or custom payloads, as this can cause issues.
If this information helps you resolve your issue, please consider marking it as the correct answer to assist others in the community.