nicht vergessen: UEFI-Zertifikate Eurer EFI-Disk Instanzen 06.2026!

jim_os · 2026-05-05T12:43:42+0200

Ich meinte die Einstellung für SecureBoot in dem BIOS meiner Fujitsu Kiste hier auf der der Proxmox Host läuft. Aber mit "Übersichtsseite" meinst Du ja vermutlich das

und wenn ja wäre meine Frage ja geklärt.

VG Jim

rothkraut · 2026-05-05T14:05:48+0200

Oh mann das habe ich noch gar nicht auf dem Schirm gehabt. Jetzt fange ich an zu schwitzen.

Wir sind dieses Jahr von VMWare zu Proxmox gewechselt. (Migration läuft gerade noch).

In meinem momentan 5- Host Cluster (~300 VMs) ist für einen Host Secure Boot aktiviert. Reicht es hier Secure Boot für den Host zu deaktivieren, oder muss ich jetzt nen ganzen Haufen VMs anfassen?

boisbleu · 2026-05-05T14:19:12+0200

Der Host hat ja erstmal nichts mit den VMs zu tun. Wenn der Host ein aktuelles BIOS hat und dort alle neuen Zertifikate hinterlegt sind, kannst du ihn so belassen. dmesg | grep cert gibt dir Auskunft. Falls nicht, dann musst du im BIOS SecureBoot deaktivieren.

Was die VMs angeht, das kommt drauf an, welche VMs EFI+SecureBoot nutzen. Die sollten auf jeden Fall umgestellt werden. Aber auch hier kann man natürlich SecureBoot deaktivieren. Oder für Windows Servern die Zertifikate in PVE ausrollen: qm enroll-efi-keys VM-ID und dann in Windows in einer administrativen PowerShell [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’ ausführen.

Kommt ein False, dann die beiden Befehle ausführen:

Code:

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot” -Name “AvailableUpdates” -Value 0x40
Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”

Dann 2x neustarten und danach wieder in der PS prüfen mit [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’

Ein True gibt grünes Licht. ;-)

jim_os · 2026-05-05T14:36:52+0200

boisbleu said:
dmesg | grep cert

Ich steuer hier einfach mal zwei Beispiele in Form von Screenshots bei.

Meine Refurbished Fujitsu D958 Mint Kiste bei der ich vor einigen Monaten mal ein BIOS Update gemacht habe und für die es tatsächlich auch noch ein neues BIOS von 2025 gab.

Meine Refurbished Fujitsu D957 Proxmox Host Kiste bei der ich seit Jahren kein BIOS-Update mehr gemacht habe und aktuell auch gar nicht weiß von wann dann die letzte verfügbare BIOS-Version überhaupt ist. Danach sollte ich jetzt vermutlich mal schauen.

VG Jim

boisbleu · 2026-05-05T14:49:19+0200

Haben beide noch keine aktuellen Zertifikate im BIOS installiert.

So sollte es aussehen:

Code:

root@pve:~# dmesg | grep cert
[    0.510865] Loading compiled-in X.509 certificates
[    0.511303] Loaded X.509 cert 'Build time autogenerated kernel key: 4a679945f66dced768781cfb6eed3b43f2a2cebe'
[    0.759472] integrity: Loading X.509 certificate: UEFI:db
[    0.759495] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[    0.759496] integrity: Loading X.509 certificate: UEFI:db
[    0.759505] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[    0.759506] integrity: Loading X.509 certificate: UEFI:db
[    0.759513] integrity: Loaded X.509 cert 'UEFIappl1: bacbd1866364e297ef689bd204133fd28731f668'
[    0.759514] integrity: Loading X.509 certificate: UEFI:db
[    0.759520] integrity: Loaded X.509 cert 'Microsoft Corporation: Windows UEFI CA 2023: aefc5fbbbe055d8f8daa585473499417ab5a5272'
[    0.760457] integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
[    0.760889] integrity: Loaded X.509 cert 'Proxmox Server Solutions GmbH: Secure Boot CA: b5f1b11e482db5869329cb975aa35205f872cd7a'
[    0.760894] Loading compiled-in module X.509 certificates
[    0.761243] Loaded X.509 cert 'Build time autogenerated kernel key: 4a679945f66dced768781cfb6eed3b43f2a2cebe'

oder so:

Code:

root@pve-m5:~# dmesg | grep cert
[    0.519715] Loading compiled-in X.509 certificates
[    0.520076] Loaded X.509 cert 'Build time autogenerated kernel key: 4a679945f66dced768781cfb6eed3b43f2a2cebe'
[    0.715108] integrity: Loading X.509 certificate: UEFI:db
[    0.715126] integrity: Loaded X.509 cert 'Microsoft UEFI CA 2023: 81aa6b3244c935bce0d6628af39827421e32497d'
[    0.715127] integrity: Loading X.509 certificate: UEFI:db
[    0.715134] integrity: Loaded X.509 cert 'Microsoft Corporation: Windows UEFI CA 2023: aefc5fbbbe055d8f8daa585473499417ab5a5272'
[    0.715135] integrity: Loading X.509 certificate: UEFI:db
[    0.715317] integrity: Loaded X.509 cert 'Fujitsu Technology Solutions GmbH: DB: 9d8e0a4aa809435e7318cc863546eacfa37403e6'
[    0.715317] integrity: Loading X.509 certificate: UEFI:db
[    0.715324] integrity: Loaded X.509 cert 'SUSE Linux Enterprise Secure Boot Signkey: 3fb077b6cebc6ff2522e1c148c57c777c788e3e7'
[    0.715325] integrity: Loading X.509 certificate: UEFI:db
[    0.715331] integrity: Loaded X.509 cert 'Fujitsu Technology Solutions: FTS Linux module signing key: febf4f2f1b2d2ea95b6c280699cd2ab1a0b742f3'
[    0.715331] integrity: Loading X.509 certificate: UEFI:db
[    0.715418] integrity: Loaded X.509 cert 'Fujitsu Limited: DB: 3fed9745e0eb46b35dbcb9f65e61c41ab5a30405'
[    0.715419] integrity: Loading X.509 certificate: UEFI:db
[    0.715504] integrity: Loaded X.509 cert 'FUJITSU Software: Fujitsu BIOS DB FJMW Certificate: 74ad174acf5fa0378680c24d2875e04223cf47a9'
[    0.715505] integrity: Loading X.509 certificate: UEFI:db
[    0.715588] integrity: Loaded X.509 cert 'Fujitsu BIOS DB Certificate: 2ebf8cd9b3324e874ef4e790ea6d1585'
[    0.715589] integrity: Loading X.509 certificate: UEFI:db
[    0.715597] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[    0.715597] integrity: Loading X.509 certificate: UEFI:db
[    0.715604] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[    0.715734] integrity: Revoking X.509 certificate: UEFI:dbx
[    0.715741] blacklist: Revoked X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'
[    0.715741] integrity: Revoking X.509 certificate: UEFI:dbx
[    0.715746] blacklist: Revoked X.509 cert 'Cisco: Virtual UEFI SubCA: 13df2e3f54ebf347dcaecebf21d3cbb2355a4c9a'
[    0.715747] integrity: Revoking X.509 certificate: UEFI:dbx
[    0.715751] blacklist: Revoked X.509 cert 'Debian Secure Boot Signer: 00a7468def'
[    0.715989] integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
[    0.716263] integrity: Loaded X.509 cert 'Proxmox Server Solutions GmbH: Secure Boot CA: b5f1b11e482db5869329cb975aa35205f872cd7a'
[    0.716266] Loading compiled-in module X.509 certificates
[    0.716551] Loaded X.509 cert 'Build time autogenerated kernel key: 4a679945f66dced768781cfb6eed3b43f2a2cebe'

PS: wobei ich mir bei den Fujitsu und den Proxmox Zertifikaten nicht sicher bin.

rothkraut · 2026-05-05T14:54:51+0200

@boisbleu danke für die Rückmeldung!

Gibt es eine Möglichkeit heraus zu finden, welche VMs secure-boot aktiviert haben, ohne dies direkt im EFI-Setup

boisbleu said:
Was die VMs angeht, das kommt drauf an, welche VMs EFI+SecureBoot nutzen.

Gibt es die Möglichkeit zu überprüfen, ob die VMs mit Secure Boot laufen, ohne dies im EFI-Startmenü zu überprüfen? Im Laufendem Betrieb?
Google meint:

qm config VMID

Look for a line that includes efidisk0.
To see if keys are enrolled, check for pre-enrolled-keys=1 in that line.

Habe das mal für ein paar VMs mit EFI-Disk überprüft. Bei denen war bis jetzt "pre-enrolled-keys=1" nicht zu finden.

Ich führe gerade eine ziemlich große Migration von VMWare zu Proxmox durch. Die VMWare Umgebung habe ich von einem Kollegen übernommen, welcher nicht mehr in der Firma ist. Daher kann ich nicht sagen, wie die Server aufgesetzt wurden.

jim_os · 2026-05-05T14:57:59+0200

boisbleu said:
Haben beide noch keine aktuellen Zertifikate im BIOS installiert.

Jo Microsoft Corporation: Windows UEFI CA 2023 fehlt, aber bei meiner Mint Kiste ist mir das ziemlich egal und um die Proxmox Kiste muss ich mich ja eh noch kümmern. Bei dem älteren Fujitsu D957 (Proxmox Host) ist das letzte verfügbare BIOS aus 2024 und bei dem "neueren" D958 (Mint) gibt es jetzt auch kein neueres BIOS mehr als das was darauf bereits installiert ist. Aber bei beiden ist SecureBoot im Fujitsu BIOS ja auch deaktiviert.

VG Jim

proxuser77 · 2026-05-05T15:23:44+0200

jim_os said:
Jo Microsoft Corporation: Windows UEFI CA 2023 fehlt, aber bei meiner Mint Kiste ist mir das ziemlich egal und um die Proxmox Kiste muss ich mich ja eh noch kümmern. Bei dem älteren Fujitsu D957 (Proxmox Host) ist das letzte verfügbare BIOS aus 2024 und bei dem "neueren" D958 (Mint) gibt es jetzt auch kein neueres BIOS mehr als das was darauf bereits installiert ist. Aber bei beiden ist SecureBoot im Fujitsu BIOS ja auch deaktiviert.

VG Jim

Wenn in der Übersicht „Legacy BIOS” steht, wie auf deinem Screenshot, dann ist Secure Boot für den Host definitiv nicht aktiviert.

Und wenn „pre-enrolled-keys=1” nicht zu finden ist, würde ich sagen, dass auch in den VMs kein Secure Boot aktiv ist.

Wenn du zu 120 % sicher sein willst, kannst du beim Booten der UEFI-VMs ESC oder F2 drücken, um ins virtuelle BIOS dieser VMs zu gelangen und dort Secure Boot noch abzuschalten. Aber ohne Keys kein Secure Boot, daher wird das wahrscheinlich nicht nötig sein, wenn „pre-enrolled-keys=1” nicht zu finden ist.

jim_os · 2026-05-05T15:27:43+0200

proxuser77 said:
Wenn du 120 % sicher sein willst

Jo danke für die zusätzlichen Infos. Ich schaue mir das die Tage dann alles noch einmal in Ruhe an. Aktuell sehe ich bei mir jetzt auch nicht die dringende Notwendigkeit da jetzt spontan irgendetwas zu machen, ohne mir das nicht alles mal in Ruhe angeschaut zu haben.

VG Jim

boisbleu · 2026-05-05T16:17:05+0200

rothkraut said:
Gibt es die Möglichkeit zu überprüfen, ob die VMs mit Secure Boot laufen, ohne dies im EFI-Startmenü zu überprüfen? Im Laufendem Betrieb?

Du meinst nicht innerhalb von Windows (msinfo wäre hier dein Freund), sondern auf PVE Ebene?

jim_os · 2026-05-05T16:56:16+0200

boisbleu said:
Innerhalb einer Windows-VM lässt sich das in der Powershell (mit administrativen Rechten gestartet) prüfen:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’

Vielleicht auch dazu einfach noch einen Screenshot.

In dem Fall jetzt von meiner Windows 11 VM unter Proxmox.

Edit: Ich habe das jetzt gerade mal per qm enroll-efi-keys 112 bei einer Home Assistant VM getestet und das Ergebnis davon sieht so aus:

Was mich jetzt ein wenig irritiert. Was soll oder will mir diese Meldung bei einer Linux VM mit BIOS: OVMF (UEFU) und EFI-Disk

jetzt sagen? Vermutlich ja das bei dieser HA VM kein Update notwendig ist?

VG Jim

rothkraut · 2026-05-05T18:11:12+0200

boisbleu said:
Du meinst nicht innerhalb von Windows (msinfo wäre hier dein Freund), sondern auf PVE Ebene?

Genau auf PVE-Ebene. Über CLI oder ob es irgendwo in den Options zu finden ist.

boisbleu · 2026-05-05T19:48:27+0200

Gute Frage. Vermutlich wenn EFI Disk und TPM vorhanden sind. Wobei SecureBoot ja nur funktioniert, wenn die Keys ausgerollt werden. Also müsste man mit dem pre-enrolled-keys=1 weiterkommen.

Vielleicht weiß jemand anderes, ob es da eine elegante Suchmöglichkeit gibt.

boisbleu · 2026-05-06T07:47:50+0200

Danke an die DENIC für gestern Abend!

cd /etc/pve/qemu-server
grep "pre-enrolled-keys=1" *.conf

Sowas in der Art.

pr0xyzer · 2026-05-06T09:05:12+0200

Habe ich total verpennt, danke!

fiona · 2026-05-06T10:26:01+0200

Hallo @jim_os,
wenn bisher keine Secure-Boot-Keys auf der EFI-Disk waren (kein pre-enrolled-keys=1), brauchst Du auch keine neuen ausrollen.

woma · 2026-05-06T10:59:52+0200

Linux Gäste kann man prüfen auf Bootvorgang mit Secure Boot, wenn QEMU Guest Agent aktiv ist:

Code:

root@node5 ~ # qm guest exec 192204 -- mokutil --sb-state                                                 
{
   "exitcode" : 0,
   "exited" : 1,
   "out-data" : "SecureBoot enabled\n",
   "out-truncated" : 0
}

Das ganze geht auch schön, wenn man die JSON Formatierung (ggf. jq installieren mit apt) entfernt und die LF wieder "scharf" macht (bei mehrzeiligen Ausgaben/Tabellen recht nützlich), es kommt dann als Antwort nur die "rohe" Konsolenausgabe aus dem Gast :

Code:

root@node5 ~ # qm guest exec 192204 -- mokutil --sb-state | jq '."out-data"' | sed 's/\\n/\n/g' | tr -d '"'   
SecureBoot enabled

Achso Variante "hab gar kein EFI", dann ist auch i. d. R. kein mokutil installiert, sieht dann so aus:

Code:

root@node5 ~ # qm guest exec 9072 -- mokutil | jq '."out-data"' | sed 's/\\n/\n/g' | tr -d '"'         
Wide character in die at /usr/share/perl5/PVE/RESTHandler.pm line 1024.
Agent error: Guest agent command failed, error was 'Failed to execute child process “mokutil” (No such file or directory)'

Ergänzung:
Nicht aktives Secure Boot aber EFI sieht dann so aus, nur schnell bei Workstation abgefragt:

Code:

XXXXXX@XXXXXX:~$ sudo mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode

jim_os · 2026-05-06T11:05:42+0200

Hallo @fiona

fiona said:
wenn bisher keine Secure-Boot-Keys auf der EFI-Disk waren (kein pre-enrolled-keys=1), brauchst Du auch keine neuen ausrollen.

Danke für die Info. Im Moment sieht es bei meinen VMs so aus

Code:

root@pve:~# for id in $(qm list | awk 'NR>1 {print $1}'); do
  echo "VM $id:"
  qm config $id | grep efi
  echo
done
VM 101:

VM 104:
efidisk0: local-lvm:vm-104-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M

VM 105:

VM 106:

VM 108:
efidisk0: local-lvm:vm-108-disk-0,efitype=4m,size=4M

VM 109:

VM 112:
efidisk0: local-lvm:vm-112-disk-1,efitype=4m,size=4M

VM 113:

root@pve:~#

D.h. nur bei der VM 104 - bei der es sich eben um eine Windows 11 VM handelt - gibt es den pre-enrolled-keys=1 Eintrag. Bei dieser Windows VM wurde durch die Windows Updates aber bereits das 2023er Zertifikat erstellt

Was aber an dem EFI-Disk-Eintrag nichts verändert hat. D.h. da taucht jetzt nicht zusätzlich der entsprechende ms-cert=2023k Eintrag mit auf. Bsp. von einem anderen User, allerdings von einer Home Assistant VM (ID 103).

OK es könnte natürlich sein das ein Windows Update nichts an dem EFI-Disk-Eintrag bei der VM ändert und deshalb der ms-cert=2023k Eintrag da nicht erscheint. Aber das weiß ich nicht. Aktuell siehe es bei der Windows 11 VM so aus.

Lt. Windows Powershell Info ist das neue 2023 UEFI Cert 2023 bereits installiert und lt. Proxmox könnte ich noch ein "Enroll Updated Certificates" durchführen.

Vielleicht noch zwei Anmerkungen dazu:
1. Ich nutze hier noch nicht den 7er Kernel bei Proxmox sondern noch Kernel 6.17.13-3 mit PVE 9.1.9

2. Einfach nur zur Info: Es gibt um HA-Forum von Simon auch noch eine jetzt längere Diskussion zu dem Thema, die ich dort "angezettelt" habe.

https://community.simon42.com/t/fyi...efi-secure-boot-zertifikate-bis-06-2026/84989

VG Jim

boisbleu · 2026-05-06T11:12:00+0200

Hallo @fiona

kannst du was zu EFI + SecureBoot für den Host sagen, was die Zertifikate angeht?

Da gibt es ja einmal
integrity: Loaded X.509 cert 'Proxmox Server Solutions GmbH: Secure Boot CA: b5f1b11e482db5869329cb975aa35205f872cd7a'

und dann die Microsoft Zertifikate
integrity: Loaded X.509 cert 'Microsoft Corporation: Windows UEFI CA 2023: aefc5fbbbe055d8f8daa585473499417ab5a5272'

Braucht PVE beide Zertifikate oder nur eines davon künftig für EFI + SecureBoot?

nicht vergessen: UEFI-Zertifikate Eurer EFI-Disk Instanzen 06.2026!

Well-Known Member

New Member

Active Member

Well-Known Member

Active Member

New Member

Well-Known Member

Well-Known Member

Well-Known Member

Active Member

Well-Known Member

New Member

Active Member

Active Member

Member

Proxmox Staff Member

New Member

Well-Known Member

Active Member

We value your privacy