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 ;)
 
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:
  • Like
Reactions: Johannes S
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