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

Treptower

Well-Known Member
Apr 18, 2021
108
22
58
beispielhaft hier mal ein Bild einer Instanz [160] mit EFI-Disk:

1775210341200.png

Denkt an die Erneuerung der UEFI-Zertifikate, wenn noch nicht geschehen!
Das betrifft nicht nur Windowsmaschinen!


Das Vorgehen hier wäre für die ID:160:
  • VM herunterfahren
  • Backup erstellen (ggf. Hinweise im LOG beachten!)
  • VM unten lassen
  • Proxmox Shell öffnen
    Code:
    qm enroll-efi-keys 160
  • VM starten und sie testen
  • Backup erstellen
 
Das reicht leider nicht. Bei Windows Server muss man die Zertifikate manuell installieren, siehe Link unten.

Code:
Windows Server 2025 certified server platforms already include the 2023 certificates in firmware. For servers that do not,
IT administrators must manually update the certificates, because Windows Server does not receive them automatically.
Unlike Windows PCs, which receive the 2023 Secure Boot certificates through Controlled Feature Rollout (CFR) as part of the
monthly update process, Windows Server requires manual action.
https://techcommunity.microsoft.com...ook-for-certificates-expiring-in-2026/4495789

Noch ein Thread zu diesem Thema
https://forum.proxmox.com/threads/secure-boot-–-microsoft-uefi-ca-2023-certificate-not-included-in-efi-disk.173417/
 
Last edited:
  • Like
Reactions: NetSecond
Ich war bisher der blauäugigen Meinung, maximal eine VM herunterfahren zu müssen und anschließend qm enroll-efi-keys <VMID> würde ausreichen, zumindest sofern kein bitlocker verwendet wird.

Wie denn nun? Tatsächlich einzeln in den guests rumbasteln?
 
Last edited:
Ich war bisher der blauäugigen Meinung, maximal eine VM herunterfahren zu müssen und anschließend qm enroll-efi-keys <VMID> würde ausreichen, zumindest sofern kein bitlocker verwendet wird.

Wie denn nun? Tatsächlich einzeln in den guests rumbasteln?
Soweit ich das gelesen haben ist bei den Windows Servern Handarbeit angesagt, Windows Client sollen das mittels Update selber machen.
Ist halt auch die Frage ob man unbedingt Secure Boot benötigt oder darauf verzichen kann.
 
Ist halt auch die Frage ob man unbedingt Secure Boot benötigt oder darauf verzichen kann.
Das war/ist auch immer mein Gedanke. Kein Secureboot und die Nummer ficht mich nicht an.
Ich glaube, ich werde beobachten was nach Ablauf der Frist geschieht und dann erst evtl. mit den Flügeln flattern
 
Last edited:
Wenn die Zertifikate nicht vor Ablauf erneuert werden, können sie danach nicht mehr aktualisiert werden. Wie auch - es gibt dann ja keine gültigen Zertifikate mehr, die die neuen installierbar und verifizierbar machen.
 
Wenn die Zertifikate nicht vor Ablauf erneuert werden, können sie danach nicht mehr aktualisiert werden. Wie auch - es gibt dann ja keine gültigen Zertifikate mehr, die die neuen installierbar und verifizierbar machen.
Die möglichen Folgen sind mir ja durchaus bewusst. Darum frage ich ja.
Nebenbei lasse ich mich nur sehr ungern am Nasenring durch die Manege führen. Das ist eine Mafiamethode: "Wenn du bis zum Tag X nicht reagierst, dann hast du ein Problem!"

Ohne Secureboot oder gar Bitlocker sollte das Zertifikatsgepfriemel doch aber wohl Wumpe sein?
Nur darum geht es mir.


Wer die Technik bewusst einsetzt, muss halt schwitzen und strampeln. Ich benutze sie genau darum bewusst nicht, möchte aber auch nicht auf die Nase fallen, weil ich irgendwas nicht auf dem Zettel hatte.

Sind wir also üblerweise tatsächlich soweit, dass ein simpler Zertifikationsrevoke deine Systeme lahmlegt?
Oder betrifft es nur die "paar" Menschen, die auf den altruistischen Weltmarktführer setzen?
Was müssen Menschen mit Baremetalinstallationen erst befürchten?

Nebenbei frage ich mich, warum ich mit einer extra angelegten EFI-Disk einer VM keine gültigen Keys automatisiert unterschieben kann. Also Müll löschen und mit gültiger Version ersetzen.
Fragen über Fragen.

P.S.:
Kannst du also, anstatt mögliche Folgen zu beschreiben was passieren könnte, versichern das es ohne "Secureboot" keine Probleme gibt? Oder fehlt dir gerade die Zeit, weil du gerade in der Registry von x VMS dengelst?
 
Last edited:
  • Like
Reactions: Johannes S
Guten Morgen,

korrekt. Es geht hier nur um UEFI SecureBoot.

Mittlerweile gibt's auch gute Zusammenfassungen von MS in deutsch zu dem Thema:
https://support.microsoft.com/de-de...gsstelle-7ff40d33-95dc-4c3c-8725-a9b95457578e

Und hier eine Anleitung zu dem Thema:
https://techcommunity.microsoft.com...g/updating-microsoft-secure-boot-keys/4055324

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’

Aber auch ein PVE, das mit EFI und SecureBoot läuft, braucht aktuelle Zertifikate!
dmesg | grep cert

Oder fehlt dir gerade die Zeit, weil du gerade in der Registry von x VMS dengelst?
Nein, ich hatte eine andere Lektüre:
https://tansanrao.com/blog/2025/04/xnu-kernel-and-darwin-evolution-and-architecture/
 
Last edited:
Wenn die Zertifikate nicht vor Ablauf erneuert werden, können sie danach nicht mehr aktualisiert werden. Wie auch - es gibt dann ja keine gültigen Zertifikate mehr, die die neuen installierbar und verifizierbar machen.
Also, wenn ich durch die hintertür gehe, das datum im BIOS auf einen zeitpunkt zurücksetze, werkseinstellungen setze, ohne internet boote, müsste es möglich sein, das zertifikat zu aktualisieren. Ich meine auch mal gelesen zu haben, das bei einigen systemen das nicht ohne ein BIOS Update gehen soll. Kann aber jetzt auch eine Fehlinformation sein.
Auf jeden Fall habe ich das auf Servern bisher abgeschaltet und warte auch mal ab.
 
Ist halt auch die Frage ob man unbedingt Secure Boot benötigt oder darauf verzichten kann.
Ist das bei Linux-VMs (auch mit aktivierten UEFI) überhaupt aktiv? Das wäre dann ein Grund für mich wieder aufs klassische BIOS zurückzuwechseln ;)
 
  • Like
Reactions: ThoSo
Im Wizard ist zumindest standardmässig der Haken bei „Pre-Enroll Keys” gesetzt, wenn man das OVMF (UEFI)-BIOS auswählt.

Meine VMs laufen alle mit dem „Default SeaBIOS”, und ich habe noch keinen Grund gefunden daas zu ändern. Die Hosts booten zwar mittlerweile mit Systemd Boot (UEFI), seit ich sie mal neu aufgesetzt habe. Secure Boot habe ich aber im BIOS deaktiviert. und ganz ehrlich, wenn ich Threads wie diesen oder auch sonstige Threads zu Linux und Secure Boot im Internet sehe, in denen Leute immer wieder Probleme damit haben, sehe ich auch da keinen Grund, warum ich das auf meinen privaten Geräten ändern sollte.

Wenn man seine Geräte professionell nutzt und vor allem, wenn man darauf Produkte des Marktführers einsetzen will oder muss, mag das Ganze wieder anders aussehen. ;)
 
Last edited:
Naja wenn man per Bootparameter das Laden unsignierter Kernel-Module unterbinden und selbst Kernel-Module signieren möchte, braucht man das halt, aber das ist halt auch ein eher exotischer Usecase. Ich frage mich halt gerade, ob bei aktivierten UEFI dann auch zwingend secureboot aktiv ist, wenn ich euch richtig verstehe, ist das bei Linux nicht der Fall, also alles safe
 
Ich frage mich halt gerade, ob bei aktivierten UEFI dann auch zwingend secureboot aktiv ist, wenn ich euch richtig verstehe, ist das bei Linux nicht der Fall, also alles safe
Meinst du auf dem Host oder in den VMs?

Beim Host hängt es meines Wissens davon ab, ob im BIOS/UEFI-Setup der Maschine Secure Boot aktiviert ist, wenn man von der Proxmox-ISO installiert. Vor ein paar Wochen habe ich zwei neue Mini-PCs gekauft und bei einer ersten Testinstallation ab ISO war Secure Boot auf dem Host aktiv. Zumindest stand da „Boot Mode EFI (Secure Boot) in der WebUI. Ich habe es dann deaktiviert und neu aufgesetzt und jetzt steht da nur noch „EFI”.

Wenn du VMs mit dem Wizard erstellst und das OVMF-(UEFI)-BIOS auswählst, ist, wie schon gesagt, dieser „Pre-Enroll Keys”-Haken standardmässig gesetzt. Ich gehe davon aus, dass damit dann quasi das Equivalent eines modernen physischen Hosts erstellt wird, der ja ebenfalls "pre-enrolled Keys” mitbringt. Ob Secure Boot dann wirklich aktiv ist und/oder ob man es trotz der „pre-enrolled Keys” noch irgendwo separat aktivieren/deaktivieren kann/muss, weiss ich nicht, denn wie gesagt, ich nutze mit allen VMs den Standard (SeaBIOS).
 
Last edited:
Windows aktualisiert nach dem installieren der neuen Zertifikate den Bootloader, dieser akzeptiert danach nur mehr die neuen 2023er Zertifikate.

Falls ihr nur einzelne VM's habt hier eine kurze Anleitung mit Registry Keys, ansonsten darunter dem Link folgen, da gibts Infos von MS wie man das via GPO erledigt.

Grundsätzlich sollte Windows Server auch ohne Secure Boot starten, wird soweit ich weiß nicht erzwungen wie bei Windows 11.
Bei MS steht Secure Boot / TPM wird nur für gewisse Features benötigt z.b. Secured Core.
 
Moin zusammen

Mit Euren Diskussionen hier habt Ihr es tatsächlich geschafft das ich jetzt den Überblick verloren habe was nun wirklich wann und wo bei welcher VM notwendig ist. :D

Ganz konkret: Bei mir gibt es lediglich 8 VMs, wovon 7 halt Linux VMs sind und in einer läuft eine Windows 11 VM. Bei 5 Linux VM wird Default (SeaBIOS) genutzt und bei der Windows VM und 2 Home Assistant VMs dann OVMF (UEFI) mit EFI-Disk.

Wenn ich das hier jetzt richtig verstanden habe sollte sich das UEFI-Zertifikate bei der Windows 11 VM automatisch aktualisieren und für die 2 Home Assistant wäre dann ein

Code:
qm enroll-efi-keys + passende ID

fällig. Wobei ich mich gerade auch noch frage ob das bei einer Home Assistant VM wirklich notwendig ist?
Bei dem 5 Linux VMs mit Default (SeaBIOS) brauche ich dann gar nichts zu machen. Ist das soweit korrekt, oder was genau muss ich dann wo machen?

VG Jim
 
Last edited:
  • Like
Reactions: Johannes S
Beim Host hängt es meines Wissens davon ab, ob im BIOS/UEFI-Setup der Maschine Secure Boot aktiviert ist, wenn man von der Proxmox-ISO installiert.
Ich reiche dazu noch mal eine Frage nach. :) Da ich jetzt nicht extra den Proxmox Host herunterfahren will, um dann im BIOS der Kiste nachzuschauen ob ich damals bei der Ersteinrichtung dort SecureBoot auf enable oder disabled eingestellt habe (ich meine es war aber disabled), gibt es bei Proxmox auch die Möglichkeit sich den BIOS-Status von SecureBoot anzeigen zu lassen?

Auf meiner Mint Kiste hier geht das ja per mokutil --sb-state, aber Proxmox gibt dann das "EFI variables are not supported on this system" aus. Würde dann das nachinstallieren von sudo apt install sbsigntool mokutil efitools zum Ziel führen, sprich das Proxmox mir dann den BIOS-Status von SecureBoot liefert? Oder wie kann ich bei Proxmox den BIOS-Status von SecureBoot abfragen?

VG Jim
 
Last edited:
gibt es bei Proxmox auch die Möglichkeit sich den BIOS-Status von SecureBoot anzeigen zu lassen?
Meinst du ob die Kiste mit SecureBoot läuft oder ob die Zertifikate schon im Bios hinterlegt sind?

Ersteres siehst du auf der Übersichtsseite, dort steht dann z.B. EFI (SecureBoot) oder eben nur EFI, wenn SecureBoot deaktiviert ist. Letzteres kannst du auf dem Host mit dmesg | grep cert prüfen.
 
Last edited: