Dev input please on Microsoft CA 2023

A

adamb

Famous Member
Proxmox Subscriber
Mar 1, 2012
1,340
79
113
If we have Debian linux VM's running secure boot and the older 2011 certificate.

Let say Debian releases a new shim update after June and is singed by the 2023 cert, will all those VM fail to boot?
 
Last edited:
Last edited:
  • Like
Reactions: Stubennerd
sterzy said:
If the shim is only signed with the 2023 cert, which will be case eventually, and you did not enroll the 2023 certificate yet, yes they will likely fail to boot if secure boot is enabled.

See the docs for more information and on how to enroll the new certificate [1].

[1]: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_secure_boot_ca_expiration
Click to expand...
Appreciate the input.

When you say "eventually", how long do you suspect that will be? Trying to gauge how quickly we need to move on this.
 
The certificate expires on June 27, 2026. After that, Microsoft will no longer be able to sign shims with that certificate. Then it'll depend on how quickly Debian (and other distributions) will release new shims. However, you can simply enroll the keys for your Debian machines as soon as possible. They will take effect with the next reboot, so they'll be active once such a shim lands.

Edit: Fixed the date, the certificate signing third-party bootloaders expires on the 27 of June.
 
Last edited:
  • Like
Reactions: Johannes S
sterzy said:
The certificate expires on June 24, 2026. After that, Microsoft will no longer be able to sign shims with that certificate. Then it'll depend on how quickly Debian (and other distributions) will release new shims. However, you can simply enroll the keys for your Debian machines as soon as possible. They will take effect with the next reboot, so they'll be active once such a shim lands.
Click to expand...

Do the VM's need to be stop/started? Or is an actual reboot enough?
 
If you reboot through the UI, yes the changes should be applied. Otherwise, you will need to turn off the VM and turn it back on again. Note that this only works if you enroll the keys through the UI, the CLI command to enroll the keys requires the VM to be turned off.
 
sterzy said:
If you reboot through the UI, yes the changes should be applied. Otherwise, you will need to turn off the VM and turn it back on again. Note that this only works if you enroll the keys through the UI, the CLI command to enroll the keys requires the VM to be turned off.
Click to expand...

Is there anyway to make the CLI option function like the GUI/API? With 1000's of VM's that is a tough one. Setting up tokens on tons of hosts to use the API would be a lot of manual work as well.
 
Well not quite, but you can probably use pvesh to script something usable. What you'd need to do is use first get the current setting for efidisk0, you can do that via something like qm config <vmid>| grep efidisk0. Then append ms-cert=2023k to the old setting there and update the config like so: pvesh set /nodes/<node>/qemu/107/<vmid> --efidisk0 <new-config>.

So the finally pvesh command will likely look something like this: pvesh set /nodes/pve-1/qemu/110/config --efidisk0 "efitype=4m,file=image-store:vm-107-disk-0,pre-enrolled-keys=1,size=4M,ms-cert=2023k".

Note that you should make sure that no other config changes are made while you do this, or they might get overwritten.
 
sterzy said:
Well not quite, but you can probably use pvesh to script something usable. What you'd need to do is use first get the current setting for efidisk0, you can do that via something like qm config <vmid>| grep efidisk0. Then append ms-cert=2023k to the old setting there and update the config like so: pvesh set /nodes/<node>/qemu/107/<vmid> --efidisk0 <new-config>.

So the finally pvesh command will likely look something like this: pvesh set /nodes/pve-1/qemu/110/config --efidisk0 "efitype=4m,file=image-store:vm-107-disk-0,pre-enrolled-keys=1,size=4M,ms-cert=2023k".

Note that you should make sure that no other config changes are made while you do this, or they might get overwritten.
Click to expand...
Appreciate the input!

What throws me off, is the "qm enroll-efi-key vmid" seems to do a lot more than just add a tag to the vm config file.

root@frontend-test:~# qm enroll-efi-keys 100
efidisk0: enrolling Microsoft UEFI CA 2023
INFO: reading raw edk2 varstore from /var/run/qemu-server/qsd-vm-100-efi-enroll-efidisk0-enroll.fuse
INFO: var store range: 0x64 -> 0x40000
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftCorporationUEFICA2011.pem
INFO: certificate already present, skipping
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftUEFICA2023.pem
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftWindowsProductionPCA2011.pem
INFO: certificate already present, skipping
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/WindowsUEFICA2023.pem
INFO: add KEK cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftCorporationKEK2KCA2023.pem
INFO: writing raw edk2 varstore to /var/run/qemu-server/qsd-vm-100-efi-enroll-efidisk0-enroll.fuse
successfully updated efidisk
 
adamb said:
Appreciate the input!

What throws me off, is the "qm enroll-efi-key vmid" seems to do a lot more than just add a tag to the vm config file.

root@frontend-test:~# qm enroll-efi-keys 100
efidisk0: enrolling Microsoft UEFI CA 2023
INFO: reading raw edk2 varstore from /var/run/qemu-server/qsd-vm-100-efi-enroll-efidisk0-enroll.fuse
INFO: var store range: 0x64 -> 0x40000
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftCorporationUEFICA2011.pem
INFO: certificate already present, skipping
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftUEFICA2023.pem
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftWindowsProductionPCA2011.pem
INFO: certificate already present, skipping
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/WindowsUEFICA2023.pem
INFO: add KEK cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftCorporationKEK2KCA2023.pem
INFO: writing raw edk2 varstore to /var/run/qemu-server/qsd-vm-100-efi-enroll-efidisk0-enroll.fuse
successfully updated efidisk
Click to expand...

I think I understand now.

When the VM is stopped then started and this is in place "ms-cert=2023k", it does exactly what enroll-efi-key does right before it actually powers it on.
 
note that Debian is currently preparing the changes for their first shim update signed with both old and new microsoft keys, and that includes checking which keys are currently enrolled and refusing the update if there is no overlap. that means that for the next shim upgrade after (which under the usual cadence will not be this year ;)) that is only signed with the new key, if you've missed enrolling the matching certificate the Debian ugprade will fail and loudly warn, and you should still be able to reboot without secure boot breaking.
 
  • Like
Reactions: fiona, Johannes S and adamb
fabian said:
note that Debian is currently preparing the changes for their first shim update signed with both old and new microsoft keys, and that includes checking which keys are currently enrolled and refusing the update if there is no overlap. that means that for the next shim upgrade after (which under the usual cadence will not be this year ;)) that is only signed with the new key, if you've missed enrolling the matching certificate the Debian ugprade will fail and loudly warn, and you should still be able to reboot without secure boot breaking.
Click to expand...

Thank you for the input fabian, that makes me feel alot better about all this.
 
You must log in or register to reply here.
Top Bottom
Back