Im Beitrag Secure Boot-Zertifikatswechsel: Ein Playbook von Microsoft – Teil 1 hatte ich ja darauf hingewiesen, dass die Uhr für Windows-Systeme, die Secure Boot verwenden, bezüglich de Zertifikatsablaufs ab Juni 2026 tickt. Aber es gibt wohl Hürden beim Austausch der Zertifikate mittels Microsoft Updates. Hier einige Informationen zu diesem Thema.
2023 Secure Boot KEK-Update auf Hyper-V VMs
Das erste Problem im Zusammenhang mit dem Austausch der Secure Boot KEK-Einträge (Key Exchange Key, siehe) ist mir über nachfolgenden Tweet von Frank Lesniak untergekommen.
Frank Lesniak verweist auf den detaillierteren auf GitHub Post Missing PK-signed KEK for Hyper-V VM, Microsoft Hyper-V Firmware PK, with Serial, wo Gunnar Haslinger das Problem zusammen gefasst hat. Haslinger versucht, das 2023 KEK-Update in einer Microsoft Hyper-V-basierten VM zu installieren, erhält jedoch nur die Fehlermeldung EventID 1795. Dann hat er herausgefunden, dass der Platform Key (PK) seiner VM nicht von folgendem Paket abgedeckt ist:
"8058e8cc51749652804bbd6f39aed713d119c64b": {
"KEKUpdate": "Microsoft\\KEKUpdate_Microsoft_PK1.bin",
"Certificate": {
"serial_number": 171049019130091589582073331848314912,
"issued_to": "CN=Microsoft Hyper-V Firmware PK,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US",
"issued_by": "CN=Microsoft Corporation Third Party Marketplace PCA,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US"
}
},
Die VMs nutzen ein Zertifikat mit einer anderen Seriennummer. Er war nicht in der Lage, bei seinen Hyper-V VMs die Microsoft Updates mit KEK-Zertifikaten zu installieren. Doug Flick von Microsoft schrieb dann in dieser Antwort, dass HyperV noch keine KEK-Updates unterstützt. Dies werde jedoch in Kürze (geplant sei März 2026) der Fall sein und die KEK-Update-Datei müsse danach noch aktualisiert werden.
Ergänzung: Der Blog-Beitrag hier wurde vor Tagen auf Vorrat geschrieben. Bereits gestern wurde in Secure Boot-Zertifikatswechsel: Ein Playbook von Microsoft – Teil 1 die Frage "Was mache ich in einer virtualisierten Umgebung?" in diesem Kommentar aufgeworfen.
Leser Fritz schrieb in einem Folgekommentar, dass VMware ab der Version 8.2 bereits die neuen Zertifikate enthält. Proxmox unterstützt die neuen Zertifikate ab der Version 9.1.4 (genauer gesagt dem Paket pve-edk2-firmware ab Version 4.2025.05-1).
peter0815 merkte in diesem Folgekommentar ebenfalls an, dass ältere Hyper-V Clients derzeit noch nicht der neue Microsoft KEK 2023 hinzugefügt werden können. Das sei erst für ca. März 2026 von Microsoft angekündigt. Dann werde das Zertifikats-Update es aber automatisch ohne eigenes Zutun beim nächsten Starten der VM passieren.
Problem beim Austausch von Keys bei Dell-Systemen
In diesem Kommentar zum Artikel Windows 11 24H2 – 25H2: Probleme mit Preview Update KB5074105 (29.1.2026) erwähnt Blog-Leser Tibor Simandi Kallay, dass das betreffende Update auf manchen Rechnern nicht installiert werden kann. Das Update enthält m.W. auch Code, um die Secure Boot-Zertifikatsdateien auszutauschen.
Am Ende des Tages stellte sich laut diesem Kommentar heraus, dass der Austausch der Secure Boot-Zertifikatsdateien bei manchen Dell-Rechnern nicht per Windows Update funktioniert. Der Leser beschreibt einen Workaround, wie er das Update doch noch auf den betreffenden Maschinen installieren konnte.
Die Erklärung des Lesers für die Installationsprobleme beim oben genannten Update ist, dass Dell, im Gegensatz zu ASUS oder MSI, keine Updates der kritischen SecureBoot-Zertifikate über Windows Update lässt. Vielmehr bietet Dell für ihre modernen Systeme selbst ein aktualisiertes UEFI BIOS an.
Ältere Systeme werden dabei nicht mehr unterstützt. Und diese werden dann demnächst auch nicht mehr mit aktiviertem SecureBoot und TPM laufen, schrieb der Leser. Über diesen reddit.com-Tread bin ich darauf gestoßen, dass Dell den Support-Beitrag Microsoft 2011 Secure Boot Certificates Expiration for Out of Scope Platforms for BIOS Updates mit einer Liste der Systeme veröffentlicht hat, die bereits das neue Zertifikat haben oder aktualisiert werden können. Bei BIOS-Updates für neuere Modelle gibt Dell angeblich in der Beschreibung mit dem Satz "This BIOS contains the new 2023 Secure Boot Certificates," an, wenn das Zertifikat aktualisiert wird.
Und in diesem reddit.com-Thread lässt sich jemand über das Thema "Secure Boot KEK Configuration Update 2011-2023 Error" bei Lenovo-Geräten aus. Es geht dort um die BIOS-Updates, die unter Linux Fehler werfen. Im Thread werden Dell und HP ebenfalls als Problem-Kandidaten genannt. Zu einem bestimmten Update-Problem schreibe ich noch was.
Sieht mir so aus, als ob das Thema Secure Boot-Zertifikate uns noch eine Weile erhalten bleibt. Administratoren können bei Geräten, die per Auto-Patch verwaltet werden, im Intune Admin Center unter Berichte > Windows Autopatch > Windows-Qualitätsupdates nachsehen. Auf der Registerkarte Berichte wird der Status von Secure Boot der Geräte angezeigt (via).
Artikelreihe:
Secure Boot-Zertifikatswechsel: Ein Playbook von Microsoft – Teil 1
Secure Boot-Zertifikatswechsel: Es gibt Hürden beim Austausch – Teil 2
Ähnliche Artikel:
Microsofts UEFI Secure Boot-Zertifikat läuft im Juni 2026 ab
Achtung: Microsofts UEFI Zertifikat läuft am 19. Okt. 2026 aus – Secure Boot betroffen
Windows 10: Chaos beim Austausch neuer Secure Boot-Keys?
Windows Januar 2026 Update tauscht Secure Boot Zertifikate
FAQ und Script zur Secure Boot-Absicherung gegen CVE-2023-24932 (Black Lotus)
Windows und das (BlackLotus) Secure Boot-Desaster: Wie ist bei euch der Status?
KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus)
MVP: 2013 – 2016
Guten Morgen zusammen,
kleine Sidequest …
Habe hier ein Lenovo ThinkCenter M920z welches ich vorbereitend zum Austausch der Zertifiakte mit einem BIOS Update versehen will.
Das letzte Bios von Lenovo (M1MKT57A vom April 2024) verhindert, dass Windows 11 25h2 mit SecureBoot bootet – es läuft in einen Bootloop.
Im Bios muss man Secureboot ausschalten, damit man überhaupt wieder ins Windows kommt.
BIOS bzw. Einstellung der Bootreihenfogle erkennt die SSD, Boot Menü vom Bios dann nicht mehr(wenn SB an)
Weiß nicht, ob er sonst noch solche Probleme hat.
Schönes Wochenende
Ich plane noch einen weiteren Beitrag, möglicherweise hat dein Problem etwas mit dem Thema des Beitrags zu tun.
Ok super
Also InPlace-Upgrade hat nichts gebracht.
Fehler im UEFI wenn man SecureBoot wieder aktiviert: Secure Boot Violation – Invalid Signature detected. Check Secure Boot Policy in Setup
Abhilfe schaffte am Ende dann nur die Option "Reset platform to setup mode" – Einstellungen gespeichert – Reboot – ging.
die Meldung [Violation – Invalid Signature detected. Check Secure Boot Policy in Setup] kenne ich nur, wenn man das PCA2011 Zertifikat in der Sperrliste (dbx) drin hat und man vorher nicht alle Schritte für das UEFICA2023 Update erfolgreich abgeschlossen hat!
Durch das Zurücksetzen "Restore setup mode" & "restore Factory Keys" werden die korrekte Zertifikatsliste neu geladen..
bei solchen Problemen könnte man folgende Schritte durchführen:
• Secureboot deaktivieren
• Hochfahren unter Windows "Bios/UEFI Update" anstoßen
• Neustarten – Flash-Bios-Update zu Ende durchführen lassen
• Neustarten, im BIOS "Secureboot" wieder einschalten
• "Restore setup mode" & "restore Factory Keys" Durchführen
Anschließend checken ob durch das Bios/UEFI Update das neue Zertifikat geliefert wurde;
Checkliste:
PowerShell:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
Erwarteter Wert:
TRUE
PowerShell:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match "Microsoft Corporation KEK 2K CA 2023"
Erwarteter Eintrag:
TRUE
Registry:
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
Relevante Werte:
UEFICA2023Status = Updated
WindowsUEFICA2023Capable = 2
EventID
1799 –> Windows UEFI CA 2023 installiert
1808 –> Secure-Boot-Update abgeschlossen
Falls durch das UEFI/Bios Update das neue UEFICA2023 Zertifikat nicht geliefert wurde, folgende Schritte durchführen:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Warten bis der Wert von AvailableUpdates auf 0x4100 geändert wurde
Rechner Neustarten
ein zweites Mal:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" machen
10-15sek warten, Rechner Neustaten
oben die Bedingungen erneut Abfragen!
Das Abfragen der Zertifkatversion funktioniert nur, wenn Secure Boot aktiviert ist.
Hallo,
die Anleitung hat bei mir funktioniert. Vielen Dank dafür.
Die Anleitung und die Befehle sind richtig und funktionieren prima! Danke sehr!
vielen Dank – habs mal bei meinem Rechner getestet.
bis auf die event-ids ist alles vorhanden.
Wer Mainboard von Asus hat, hier ist einen Artikel dazu veröffentlicht:
Windows Secure Boot certificate expiration and certificates updates
https://www.asus.com/support/faq/1055903/
insbesondere zu "(Method II) Manually Update UEFI BIOS" ;)
Es gibt aber nicht für alle MB von Asus Updates, z.B. nicht für das N100I-D D4, das ist ein Mini-ITX.
MSI hat auch einen Beitrag dazu
https://www.msi.com/faq/faq-11305
Bezieht sich wohl nur auf Laptops, ist aber nicht besonders hilfreich – die verlassen sich bei älteren Modellen wohl auf Windows Update
Hallo,
die Problematik mit Hyper-V VMs und den fehlenden KEK Zertifikaten ist zwar richtig, es ist aber falsch zu behaupten, dass man hier nichts unternehmen könnte. Es gibt mehrere Workarounds, welche bei Administrator. de zu finden sind:
https://administrator.de/forum/uefi-secure-boot-zertifikate-windows-server-676429.html#comment-2390885
https://administrator.de/forum/uefi-secure-boot-zertifikate-windows-server-676429.html#comment-2391783
Zumindest der erste Workaround funktioniert(selber getestet). Der zweite Workaround scheint bei einem anderen User nicht funktioniert zu haben:
https://administrator.de/forum/secureboot-hyperv-vm-server-676582.html
Ich konnte bei uns aber auch beobachten, dass dies nur ältere VMs betrifft. Neue VMs – bei denen der Hosts schon etliche CUs installiert hatte – trat das Problem nicht auf und die KEK Zertifikate waren in der VM vorhanden.
Hier einfach nur warten und Tee trinken, halte ich für sehr blauäugig. Wir reden hier immer noch von Microsoft…
Ja, es gibt Möglichkeiten das virtuelle NVRAM der VM bei ausgeschalteter VM vom Host-System (Hypervisor) aus zu tauschen. Ist für einzelne VMs sicherlich eine interessante Option, ob man das aber im großen Stil so automatisieren und anwenden möchte ist eher fraglich, vor allem wenn die VMs nicht alle dem Admin des Hosts selbst gehören sondern unter andere Zuständigkeit fallen oder gar Kunden-VMs sind.
Es ist schon schlimm genug, dass wir hier regelmäßig die Meldung bekommen, dass die entsprechenden Zertifikate noch nicht im UEFI hinterlegt wären, obwohl die VMs noch mit BIOS laufen und entsprechenden die Updates gar nicht funktionieren können.
Da hat MS bei der Prüfung wieder ganze Arbeit geleistet.
Warum legen hier so viele Hand an? Windows Update regelt das doch automatisch. Einfach abwarten.
Naja, beispielsweise beim älteren Dell Precision T3620 geht das übers UEFI ganz einfach.
Da gibt es für jedes der 4 Zertifikate (PK, KEK, db, dbx) die Möglichkeit, das Zertifikat zu sichern, zu überschreiben, einen Key hinzuzufügen oder das ursprünglich ab Werk installierte Zertifikat wiederherzustellen.
Update der Zertifikate geht nur, wenn im UEFI "Custom Mode Key Management" aktiv ist.
Ist das nicht aktiv, sind die Zertifikate im UEFI schreibgeschützt.
> sichern, überschreiben, hinfügen
Über USB-Stick, oder wie muss ich mir das jetzt vorstellen?
Wo liegen diese neuen Keys denn in Dateiform vor? Denn zumindest diesen Custom Mode mit manuellem Key-Management konnte ich auch in meinem China-Mini-PC UEFI-BIOS finden und aktivieren.
Zitat:
"Wo liegen diese neuen Keys denn in Dateiform vor?"
—
Die Links zu den Downloads der Zertifikate findest du dort:
learn. microsoft. com/de-de/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11
Das Microsoft KEK 2K CA 2023 Zertifikat:
go. microsoft. com/fwlink/?linkid=2239775
"Windows UEFI CA 2023 kann von hier heruntergeladen werden:"
go. microsoft. com/fwlink/?linkid=2239776
"Microsoft Corporation UEFI CA 2023 kann von hier heruntergeladen werden:"
go. microsoft. com/fwlink/?linkid=2239872
"Microsoft Option ROM UEFI CA 2023 kann von hier heruntergeladen werden:"
go. microsoft. com/fwlink/?linkid=2284009
…und noch ein paar mehr.
Wir haben noch zuverlässige Optiplex 3020 im
Einsatz. Geht das da auch über den Custom Mode per USB – irgendwer Erfahrungen?
Dann noch die blöde Frage: einfach Zertifikate auf den USB laden und im bios einspielen oder wie genau geht das von statten?
Lt. Handbuch geht das.
Siehe: https://www.dell.com/support/manuals/de-de/optiplex-3020-desktop/OPT3020MTOM/system-setup-optionen?guid=guid-97fb9f99-ec04-4f53-b195-ee93d749b503&lang=de-de
Runter scrollen bis "Expert Key Management".
Einen Optiplex 3020 habe ich auch noch ausgemustert im Regal stehen (Baujahr 2014, i3-4150). Danke für die Erinnerung, ich habe den mal getestet.
Leider habe ich den Eindruck, Dell hat hier etwas verbockt. Wenn ich AvailableUpdates wie üblich auf 0x5944 setze, wird die "Windows UEFI CA 2023" für die db erfolgreich installiert. Aber: Dell hat offenbar kein KEK-Zertifikat bereitgestellt, was mit dem PK dieses PCs signiert ist. Jedenfalls findet Windows keines zu installieren und weigert sich in Folge auch, den Bootmanager umzustellen.
EDIT: habe noch mal nachgelesen, das soll wohl richtig so sein. Die "Windows UEFI CA 2023" kann zwar mit KEK 2011 installiert werden, aber zum Booten damit braucht man KEK 2023.
Der Weg über Custom Mode per USB hilft nicht so einfach weiter, weil auch dafür hast du kein KEK-Zertifikat, was mit dem PK signiert ist. Ob oder wie man einen PK selbst erstellen und "Microsoft Corporation KEK 2K CA 2023" damit signieren kann habe ich noch nicht eruiert.
Habe noch ein wenig weitergeforscht und war letztlich erfolgreich. Das ganze ist lächerlich einfach zu fixen, wenn man nur weiß, wie. Man muss nicht selbst signieren, denn unter anderem für solche Problemfälle hat Microsoft einen generischen PK erstellt, den man hier herunterladen kann:
https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/PK/Certificate/WindowsOEMDevicesPK.der
Und zu diesem PK kann man einen passend signierten KEK hier herunterladen:
https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/Microsoft/KEKUpdate_Microsoft_PK3d8660c0.bin
Eigentlich sollte man diese beiden Dateien über den Custom Mode im UEFI-Setup einspielen können. Leider wird der PK vom Optiplex 2030 nicht akzeptiert, man erhält die Fehlermeldung "Error replacing key. Please make sure that the new key is properly formatted with signature list and serialization headers."
Bestimmt kann man die .der-Datei passend umwandeln. Ich weiß zwar nicht wie, es war aber auch gar nicht nötig, denn im Custom Mode konnte ich die KEKUpdate_Microsoft_PK3d8660c0.bin auch ohne den passenden PK hochladen! Ob das ein Bug ist oder das absichtlich hier erlaubt wird, weiß ich nicht.
Bootet man dann Windows, wird vom Secure-Boot-Update-Task automatisch das db-Update installiert. Nach einem weiteren Reboot ersetzt der Secure-Boot-Update-Task auch noch den Windows-Bootmanager durch die neue Version, die nur mit Windows UEFI CA 2023 startet.
Nachahmung natürlich nur auf eigene Gefahr! Auf jeden Fall Backup machen und den Bitlocker-Wiederherstellungsschlüssel bereithalten. Aber in meinem Fall habe den hierfür nicht mal gebraucht.
Guten Morgen,
vielen Dank für die hilfreichen Tipps. Ich habe es genau so bei allen unseren Optiplex 3020 gemacht.
KEK runtergeladen auf USB (FAT32)
PC – Windows Updates 02/26
Booten
BIOS – SecureBoot in CustomMode
KEK anhängen, nicht ersetzen
Booten – Secure-Boot-Update-Task
(Ergebnis 1701)
Booten -Secure-Boot-Update-Task
(Ergebnis 1808)
Soweit in der Kurzzusammenfassung.
Vielleicht hilft es anderen weiter.
In dem Zusammenhang, BIOS Update Lenovo:
Es scheiterte bei mir mit einen komplett unspezifischen Fehler in dem Logfile, das das Update schreibt, pauschaler Fehler ohne Fehlermeldung, quasi "tuts nicht":
2026-01-14 22:40:19.781 Failed to update BIOS (102).
2026-01-14 22:40:19.783 [Flash Error] Write error during flashing.
2026-01-14 22:41:16.394 LenovoBiosUpdateTool shutting down
Lösung:
Das Update Tool kopiert das Bios Update in die EFI Partition und die ist ihm mit 100MB (Default Größe) zu klein.
Kann man das nicht als Fehler ordentlich reporten? Das macht mich echt wütend.
https://gist.github.com/peidaqi/8f7a8e57341a561797a872122b4ce094
Ich habe alle Sprachen ausser de-DE/en-* gelöscht. Es sind vielleicht 10MB gewonnen, die reichen aber.
Flash ging danach sofort ohne Fehler.
Alles funktioniert nur hp hat für nagelneue AIO Rechner (Bios vom 01.2026) noch keine neue DBX in Bios und immer noch ein 2017 Cert. Das ist ein echtes Problem, das auch MS nicht beheben kann, ich kann auch nichts ohne hp Support machen und ob und wann von dort was kommt ist fraglich.
-dito- same DBX hp Prob here..
Das Update für den sicheren Start konnte SBAT mit dem Fehler Unknown HResult Error code: 0x800700c1 nicht aktualisieren. Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2169931
Mein HP ProBook 430 G5 bekommt auch kein neues BIOS/UEFI-Update für die neuen Zertifikate (lt. HP-Support-Website), da Erscheinungsjahr der Modell-Serie 2017 ist. Aktuell ist das letzte bereitgestellte BIOS/UEFI-Update HP Q85 Ver. 01.31.00 vom 15.01.2025 installiert.
Somit ist das gutes Arbeitspferd mit Windows 11 Pro (Version 10.0.26200 Build 26200) bald nur noch Elektroschrott … Schade
Also ich würde eher Secure Boot ausschalten als ein funktionierendes Gerät wegzuwerfen.
100% Zustimmung. Es ist völlig absurd und auch entgegen jede überall gepredigte Nachhaltigkeit, gut funktionierende Hardware wegen irgendeiner Pseudosicherheit Funktion als Elektroschrott zu vernichten.
Traurig da ein G5 ein Win11 kompatiblen CPU hat, so wird selbst Hardware auf der Win11 offiziell läuft obsolet. HP hätte das Zertifikat auch schon lange zur Verfügung stellen können, selbst mit mit letzten BIOS Update das schon 1 Jahr alt ist.
DAS hat mir HP sogar per Email und am Telefon zugesichert!
Bis heute nichts. Wir werden NIE WIEDER HP Rechner anschaffen oder bei Kunden empfehlen. Das ist einfach Ignoranz und Geldschneiderei. Solche Händler brauchen wir nicht. Alle G5 Norebooks (80 Stück) sind betroffen. Bin richtig enttäuscht von dem ehemals guten Partner. Ich kann HP wirklich nicht mehr empfehlen.
"Elektroschrott" ist ein wenig dramatisch formuliert, oder?
Vorerst wird das Teil ja weiter funktionieren, du bekommst halt nur keine Updates für Secure Boot.
Und vor allem: bist du dir wirklich sicher, dass du unbedingt ein Firmwareupdate brauchst? Diese ganz neuen Updates von HP beinhalten eine Markierung, die Windows Update anweist, das Secure-Boot-Update automatisch zu machen. Das heißt aber nicht zwangsläufig im Umkehrschluss, dass es ohne diese Markierung nicht gehen würde! Mit diesem PowerShell-Befehl kannst du selbst die Freigabe setzen:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x5944
Ja, theoretisch gibt es die Möglichkeit, dass das schief geht und den Rechner brickt. Insbesondere bei HP ist da unter https://support.hp.com/us-en/document/ish_9642671-9641393-16?jumpid=in_r11839_us-en/PCSecureBootErr ein Problem dokumentiert. Aber das wurde schon im August 2023 behoben und deine Firmware ist von 2025. Außerdem ist dein ProBook 430 G5 gar nicht als betroffen aufgeführt. Ich selbst habe auch schon ein Asus-Mainboard, dessen neueste Firmware aus dem Jahr 2014 stammt, mit obigem Befehl erfolgreich auf die neuen Secure-Boot-Zertifikate umgestellt.
Also, bevor du das Ding sowieso wegwirfst weil du unbedingt ein aktives und aktuelles Secure Boot haben willst, sichere deine Daten und probiere die manuelle Umstellung. Entweder hast du dann wirklich Elektroschrott, oder es klappt und kannst den Rechner fröhlich weiterbenutzen inklusive aktuellem Secure Boot.
"Elektroschrott" ist ntürlich etwas übertrieben …
Die bekannten Vorgehensweisen (per PowerShell Skripte bzw. manuelles setzen von Reg-Schlüsseln und auf Windows Update hoffend) habe ich erfolglos durchgeführt. In der Ereignisanzeige erscheint u.a. der Eintrag, dass eine Aktualisierung nicht möglich ist, es ist ein bekannter Fehler für die HP -BIOS/UEFI Version aufgetreten und man/frau soll sich an den Hersteller wenden.
Also bleibt für den Fall, dass Windows 11 im Juni/Oktober 2026 nicht mehr richtig starten sollte: Datensicherung, Secure Boot aus, Debian oder Slackware installiert und gut …
Die Firmwareversion steht also auf einer expliziten Blacklist bei Microsoft. Das ist ärgerlich und kommt mir für eine Version vom Januar 2025 seltsam vor. Secure Boot ausschalten wirst du eigentlich nur müssen, wenn du irgendwann mal von einem zukünftigen Bootmedium starten willst, welches die neuen Zertifikate verlangt. Die jetzige Windows-Installation sollte auch nach Oktober 2026 mit Secure Boot starten, nur halt ohne Updates dafür.
Hier ist das HP ProBook 455 G7 am Start, bei dem ist das neueste Bios-Update installiert, hier wird folgendes angezeigt:
Current UEFI PK
√ HP UEFI Secure Boot PK 2017
Default UEFI PK
√ HP UEFI Secure Boot PK 2017
Current UEFI KEK
√Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)
√ HP UEFI Secure Boot KEK 2017 (revoked: False)
Default UEFI KEK
√ Microsoft Corporation KEK CA 2011 (revoked: False)
X Microsoft Corporation KEK 2K CA 2023
√ HP UEFI Secure Boot KEK 2017 (revoked: False)
Die HP-Zertifikate sind von 2017 bis 2033 gültig
und wurden wohl beim letzten BIOS-Update eingespielt.
Ob das so funktioniert werden wir sehen.
hp-pc
Windows-Auto-Update und sofort BSOD
IpICSHlpStopSharing : 0x80070032
Der Filter-Manager konnte keine Verbindung mit dem Volume herstellen.
Der letzte Status war "0xC03A001C".
Ereignis-ID 1801
Aktualisierte Zertifikate für den sicheren Start sind auf diesem Gerät verfügbar, wurden aber noch nicht auf die Firmware angewendet.
Lesen Sie den veröffentlichten Leitfaden, um das Update abzuschließen und den vollständigen Schutz aufrechtzuerhalten.
Diese Geräte-Signaturinformationen sind hier enthalten.
DeviceAttributes: hp FirmwareManufacturer:AMI;FirmwareVersion:F.26
Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet.
Der Fehlercode war: 0x00000154 (0xffffa10570508000, 0xffff970be96d6ff0, 0x0000000000000002, 0x0000000000000000).
Auf alle hp gelöst, thx an Deskmodder und besonders an DK2000
https://www.deskmodder.de/phpBB3/viewtopic.php?p=455476#p455476
Unserer Erfahrungen bisher (10 Server, 250 Clients): ich glaube Windows ist bei Laptops vorsichtiger, als bei Desktops..
Unsere Daten:
– HP Server (Proliant): Ist in den Bios-Updates enthalten
– HP Desktops: läuft meistens ohne Probleme mit aktueller Bios Version in allen Generationen
– HP Laptops:
->Generation 11: Sieht gut aus, der Rollout wurde vorbereitet (ist die Frage wann Windows-Update aktiv wird)
->Generation 10,8,7: Sieht trotz Bios-Version aus der HP-Liste nicht gut aus..
Schlüssel-Registry zum Monitoren: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\WindowsUEFICA2023Capable
HP-Informationen: https://support.hp.com/de-de/document/ish_13070353-13070429-16 Liste: "Required BIOS updates by release year of platform"
kurze frage:
Woran erkenn ich das ein PC aktuelle Zertifkate hat? Gibt es ein Tool mit dem ich das testen kann?
LG Jojo
Ich verwende folgendes PowerShell-Skript (mit Admininstratorrechten ausführen):
Write-Host "db 2023 installed:" ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
Write-Host "KEK 2023 installed:" ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023')
Start-Process -FilePath "C:\WINDOWS\System32\mountvol.exe" -ArgumentList "b: /s" -Wait
$certIssuer = (Get-PfxCertificate -FilePath "b:\EFI\Microsoft\Boot\bootmgfw.efi").Issuer
Start-Process -FilePath "C:\WINDOWS\System32\mountvol.exe" -ArgumentList "b: /d" -Wait
Write-Host "bootmgfw.efi signature:" ($certIssuer -match 'CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US')
"db 2023 installed" und "KEK 2023 installed" müssen beide True zurückgeben, dann sind die Zertifikate installiert.
"bootmgfw.efi signature" sagt dir, ob der Bootmanager noch mit dem alten (False) oder dem neuen (True) Zertifikat signiert ist.
"Boot-Zertifikatswechsel"
Ich lese das heute zum ersten Mal. Mein Notebook ist eins von Fujitsu. Erst im letzten Jahr habe ich ein Bios-Update eingespielt. Von Fujitsu gibt es dafür ein Programm "DeskUpdate". Ein Notebook von Asus aus 2022 habe ich auch noch. Mal schauen.
Die Frage mag für absolute Profis hier ein wenig off topic sein, jedoch:
Bei der ganzen Manipulation des UEFI BIOS via Windows Update u.s.w. kam mir die Frage, ob das nicht Tür und Tor öffnet für Manipulationen des UEFI BIOS von Hackern.
Alte PC´s hatten ein einfach gestricktes BIOS von AMI, AWARD o.a. und das konnte man eben NICHT via Windows verändern.
Nun in den modernen PC´s und Laptops können viele Prozesse munter im BIOS die Bootreihenfolge ändern, Zertifikate aktualisieren oder sperren und vieles mehr.
Ob das tatsächlich ein Sicherheitsgewinn ist wage ich zu bezweifeln.
Die Politik von DELL und einigen anderen Herstellern, eben gerade NICHT via Windows Update solche Zertifikate auszutauschen halte ich für die bessere Variante. Nur dann sollten diese Hersteller auch für ältere Geräte solche "BIOS Updates" bereitstellen. Schon allein um den EDV Schrott nicht unnötig anwachsen zu lassen.
Im Übrigen: die hier angesprochende Methode, via UEFI BIOS die SecureBoot Zertifikate selbst zu aktualisieren mag bei manchen Rechnern funktionieren. Jedoch scheint Dell bei den alten Optiplex Rechern ein anderes Format zu verwenden, was die Aktualisierung der Zertifikate unmöglich macht.
Wäre hier für einen funktionierenden Tipp echt dankbar.
Das BIOS (oder UEFI) ist nicht vollständig read-only, auch bei den alten Kisten nicht: Irgendwo müssen Einstellungen ja gespeichert werden.
Theoretisch bietet die Aktualisierung einen Angriffsvektor, halte das Risiko aber für sehr überschaubar. Die Sicherheitsmechanismen des BIOS sind bei modernen Geräten schließlich auch immer schwieriger zu überwinden und das viel größere Einfallstor bleibt das Betriebssystem selbst.
Die Aktualisierung per BIOS-Update wäre sicher schöner, macht aber viel mehr Arbeit und wird bei einem Großteil der Kunden garnicht ankommen. Da ist das Update von PK, KEK, DB und DBX via Windows das wesentlich kleinere Übel.
Bezüglich "alte Dell Optiplex"-Rechner lies mal weiter oben, was ich heute gepostet habe. Bei meinem Optiplex 3020 hat es gereicht, im UEFI-Setup die von Microsoft bereitgestellte Datei KEKUpdate_Microsoft_PK3d8660c0.bin zur KEK-Liste hinzuzufügen. Den Rest hat Windows automatisch erledigt.
Was deine "Hackerthese" angeht, würde ich massiv widersprechen, da ist das Gegenteil der Fall. Früher konntest du einfach mit einem DOS-Programm dein BIOS flashen, Sicherheit nahe null. Bei UEFI gibt es dagegen ein standardisiertes Interface zum OS (UpdateCapsule). Die Firmware flasht sich hier selbst neu, nachdem sie das übergebene Update verifiziert hat. Bei den Secure-Boot-Zertifikaten ist es ähnlich, das macht ja gerade dieses Zertifikatswechselthema für Microsoft so schwierig.
Am 29.Januar 2026 wurde das KB5074110 für Windows 11 24H2 und 25H2 veröffentlicht.
Auf den Computern, die bereits das Windows UEFI CA 2023-Zertifikat im UEFI haben, wird die 2011-zertifizierte Datei bootmgfw.efi durch die 2023-zertifizierte ersetzt.
Falls man aber das UEFI zurücksetzt und das neue Zertifikat nur als "Current", aber nicht auch als "Default" im UEFI installiert war, dann wird wieder das alte 2011-Default-Zertifikat zum neuen "Current" und dann bootet der neue Bootmanager nicht mehr, weil das 2011-Zertifikat nicht zur 2023-Signatur des neuen Bootloaders passt und Secure-Boot ist blockiert.
Microsoft empfiehlt für diesen Fall "das Wiederherstellungsmedium für den sicheren Start zu erstellen."
support. microsoft. com/de-de/topic/kb5074110-dynamisches-update-f%C3%BCr-windows-11-version-24h2-und-25h2-einrichten-29-januar-2026-7546f577-a103-458b-b910-9e8bca84b10b
Download aus dem Catalog:
catalog. update. microsoft. com/Search.aspx?q=KB5074110
Zusätzlich gab es auch noch das SafeOS-Update KB5074111.
DELL – Alienware m18 R2 – aktuell- ohne Maßnahmen – alles false
Nun nach obigen Maßnamen – alles true
check mit Posting " Damiel sagt: "6. Februar 2026 um 17:54 Uhr" PS Skript alles OK
Nur eines möchte ich noch anregen / fragen – wie schaut es aus mit den sog. "OS Recoverytools" mancher Hersteller, der auf der Platte mit einer "Wiederherstellungspartition" vorliegt ?
Danke an die "Gemeinde" :)
Interessant zu bemerken, das DELL inzwischen das hier im Beitrag erwähnte Dokument:
https://www.dell.com/support/kbdoc/en-us/000347876/microsoft-2011-secure-boot-certificate-expiration
gelöscht hat.
Zitat: "The chosen document is not currently available. Please try again later."
Ein Schelm, der Aerges dabei denkt! ;-)
Ergänzung: DELL hat lediglich den Link zu diesem Dokument geändert.
https://www.dell.com/support/kbdoc/en-us/000378734/microsoft-2011-secure-boot-certificates-expiration-for-out-of-scope-platforms-for-bios-updates?lang=en
Hab den Link korrigiert, danke.
Eine Anmerkung zu Dell: Ja, da steht der Hinweis in aktuellen BIOS Releasenotes. Aber Achtung: Es gibt zwei Arten von Zertifikatsspeichern: 1. Read-only vendor und 2. Produktion.
Der 2. Store konnte bei meinem Test auf einem Dell NB mit aktuellem BIOS problemlos über Windows aktualisiert werden.
Der 1. Store ist das Backup für das Zurücksetzen von BIOS/Zertifikatsliste im BIOS. Und der kann nur vom Hersteller per FW-Update aktualisiert werden. Und genau darauf bezieht sich der Hinweis in den Releasenotes von Dell.
Zusammengefasst: Wer glaubt er habt mit einem bloßen BIOS Update alles aktualisiert der Irrt gewaltig.
Demnach machen Powershell-Skripte zum Auslesen nur dann Sinn, wenn Sie auch die *Default stores abfragen.
Falls Windows in VMware- oder Proxmox-Umgebungen den neuen KEK nicht schreiben kann, unter dem Kommentar von Fritz:
https://borncity.com/blog/2026/02/05/secure-boot-zertifikatswechsel-huerden-und-ein-playbook/#comment-246371
mit den Links zu den Anleitungen für VMware und Proxmox habe ich noch Lösungen ergänzt die bei uns funktioniert haben.