[English]Ich greife erneut ein Thema hier im Blog auf, was noch ein Jahr Zeit hat, aber arg unangenehme Folgen haben dürfte. Im Juni 2026 laufen UEFI Secure Boot-Zertifikate ab. Im Oktober 2026 trifft es dann das nächste ablaufende UEFI-Zertifikat für den Secure Boot. Microsoft hat vorige Woche auf diesen Umstand hingewiesen und Administratoren aufgefordert zu reagieren.
Zum Thema der ablaufenden UEFI-Zertifikaten, die beim Secure Boot von Windows gebraucht werden, hatte ich mehrfach hier im Blog Artikel veröffentlicht (siehe Artikelende). Es ging da aber um einen Zertifikatsablauf im Oktober 2026. Aber bereits im Juni 2026 wird das Thema brisant. Denn Microsoft hat vorige Woche den Techcommunity-Beitrag Act now: Secure Boot certificates expire in June 2026 veröffentlicht, der auf ein weiteres Zertifikatablauf-Problem hinweist. Verschiedene Leser hatte mich per E-Mail auf dieses Thema oder auf den Beitrag hier hingewiesen (danke).
UEFI-Secure Boot-Zertifikat läuft im Juni 2026 ab
Im Beitrag weist Microsoft darauf hin, dass die Microsoft-Zertifikate, die in Secure Boot verwendet werden, alle im Juni 2026 ablaufen. Der Hintergrund ist, dass diese UEFI-Zertifikate vor 15 Jahren (für Windows 8-Maschinen) erstmals ausgestellt wurden.
Die Struktur der Secure Boot-Zertifikatskette verstehen
Das in Windows 8 eingeführte Secure Boot stellt über eine Vertrauenshierarchie, die auf Zertifikaten im UEFI basiert, sicher, dass beim Systemstart nur autorisierte Software ausgeführt wird. An erster Position dieser Kette steht der Plattformschlüssel (PK), der in der Regel vom OEM oder einem Beauftragten verwaltet wird und als Vertrauensbasis dient.
Der Plattformschlüssel (PK) autorisiert Aktualisierungen der Key Enrollment Key (KEK)-Datenbank, die wiederum Aktualisierungen von zwei kritischen Signaturdatenbanken autorisiert: die Allowed Signature Database (DB) und die Forbidden Signature Database (DBX).
Diese mehrschichtige Struktur stellt sicher, dass nur validierte Updates die Boot-Policy des Systems ändern können, um eine sichere Boot-Umgebung zu gewährleisten (siehe Aktualisieren von Secure Boot-Schlüsseln).
Ablaufende Zertifikate für Windows
Microsoft hat im Technet-Beitrag folgende Tabelle mit der Liste der ablaufenden Zertifikate veröffentlich. Es geht hier im Beitrag um die beiden Zertifikate Microsoft Corporation KEK CA 2011 und Microsoft Corporation UEFI CA 2011 (oder UEFI-Zertifikate von Drittanbietern, z.B. für Linux-Systeme), die beide im Juni 2026 ablaufen.
Diese ablaufenden Zertifikate werden durch die neuen Zertifikate Microsoft Corporation KEK 2K CA 2023 und Microsoft Corporation UEFI CA 2023 oder Microsoft Option ROM UEFI CA 2023 ersetzt.
Auf den Ablauf des Microsoft Windows Production PCA 2011-Zertifikats zum Oktober 2026 hatte ich in den Artikels am Beitragsende hingewiesen.
Welche Systeme sind betroffen?
Betroffen vom UEFI-Zertifikatsablauf sind sowohl physische als auch virtuelle Maschinen (VMs), auf denen eine unterstützte Version von Windows 10, Windows 11, Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012, Windows Server 2012 R2 läuft. Das sind alle Systeme, die seit 2012 veröffentlicht wurden. Diese schließt auch Systeme aus dem Long-Term Servicing Channel (LTSC) ein.
Nicht betroffen sind Systeme, die a) kein Secure Boot zur Absicherung des Windows-Starts verwenden und b) neue Systeme mit Copilot+PC aus 2025 – letztere haben bereits das neue UEFI-Zertifikat aus 2023.
Erinnerung: Es können auch Apple Macs betroffen sein, wenn Windows auf dieser Hardware per Bootcamp oder per Parallels virtualisiert installiert ist. Die Aktualisierung dieser Zertifikate wird durch Microsoft aber nicht unterstützt. Wer auf Bootcamp und Windows verzichtet, oder einen der Apple Macs mit Silicon-Chip (M1-M3) verwendet, ist ebenfalls nicht betroffen.
Was bedeutet der Zertifikatsablauf?
Mein erster Gedanke war, dass die Systeme beim Zertifikatsablauf Windows nicht mehr booten (siehe auch Frage: BlackLotus-Schwachstelle und ablaufendes UEFI-Zertifikat – was droht uns?). Allerdings tritt dieses Szenario nicht auf, die Systeme starten Windows weiterhin, wenn Secure Boot aktiviert ist. Ist Secure Boot deaktiviert und alles auf Legacy Boot umgestellt, juckt der Zertifikatsablauf nur indirekt (wird relevant, wenn man nach Juni 2026 im BIOS/UEFI wieder auf Secure Boot gehen möchte).
Es gibt aber ein größeres Problem: Sind diese CAs ablaufen, erhalten die Systeme keine Sicherheitsupdates mehr für den Windows Boot Manager und die Secure Boot-Komponenten. Systeme (egal ob physische Geräte oder virtuelle Maschinen), die auf Secure Boot angewiesen sind:
- Verlieren nach Juni 2026 die Möglichkeit, Secure Boot-Sicherheitsupdates zu installieren (relevant, falls Root-Kits, die neue Schwachstellen ausnutzen, bekannt werden).
- Können Software von Drittanbietern, die nach Juni 2026 mit neuen Zertifikaten signiert wurde, nicht mehr vertrauen.
- Erhalten bis Oktober 2026 (und danach) keine Sicherheitsupdates mehr für den Windows Boot Manager.
Abhilfe schafft nur, die betreffenden Systeme mit den oben genannten 2023er Secure Boot-Zertifikaten zu aktualisieren.
Microsoft holt in diesem Zusammenhang dann die Keule "Eine kompromittierte Sicherheit beim Start bedroht die Gesamtsicherheit der betroffenen Windows-Geräte, insbesondere aufgrund von Bootkit-Malware." hervor. Erwähnt wird dass ein solcher "ungesicherter" Boot-Ablauf auch heute noch vom BlackLotus UEFI-Bootkit (CVE-2023-24932) als Cyberangriffsvektor genutzt werden kann.
Was muss ich tun?
Wer sicherstellen will oder muss, dass die UEFI Secure Boot-Zertifikatskette auf die 2023er Zertifikate abgestimmt ist, muss sicherstellen, dass auf den Systemen die Zertifikate aktualisiert werden. Microsoft will (voraussichtlich) in den kommenden Monaten die aktualisierten Secure Boot-Zertifikate im Rahmen der monatlichen Patchdays per Windows Update ausrollen.
In diesem Kontext rät Microsoft Administratoren, bei den OEM-Anbietern nachzuschauen, ob neue BIOS/UEFI-Firmware-Updates vorhanden sind und diese einzuspielen, bevor die Zertifikate per Windows Update aktualisiert werden. Dürfte den letzten "Update-Problemen" geschuldet sein, sie die Blog-Beiträge Windows 10: Juni 2025-Update KB5060533 verursacht Surface Hub v1-Bootfehler und Vorsicht: Windows Juni 2025-Updates bricken Fujitsu-Rechner.
Aber auch der Versuch Microsofts, das im Oktober 2026 auslaufende Zertifikat über Windows Update zu aktualisieren, ist gründlich schief gegangen (siehe Frage: BlackLotus-Schwachstelle und ablaufendes UEFI-Zertifikat – was droht uns?). Von dieser Warte gesehen, dürften die kommenden Monate spannend werden, was den jeweiligen Patchday betrifft.
Redmond weist vorsorglich darauf hin, dass Microsoft-Support nur für unterstützte Client-Versionen von Windows 11 und Windows 10 verfügbar ist. Sobald Windows 10 im Oktober 2025 das Ende des Supports erreicht, sollten Administratoren überlegen, Extended Security Updates (ESU) für Windows 10, Version 22H2, zu beziehen, um ggf. weitere UEFI-Zertifikats-Updates zu beziehen.
Ähnliche Artikel:
BlackLotus UEFI-Bootkit überwindet Secure Boot in Windows 11
KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus)
Windows und das (BlackLotus) Secure Boot-Desaster: Wie ist bei euch der Status?
Update zur Windows-Härtung in 2024/2025 – Stand März 2024
Achtung: Microsofts UEFI Zertifikat läuft am 19. Okt. 2026 aus – Secure Boot betroffen
Frage: BlackLotus-Schwachstelle und ablaufendes UEFI-Zertifikat – was droht uns?
Windows 10: Juni 2025-Update KB5060533 verursacht Surface Hub v1-Bootfehler
Vorsicht: Windows Juni 2025-Updates bricken Fujitsu-Rechner
FAQ und Script zur Secure Boot-Absicherung gegen CVE-2023-24932 (Black Lotus)
MVP: 2013 – 2016
Es kommt mir schon etwas seltsam vor von Administratoren zu verlangen tätig zu werden und Microsoft hat seine Hausaufgaben selber nicht gemacht.
Klingt irgendwie verdächtig nach Henne – Ei Problem für mich…
Ich für meinen Teil warte eigentlich nur auf MS und die Info vom Hersteller des Deployment Systems.
Was soll ich jetzt ein Bootmedium aktualisieren, wenn ich es dann nicht mehr booten kann, weil das neue Zertifikat ja noch nicht im BIOS vorhanden ist…
Komische Fragestellung die du da hast. Als ich das Update manuell eingespielt habe war mir klar ich brauche jetzt neue ISOs oder ich schalte Secure Boot für die Installation kurz aus.
Was war nochmal dein Problem?
Ach ja. Ich ändere etwas im UEFI und ändere die ISO. Resultat: Es geht.
versus
Ich ändere nichts und nutze alte ISOs. Resultat: Es geht.
versus
Ich weiss von der Problematik und nutze neues UEFI + alte ISO + Secure Boot kurz aus. Resultat: Es geht.
Ja um was geht denn jetzt der Ärger, wenn doch alles geht? Man muss es einfach nur wissen!
Nachtrag:
Hatte schon viel Vorarbeit geleistet, aber es fehlt halt immer etwas:
Vorher:
https://i.imgur.com/vzZ2ymZ.png
Commands:
https://pastebin.com/UashLQLg
https://i.imgur.com/Xzu0ker.png
Nachher:
https://i.imgur.com/NMPlsXu.png
Danke an Anonym für das Script. Die REGs darinnen funktionieren nicht wirklich, musste die Commands oben selbst recherchieren in Esoterischen MS-KB-Dokus.
Grüße gehen raus an alle BC-Kumpels!
Natürlich gibt es noch die Methode "Psychopath" (gerade getestet):
1) Alle Keys im UEFI BIOS gekillt.
https://github.com/microsoft/secureboot_objects/releases/tag/v1.1.3
2) Alle DBs manuell von USB-Stick einspielen (die doppelten bitte mit append/anhängen).
3) Boot in Windows und aggressiv DB/DBX im NvRAM des UEFI updaten:
https://pastebin.com/ez3CvPPB
4) Option ROM geht jetzt auch.
Beweise:
https://i.postimg.cc/5tcPcW0V/image.png
Sollte man nur machen, wenn man weiss was genau diese Dinge tun!
(Es geht einfach so gut!)
Danke für die Info mit -> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x2 <- alles Grün in der TestNUC.
Seucreboot/Reset-Brechstange hat bei der Zweiten Maschine auch geholfen :)
Eröffnest du bitte einen PR mit deinen Optimierungen? Vielen Dank für deine Hinweise. :-)
Addendum 2:
Ging natürlich darum die Option ROM noch grün zu bekommen in der aktuelle DB reicht aus:
https://i.imgur.com/9sIyLsj.png
(leider geht das JS zu editieren der Posts bei mir nicht, sorry Günni)
https://github.com/cjee21/Check-UEFISecureBootVariables#viewing-all-the-uefi-secure-boot-variables
Kann man bei älteren Maschinen, die keine UEFI-Updates mehr vom Hersteller bekommen, die CAs im BIOS durch einen Mod auf den aktuellen Stand bringen?
Ist logischerweise kein gangbarer Weg für den Normal-Endanwender, aber es gibt ja eine lebhafte Bios-Modding-Szene und bei älteren Maschinen ist das außerdem noch einfacher zu machen.
Die Zertifikate sind unabhängig von UEFI-Updates. Kompatible Betriebssysteme verwenden ihre Updatefunktion um sie zu laden und ans UEFI zu übergeben. Dort wird auf Legitimität geprüft und danach in die entsprechende Variable geschrieben.
Eines sollte man sich noch bewusst sein: Ja, man kann KEK, DB und DBX unabhängig von UEFI Updates aktualisieren (auch z.B. unter Linux über fwupd), das ist auch OK so.
Leider gibt es ein relevantes "aber": Einige Hersteller schaffen es leider (bewusst?) nicht, dass diese Bereiche im NVRAM bei einem Update erhalten bleiben, sondern setzen diese bei einem UEFI-Update zurück.
Ich kann das im Moment auf bestimmten Consumerboards von Asrock aus der AM4-Generation bestätigen. KEK, DB und DBX werden dort immer zurückgesetzt und SecureBoot wird bei Updates auch deaktiviert. (was auch sinnvoll ist, denn ohne erhalt der Keys würde UEFI den Bootloader mit nicht als legitim erkennen.
Bei Businessgeräten beobachte ich das weniger (HP, Lenovo, Acer).
Wie das ein Endbenutzer hinkriegen will, frage ich mich ernsthaft.
was ich immer noch vermisse:
Was muss man beim WDS machen ?
Die UEFI Bootfiles sind dort ja auch signiert … (im Moment noch mit auslaufendem Zert)
Das ist kein Problem, einfach bootmgfw.efi und wdsmgfw.efi ersetzen (z. B. in RemoteInstall\Boot\x64). Habe ich wegen Black Lotus schon durchgespielt. Schwierigkeiten könnte nur bereiten, dass man immer nur eine Variante aktiv haben kann.
Aber erst, nachdem die Zertifikate auf den (allen) Zielsystemen verfügbar sind, oder?
Ja. Und wenn man alle Schritte des Black-Lotus-Fixes durch hat, ist ein WDS-Boot mit den alten Bootfiles auf dem Server nicht mehr möglich.
aber wo bekomme ich die wdsmgfw.efi mit neuem Zert her ?
Aus der boot.wim eines aktuellen (24H2)-Installationsmediums für Windows 11, Verzeichnisse Windows\Boot\EFI_EX und Windows\Boot\PXE_EX. Den _EX-Suffix der beiden Dateien dabei entfernen.
was will microsoft wie bei Servern aktualisieren, die auf vmware virtualisiert sind? wenn da nicht broadcom mit vmware eine generelle Lösung liefert wirds lustig. wo sind aktualisierte ISOs für Server 2016 und Server 2019 die dementsprechende Zerfitikate im Medium haben?
Glauben die wirklich jeder baut sich nun selbst seine eigenen Boot und Installationsmedien? Vor allem supported MS solche Eigenbau Installationen supporten?
Man hätte den ganzen Secure Boot müll einfach auch lassen können. Sicherheit erhöht sich ja sowieso keine dadurch. Es macht nur mehr schwierigkeiten.
Achja MS bekommt es ja nicht mal gebacken saubere Windows 11 24H2 Isos zu liefern. Installiert mal mit der Juni consumer ISO MVS MSDN Version ein Windows 11 und schaut mal ob ihr den print to pdf drucker drinnen habt. das Feature wird installiert, der Drucktreiber halt nicht.
siehe auch Windows 11 24H2 again missing PDF Printer -prnms009.inf (Clean install new builds) FIX HERE
VMen booten genauso über ein entsprechendes VM-UEFI, welches ganz normal von Betriebssystemen ein aktuelles Zertifikat zu Verfügung gestellt bekommen können. Aktuellere Installationsmedien werden nicht benötigt, bevor das Alte abläuft, weil beide im Speicher bleiben und natürlich wird die Sicherheit dadurch erhöht!
Mit den virtuellen Druckern scheint es aktuell Probleme zu geben, weshalb bei entsprechenden 23H2 Systemen wo diese installiert sind momentan auch das Upgrade auf 24H2 ausgesetzt ist.
Problem kann ich leider in meiner Umgebung bestätigen, trifft vereinzelt Computer, die auf Juni Patchlevel upgedated wurden, das ISO ist das Original RTM ISO.
Die Liste der Root Authority Certificates von Microsoft findet man hier:
https://www.microsoft.com/pkiops/Docs/Repository.htm
Für die neuen Zertifikate benötigt man keine neue Bootmedien. Das sind die selben Zertifikate, nur aktualisiert. Sie müssen vor Ablauf des KEK installiert sein. Wer bis dahin kein aktualisiertes KEK bekommt, muss an der Uhr drehen. Es sollte vermieden werden, dass sie mehrfach installiert werden.
Das was ich nur nicht verstehe wieso gibt es keine Boot Medien von MS die gleich das neue Zertifikat verwenden. Wenn ich eine aktuelle ISO 23H2 verwende, kann ich zwar mit dem Powershell Script die ISO anpassen. Die ISO verwendet dann selbst zum Boot das neue Zertifikat, das installierte Windows von der neuen ISO aber nicht, muss man wieder manuell machen über den Update flag in der Registry. Es geht ja nicht um die Sperrung des alten Zertifikat.
Wer die ISO mit dem neuen Bootmanager nutzt, der muss auch den Boot-Manager in der Install.esd aktualisieren.
Ja, verstanden wieso das Microsoft Powershell Script das nicht gleich mit macht, steht für nicht nicht im Artikel. Muss man wieder googeln. Ja das habe ich dann auch gefunden.
reicht das hier schon aus, um in 2026 kein böses erwachen zu haben?
Formal DB update steps
Apply the February 2024 (or later) security update.
Open a PowerShell console and ensure that PowerShell is running as an administrator before running the following commands:
Set the registry key to Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x40
Run the following scheduled task as Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Reboot the machine twice after running these commands to confirm that the machine is booting with the updated DB.
To verify that the Secure Boot DB update was successful, open a PowerShell console and ensure that PowerShell is running as an administrator before running the following command: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
If the command returns "True", the update was successful. In the case of errors while applying the DB update, please refer to the article, KB5016061: Addressing vulnerable and revoked Boot Managers.
https://techcommunity.microsoft.com/blog/windows-itpro-blog/updating-microsoft-secure-boot-keys/4055324
Hi, du musst zumindest die Stepp 1 und Stepp 2 machen.
1. Update DB Zertifikat damit Trust
Installieren Sie die aktualisierten Zertifikatdefinitionen in der Datenbank.
2. Update Boot Manager
Aktualisieren Sie den Start-Manager auf Ihrem Gerät.
https://support.microsoft.com/de-de/topic/verwalten-der-windows-start-manager-sperrungen-f%C3%BCr-%C3%A4nderungen-des-sicheren-starts-im-zusammenhang-mit-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_evaluate
Wenn Schritte 1-2 OK sind sollte auch folgender Key auf 2 Stehen:
https://support.microsoft.com/en-us/topic/enterprise-deployment-guidance-for-cve-2023-24932-88b8f034-20b7-4a45-80cb-c6049b0f9967#id0ebbj=validate
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\WindowsUEFICA2023Capable
0 – or key does not exist – "Windows UEFI CA 2023" certificate is not in the DB
1 – "Windows UEFI CA 2023" certificate is in the DB
2 – "Windows UEFI CA 2023" certificate is in the DB and the system is starting from the 2023 signed boot manager.
Die stellen sich Zertifikate für 15 Jahre aus. Na, wenn das mal sicher ist! Schließlich habe die vielen Zertifikat-"Profis" gerade beschlossen, selbst Server-Zertifikate nur noch für *47* Tage zu genehmigen.
Überhaupt ist dieses ganze Zertifikats-Geraffel reine Geldschneiderei, sozusagen: die Lizenz zum Gelddrucken. Ein Dukatenkacker sondergleichen!
Wenn ich dran denke, dass wir schon seit mehr als 15 Jahren eine eigene interne CA (openssl) betreiben, dann würde ich am liebsten eine Web-Startseite für unser Unternehmen einrichten und draufschreiben: "Vielen Dank, dass Sie uns besuchen, aber sie können unsere Dienste nur nutzen, wenn Sie unser Wurzelzertifikat abkzeptieren! Hier der Fingerprint: FA:E8…"
Guck bitte nochmal nach wie lange das E6 und ISRG Root X2 cert "leben". Nur weil die certs am boden der Pyramide kurz "leben" hat das nullinger mit den intermediären und wurzelcerts zu tun. Die werden immer extrem langlegbig bleiben.
Nur für den Fall, dass du das auf der Arbeit oder in der Öffentlichkeit sagst, könnte dir peinliche Blicke der Kollegen ersparen.
>>> Die stellen sich Zertifikate für 15 Jahre aus. Na, wenn das mal sicher ist!
Das sind zwei Paar Schuhe ganz unterschiedlicher Schuhgröße.
Wurzelzertifikate werden in aller Regel in einer besonders geschützten Umgebung erstellt und die zugehörigen Keys gerne auch offline gelagert.
Deren Verteilung muß ja auch besonders geschützt erfolgen, etwa als Bestandteil des Betriebssystems oder der Browser-Installation.
Diese Zertifikate erneuert man (vom Ablauf mal abgesehen) eigentlich nur im Rahmen der technischen Entwicklung, beispielsweise wenn die vor 15 Jahren verwendeten 1024 Bit Schlüssellänge oder der Signaturalgorithmus MD5 bzw. SHA1 nicht mehr als sicher angesehen wird.
Es gab zwar schon Fälle, in denen eine solche CA zurückgerufen wurde (etwa der plötzlich in Ungnade gefallene chinesische Signaturanbieter WoSign), aber das ist sehr selten.
Endbenutzerzertifikate haben ein ganz anderes Aufgabengebiet, sie Autorisieren einen bestimmten Zustand (etwa die Eigentümerschaft über eine bestimmte Domain oder die Existenz eines bestimmtes Unternehmens), die sich leider auch in kurzer Zeit ändern können. Deswegen machen dort kürzere Zeiten der Prüfung durchaus Sinn, im Verlauf der Diskussion wurden sogar 10 Tage für die Revalidierung erwogen.
Darf man als ganz normaler Nutzer darauf hoffen das im Juni nächstes Jahr der Schleppi noch geht oder ist er sicherheitstechnisch Schrott. Win11Pro aktuell.
Abgelaufene oder (natürlich versehentlich) fehlerhaft aktualisierte UEFI Zertifikate als Killswitch für ältere Hardware, sehe es schon kommen.
Nicht direkt so kommuniziert, etwas subtiler als "aus Sicherheitsgründen" oder "wegen böser Hacker" o.ä.
Die neuen "KI" bzw. "NPU" Chips wollen ja in neuen Geräten unter die Leute gebracht werden.
Windows 11 bootet auch mit abgelaufenem oder (natürlich versehentlich) beschädigten UEFI Zertifikat.
Ausser wenn es nicht mehr bootet.
Exakt, danke für deine Anmerkung. 👍
Nicht alles, was zu funktionieren scheint, wird immer weiter funktionieren. Diese Zeiten sind vorbei.
Wie sieht das für nicht IT-Leute wie mich zu Hause aus? Das sollte von Microsoft erledigt werden, wenn ich den Artikel richtig verstanden habe?
Für Admins und Consumer gilt wie immer: System aktuell halten. Das gilt auch für BIOS-Updates.
Danke! Der zweite Link ist viel hilfreicher, als die anderen Seiten die MS bereitstellt. Damit klappt es in 1 statt in 4 Schritten.
Ich habe heute mal geprüft ob, es ein UEFI Update für mein System gibt. Auf der ASUS Seite habe ich dann tatsächlich eins gefunden. Das UEFI heißt 8801 und ist für das Motherboard ROG Crosshair VI Hero freigegeben. Vorher war 8702 Installiert. Es behebt laut Beschreibung Sicherheitsanfälligkeiten. Es schließt die Sicherheitslücke "Sinkclose" die viele AMD CPUs bis zurück zum Jahr 2006 betrifft.
In meinem UEFI ist weiterhin das KEK Zertifikat von 2011 hinterlegt. Das Zeigt mir das Key Managment unter Details an.
Wo bekomme ich die aktuellen Zertifikate zum Download angeboten? Im UEFI gibt es eine Funktion, das die Zertifikate von einem lokalen Datenträger Installiert werden können.
Edit:
Mit UEFI 8801 wird das aktualisierte Zertifikat hinterlegt.
Hallo,
ich habe Schwierigkeiten bei einem HP Rechner die aktualisierten Zertifikate einzuspielen. Windows 10 ist auf neuestem Stand und Secureboot ist aktiv.
Hier habe ich die Dateien/Scripte geladen: https://github.com/cjee21/Check-UEFISecureBootVariables#viewing-all-the-uefi-secure-boot-variables
Ich kann aber die beiden Registry-Einträge fürs updaten der DB/DBX so oft setzen, lt. dem Script "Check UEFI KEK, DB and DBX.cmd" bleiben aber alle Dateien auf altem Stand nach Neustart :(
Kann gerne mal ein Bildschirmfoto von der Ausgabe verlinken.
Ergänzung: Wenn man in die Powershell das eingibt und mit Enter bestätigt:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
Kommt als Rückmeldung "False". An der Stelle komme ich also nicht weiter.
Quelle: https://support.microsoft.com/de-de/topic/verwalten-der-windows-start-manager-sperrungen-f%C3%BCr-%C3%A4nderungen-des-sicheren-starts-im-zusammenhang-mit-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_evaluate