Update von Secure-Boot-Zertifikaten auf (älteren) Geräten ohne Windows Update

[__Seraph_]

Hallo zusammen,

ich hoffe, ich poste das in den richtigen Bereich. Vor ca. 1 Monat hatte ich starke Probleme mit ständigen Freezes nach 5 min. Ursache war der Task Secure-Boot-Update, über den Windows versucht, automatisiert die 2023 auslaufenden Secure Boot Zertifikate auf die 2023-Versionen upzudaten (im Detail: siehe mein Beitrag hier). Nach nun ungefähr 1 Monat und stundenlangem Testen allen möglichen Anleitungen habe ich tatsächlich einen Weg gefunden, wie man die Updates doch installiert bekommt. Wesentlich einfacher wäre das alles, wenn Hersteller für ältere Systeme auch ein Bios-Update bereitstellen, da der Weg über Windows oft nicht funktioniert. Leider ist das aber nicht so.

Hinweis: Ich bin kein IT-Experte und ich war mir bewusst, dass das auch nach hinten losgehen kann. Dennoch will ich nachfolgende Infos nicht für mich behalten, sondern teilen. Wer es nachmacht oder teilweise versucht: Auf eigenes Risiko und eigene Gefahr. Ich kann nicht versichern, dass das überall funktioniert.

Der einzige Workaround, um diesem Freeze sinnvoll zu entkommen, war bislang a) Secure Boot deaktivieren oder b) den Task in der Aufgabenplanung deaktivieren. Da ich aber keine Lösung für sinnvoll hielt und meinen PC nicht zu Elektroschrott machen wollte, habe ich recherchiert. Ja, der PC ist alt, aber für mich reicht er noch vollkommen. Hier noch die wichtigsten Systeminfos:

Modell: Medion Akoya P5378I (über die Jahre allerdings stark modifiziert)

CPU: Intel i7-6600

GPU: AMD Radeon RX6500 XT OC

RAM: 2x 16 GB DDR4-2133

Mainboard: Medion H110H4-EM v1.05

OS: Windows 10 22H2 (für ESU registriert)

Ich versuche es möglichst detailliert zu beschreiben, sodass andere mit demselben Problem ggf. selbst abwägen können, was sie tun wollen/können oder nicht. Für einige Begrifflichkeiten und Funktionen würde ich gerne auf das Internet oder Gemini verweisen. Ja, am Ende hat mir die KI dabei geholfen, das Problem zu lösen, auch wenn es ein sehr mühsamer Weg mit etlichen Fails war.

Am Ende hing der Windows-Update-Prozess am Fertigstellen der Aktualisierung der Secure-Boot-Variablen im NVRAM des Mainboards. Insgesamt gibt es 4 neue Zertifikate, die dafür sorgen, dass Windows nach Ablauf der 2011-Zertifikate in 2026 mit Secure Boot hochfährt. Wenn hier eine Verletzung der Validierung stattfindet, bekommt man bei aktivem Secure Boot einen roten Bildschirm "Secure Boot Violation" und kann in diesem Zustand grundlegend erst mal nicht booten. Die 4 Zertifikate sind in verschiedenen Datenbanken abgelegt. Insgesamt gibt es:

• PK (Platform Key)
• KEK (Key Exchange Key)
• db (eine Art Whitelist für Zertifikate)
• dbx (Revocation List, eine Art Blacklist für ungültige Zertifikate, die geblockt werden).

Das Ganze folgt nach meiner Info einer sog. Root of Trust, d.h. der PK steht über allem und wird i.d.R. vom Hersteller (OEM) verwaltet. Er autorisiert Änderungen am KEK. Der KEK wiederum überwacht die Änderungen an db und dbx. Dazwischen gibt es alle möglichen Ausprägungen und es funktioniert auch nicht immer alles nach Lehrbuch, insbesondere bei abgespeckten oder modifizierten OEM-UEFI-Versionen.

Im Internet findet ihr etliche Anleitungen, wie man den Zustand des Updates prüfen kann. Am einfachsten ist die Nutzung von Skripten, die man auf GitHub finden kann. Alternativ kann man sich das auch in der Registry ansehen. Dafür dem Pfad Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing folgen.

Zertifikatsübersicht

Ihr braucht folgende Zertifikate, damit das System komplett auf neuem Stand ist. Es sind grundsätzlich nicht alle unbedingt nötig, das hängt aber davon ab, welche Hard- und Software ihr habt. Daher habe ich da nicht groß geschaut und versucht, alles auf Stand zu bringen.

• Microsoft Corporation KEK 2K CA 2023 (KEK)
• Windows UEFI CA 2023 (db)
• Microsoft UEFI CA 2023 (db)
• Microsoft Option ROM UEFI CA 2023 (db)

Wichtig ist, dass das mindestens in der sog. Current-Database enthalten ist. In den Default-Databases nicht zwingend, denn die werden nur mit einem richtigen Bios-Update aktualisiert und stellen dann auch die Werkseinstellung dar. Bei älteren Geräten wird hier vermutlich immer nur die 2011-Version stehen bleiben. Das muss man auch bei einem Reset wissen, die 2023-Zertifikate sind dann nämlich erst mal weg.

Fehlerursache

Warum schlägt das Update überhaupt fehl? In der Theorie sollte das bei den meisten Geräten alles klappen. Ich konnte bei meinem Medion-Motherboard feststellen, dass es einfach nicht dieselben Spielregeln hatte. Eine Ursache wäre gewesen, dass schlichtweg der Speicherchip des Bios voll ist. Er ist für heutige Verhältnisse sehr klein, bspw. 8 MB. Darauf muss alles Platz haben. Für jede Funktion ist ein Bereich definiert. Wenn voll, dann voll. Gerade die dbx-Updates werden vergleichsweise groß und beinhalten hunderte Einträge. Gerade da scheitert es bei älteren Geräten oft. Da es letztlich geklappt hat, ist es das doch nicht gewesen.

Bei dem H110H4-EM war es schlichtweg, dass das UEFI keine Schreibvorgänge, die von Windows aus initiiert wurden, zuließ oder zumindest die Befehle nicht verarbeiten konnte. Ergebnis: Der Update-Task sendet ein To Do aus und das UEFI meldet sich nicht. Der PC friert ein oder quittiert den Dienst, weil man in geschützte Bereiche reinschreiben will. So zumindest meine Theorie.

Werkzeuge und Tools

Auch hier vorab: Nur mit Windows-Bordmitteln kommt man zu nichts. Man braucht grundlegend nur Software, sollte sich für den Ernstfall, aber auch geeignete Hardware aneignen. Ich möchte nicht zu weit ausholen, wer tiefer einsteigen will kann die KI fragen, die gibt relativ gut Auskunft und unterstützt auch beim Finden dieser Sachen. Ich habe am Ende nicht alles benötigt, aber es hat mir beim Weg dorthin geholfen:

• oben genannte GitHub-Skripte zur Kontrolle des Erfolgs, alternativ das Modul UEFIv2 via PowerShell installieren, sodass man damit die Variablen auslesen kann.
• IntelCSTools (auch auf GitHub zu finden). Das sind ziemlich mächtige Tools, um direkt auf Firmware-Ebene einzugreifen. Für jede Generation an CPUs braucht es eine andere Version, für Generation 6 Skylake braucht man die Tools in der v11. Darin relevant dann eigentlich nur das Flash Programming Tool, für 64-Bit-Systeme unter WIN64.
• USB-Stick, FAT32-formatiert
• ein Hex-Editor wie HxD sowie das Tool UEFITool NE A73 schaden nicht. Damit kann man sich Bios-Files und Zertifikats-Dateien (teilweise) ansehen, um ein wenig besser zu verstehen, was da genau passiert. Für die finale Lösung ist es nicht unbedingt nötig.
• Auch das Tool AMIBCP von American Megatrends Inc. (Bios-Software) ist nützlich, aber man braucht es nicht unbedingt. Damit könnte man sein Bios-File modifizieren. Ich hatte zunächst gedacht, durch Freischalten versteckter Menüs für das Key-Management komme ich zum Ziel, war aber glaub auf dem Holzweg.
• Ein CH341-Programmer. Den gibt es billig als China-Ware für 10 Euro oder auch professionell für hunderte Euro. Das ist eine Programming-Hardware mit USB-Anschluss. Damit kann man mittels einer Klemme oder durch Auslöten des Bios-Chips sowohl enthaltene Daten darauf lesen oder schreiben. Sowas habe ich mir gekauft, falls ich was zerschieße und mein PC nicht mehr startet. Da man dann keine Benutzeroberflächen mehr hat, bleibt einem nur das Flashen des Chips mit einem Programmer. Das ist also eher ein Backup. Man muss sich dazu dann im Internet eine passende Software sowie den fürs System geeigneten Treiber suchen, bspw. NeoProgrammer. Wenn alles klappt, braucht man das Teil nicht. Man kann mit dem o.g. auch ein Backup erstellen Flash Programming Tool (nur wenn der Chip nicht teils gesperrt ist, sonst hilft nur ein Auslesen mit der Hardware). Wenn man sich einen solchen Programmer holt, dann sind diese oft falsch geschaltet. Bios-Chips laufen entweder mit 3,3 V oder 1,8 V. In meinem Fall 3,3 V. Der Programmer stellt das auch grundlegend bereit, aber nicht an allen 8 Pins. Daher sollte man den Programmer modifizieren, dass auf allen relevanten Leiterbahnen 3,3 V anliegen. Ansonsten besteht die Gefahr, den Chip zu zerstören. Anleitungen gibt es im Netz genug.
• KeyTool.efi Das ist eine Art Programm, welches man noch vor Windows direkt im Bios ausführt. Es ist ein sehr wirksames Werkzeug, um Variablen direkt in den NVRAM zu schreiben. Das wird am Ende auch die Software sein, die das Update ermöglicht. Hier muss man aber ewig suchen, bis man das findet. Man muss es im .efi-Format haben und dann auf dem USB-Stick einen Ordner EFI, Unterordner BOOT anlegen. Da rein muss dann KeyTool.efi, wobei man es in BOOTX64.efi umbenennen muss, damit es gefunden wird. Startet man den PC, muss man schnell F8 drücken, bis man ins Bootmenü kommt. Dann wählt man nicht den Windows Boot Manager, sondern den Stick und man startet das Tool. Gefunden habe ich das mithilfe von KI aus einem Debian-Paket. Es hieß efitols_1.9.2.-3_amd64.deb.
• Shell.efi Das ist eigentlich eine Art cmd auf Bios-Basis. Ich habe es am Ende nicht gebraucht. Damit könnte man auch direkt auslesen und schreiben. Auch das findet man nur auf Umwegen, ich weiß gar nicht mehr genau, wo ich es her habe. Ich meine aus einem Linux-Paket.

Vorbereitung

Um für etwaige Ausfälle bestmöglich gerüstet zu sein, habe ich folgendes gemacht. Jeder muss selbst entscheiden, was er tun will.

• Einen Klon meiner SSD, damit ich im Falle eines Windows-Fehlers nur die Festplatte tauschen muss und dann bin ich wieder auf Stand vorher. Das kann man bspw. mit Macrium Reflect machen.
• Ein Backup vom Bios-Chip. Falls irgendwas schiefläuft, kann man damit 1:1 Byte für Byte auf den Chip zurückschreiben und das System sollte wieder booten. Das gilt nur für Software-Fehler. Zerstört man die Hardware, müsste man einen neuen Chip einlöten. Für das Backup kann man entweder das Intel Flash Programming Tool verwenden oder mit dem CH341-Programmer direkt auslesen. Wichtig dabei: Für ein Backup braucht man immer einen sog. Full-Dump, d.h. alles. Wer mittels Software nur das Bios sichert, hat bei einem Brick keinen wirklichen Vorteil. Muss man doch mit dem Programmer den Chip neu beschreiben, so wird i.d.R. zunächst alles gelöscht und dann beschrieben. Dann wäre nur das Bios-File auf dem Chip und das geht nicht. Jedes Byte muss an der vorgesehenen Stelle sein. Erstaunlicherweise hat Medion in dem Board keinen Schutz verbaut, sodass man es mit dem komplett Flash Programming Tool auslesen kann. Der Full-Dump hatte bei mir dann 8.192 KB, das isoliete Bios-File hätte nur 6.148 KB. Das muss man unbedingt vorher prüfen, sonst muss man es über den Programmer direkt am Chip auslesen. Das Bios-File allein ist eigentlich nur für Bios-Mods sinnvoll.
• Ein Export der aktuellen Secure-Boot-Variablen (PK, KEK, db und dbx). Das kann man direkt im Bios über "Export Keys" machen, wenn man Secure Boot in den Custom Mode umstellt oder man nutzt KeyTool.efi. Letzteres hat den Vorteil, dass man sowohl eine gesamte Zertifikatsliste als auch die einzelnen Zertifikate sichern könnte. Wichtig: Solange Secure Boot noch aktiv ist bzw. die Keys gesetzt sind, bringt der Export allein noch nicht viel. Der ist für die Modifikation später aber hilfreich.
• WSL (Windows Subsystem for Linux) Ehrlicherweise weiß ich gar nicht genau was das ist. Ich verstehe darunter eine unter Windows lauffähige Oberfläche, über die man Linux-Distributionen (bei mir Ubuntu) bzw. deren Befehle, die es bei Windows nicht gibt, in einer Art cmd-Kommandofenster nutzen kann. Am Ende ging es nur damit. Die KI führte mich aber gut durch die Installation. Das Ganze wird über PowerShell angestoßen.
• Sonstige Sicherungen, die einem wichtig erscheinen.

Gescheiterte Lösungsansätze

Um allen unnötige Ansätze zu ersparen, teile ich euch meine Erfahrungen. Ich bin seit Anfang März 2026 bis gestern nahezu täglich nach der Arbeit am PC gesessen und habe Lösungen gesucht, die auch ein "normaler User" bewerkstelligen kann. Am Ende ging es aber nicht und ich musste mich technisch weiterbilden: Learning by doing.

• Egal wie man es direkt über Windows machen will, es klappt nicht. Es ist kein direkter Zugriff auf die Variablen im UEFI möglich.
• Restore Factory Keys im Bios ist auch nicht zielführend. Damit löscht man die Current-Database und setzt alle Variablen zurück. Man kann dann zwar den Update-Vorgang neu starten, aber es kommt wieder zum Freeze. Es wurden bei mir nur 2 Zertifikate installiert, der Rest geht nicht. Warum? Weil es 2 db-Zertifikate waren, die über den KEK 2011 legitimiert wurden, ab dann ging nichts mehr.
• Am Ende muss man versuchen, die Keys manuell zu importieren. Zwischenfazit: Man braucht gewisse Tools dafür, alles andere erscheint unsinnig. Nicht, dass es nicht geht, es ist schlichtweg zu fehleranfällig.
• Ich habe mittels KeyTool.efi zunächst versucht, einzelne Keys hinzuzufügen. Das führte zu mehreren Problemen.
  • Die Funktion "Add Keys" gibt es zwar, wird vom Medion-Board aber nicht zugelassen.
  • Wenn man mithilfe von KI und einem Hex-Editor mehrere Zertifikate/Keys zusammenführen will, geht das zwar technisch führt aber zu folgenden Fehlern: Es ist das falsche Format, es fehlen gewisse Header (Security Violation beim Import), die Bytes passen nicht (Alignment führ zu Invalid Parameter) oder man schafft es irgendwie mehrere Zertifikate in einer Datei unterzubringen, aber das Bios erkennt das dann nur als 1 riesiges Zertifikat, weil in der Datei keine saubere Trennung drin ist.
  • Falls es bei jemandem klappt: Solange Secure Boot Variablen noch gesetzt sind, d.h. der PK ist aktiv, können Änderungen auch mit KeyTool.efi nur mit sog. .auth-Dateien erfolgen (zumindest bei mir war das so). Das sind Dateien, die über eine digitale Signatur verfügen. Da man dafür aber den Private Key von Medion bräuchte (KEK wird vom PK bewacht), kann man das vergessen.
  • Im Allgemeinen klappte bei mir ohnehin nur die Einspielung der Keys mit einer Zertifikatsliste, einer sog .esl-Datei (EFI_SIGNATURE_LIST). Sie führt alle notwendigen Zertifikate in einer Datei. Die .esl ist auch das, was man beim Export der Keys als Backup bekommt, wenn man alles gesammelt exportiert. Die Medion-Programmierung des Bios ließ bei mir keine Einzelbefehle zu. "Addend Key" oder "Add Key" ist wirkungslos und mündete immer in einem Fehler.

Lösung

Hier versuche ich euch zu schildern, was ich gemacht habe, weil alle anderen Wege nicht geklappt haben.

1. Alle Tools, Backups etc. vorbereiten.
2. Ins Bios booten und dort unter Security den Seucre Boot Mode auf Custom umstellen, dann ins Key Management gehen und dort die Funktion Default Key Provisioning (?) auf Disabled stellen. Ein paar Zeilen weiter unten muss dann anstelle der Funktion Restore Keys to Factory Settings die Funktion Clear all Keys kommen. Man muss das tun. Nur wenn alle Variablen inkl. PK gelöscht werden, gelangt das System in den sog. Setup-Mode. Warum ist das wichtig? Für die Platzierung von db, dbx und KEK sind dann keine signierten .auth-Dateien mehr nötig, sondern das Bios frisst auch die unsignierten .esl-Dateien. Wenn man den PK stehen lässt, muss man die Root of Trust einhalten und das wird einem nicht ohne Weiteres gelingen, weil man keine private keys der OEM hat. Daher hatte Windows den OEMs die Zertifikate geschickt, um sie zu signieren. Das wurde gesammelt und hätte über Windows Update ausgesteuert werden sollen. Auf GitHub findet man sogar für meinen Medion-PC signierte KEK-Update-Pakete als .auth, aber es ging dennoch nicht.
3. Ich habe dann von unten nach oben angefangen. 
4. Die dbx habe ich 1:1 als .esl wieder eingespielt. Da braucht man nichts modifizieren.
5. Der db-Export als .esl enthielt ja nur die 2011er Zertifikate bzw. bei mir 2 von 3 2023er Zertifikaten, die über Windows Update bereits geschrieben werden konnten. Mir fehlte nur noch das Microsoft UEFI CA 2023. Das habe ich von Microsoft als .crt-Datei heruntergeladen (eigentlich für was anderes vorgesehen). Das Problem nun: Wie füge ich dieses Zertifikat einer EFI_SIGNATURE_LIST hinzu, damit alle Bytes und Header passen? Das konnte ich nur über die Befehle aus WSL umsetzen. Da hat mich Gemini sehr gut durchgeführt. Man nimmt die exportierte .esl und erstellt aus der heruntergeladenen .crt zunächst eine .pem-Datei, damit das Zertifikat sicher umgewandelt wird (direkt ging bei mir nicht und verursachte Import-Fehler im Bios). Danach wurde die .pem in eine .esl umgewandelt. Dabei wird mit dem Befehlssatz cert-to-efi-sig-list unter Verwendung der Microsoft-GUID 77fa9abd-0359-4d32-bd60-28f4e78f784b als Signaturinhaber genutzt. Sodann muss mit einem Befehl die alte .esl und die einzelne .esl fusioniert werden. Das geht aber nur mit den WSL-Befehlen vernünftig. Die dann erhaltene neue .esl kann dann als eine Datei in die db importiert werden. Es geht bei diesem Board immer nur 1 Vorgang über "Replace key/s".
6. Beim KEK war das eigentlich dasselbe. Ich habe den 2023 KEK der .esl des Exports angefügt und alles über WSL unter Verwendung der Microsoft GUID zu einer neuen .esl zusammenführen lassen.
7. Der Knackpunkt ist dann der PK. Solange der nicht sitzt, ist das System im Setup Mode. Sobald ein PK gesetzt wird, ist die Datenbank wieder zu und man kann nicht mehr mit .esl-Importen arbeiten. Der PK wacht sozusagen über alles. Das Problem ist nur, dass KeyTool.efi in meinem Fall auch im Setup Mode keine .esl als PK zuließ, sondern nur eine .auth. Da ich aber von Medion nicht den private key habe, konnte ich pk.esl nicht signieren, um daraus eine .auth zu machen. Man hat nun 2 Möglichkeiten. Man generiert sich mit WSL und openssl-Befehlen ein eigenes Zertifikat und nutzt den Microsoft Standard PK WindowsOEMDevicesPK oder man erstellt sich selbst eine eigene Signatur. Ich habe mich für letzteres entschieden, weil ich nicht weiß, ob im Mainboard dann irgendwo das Medion-PK bei Firmware-Checks erwartet wird. Man generiert sich einen eigenen private key mit RSA-2048-Verschlüsselung und bekommt dazu auch ein öffentliches Zertifikat mit dem public key. Als Inhaber kann man dafür einen beliebigen Namen nehmen, ich habe meinen eigenen Nachnamen genommen. Das wird auch später nicht in der Abfrage der Secure-Boot-Variablen auftauchen. Es geht nur darum, dem Bios zu signalisieren, dieser Medion-PK wurde von einer übergeordneten Stelle signiert und für ok befunden. Nur in dem Fall bin ich nicht Medion, sondern signiere meinen eigenen PK. Das frisst das Bios dann und in dem Moment ist Secure Boot dicht und man kann es wieder aktivieren.
8. Am Ende kann man dann die Checks machen und es sollte alles gesetzt sein.

 Ausblick

Damit bin ich prinzipiell durch. In der Registry stehen natürlich die ganzen Fehler noch drin und dass der Prozess "in Progress" steht, weil ich alles direkt im UEFI gemacht habe und Windows nichts mitbekommt. Ich belasse es auch erst mal dabei. Ob ich dann ggf. in der Registry die Werte mal lösche und den DWORD-Wert auf 0x4000 setze, damit Windows denkt, es passt alles, werde ich noch entscheiden.

Wichtig ist nun, dass man sich seine ganzen .esl-Listen sowie den selbst generierten Schlüssel für die PK-Signatur gut sichert. Warum? Wenn künftig wieder ein KEK-Update nötig wäre (wenn auch unwahrscheinlich), wird das nicht mehr gehen. Da ich den PK nun mit meinem Key signiert habe, ist die Medion-Signatur wertlos. Ich muss also künftig selbst signieren, um es einzuspielen. db und dbx sollten nicht betroffen sein, da sie über KEK bewacht werden und der ist ja nun gesetzt.

Theoretisch müsste nun im Laufe der Zeit per Windows Update der Bootmanager auch auf 2023 signiert werden. Das dürfte Windows automatisch merken, dass die Zertifikate vorhanden sind. Ab dann können 2011er Bootloader nicht mehr verwendet werden. Also sollte man dann auch seinen bootfähigen Stick etc. aktualisieren oder einen zweiten erstellen. Dann hat man beide Bootloader-Varianten noch drin.

Am Schluss nicht den Fehler von mir machen: Nach alldem hatte ich Secure Boot Violations beim Booten und kam nicht weiter. Das lag aber daran, dass ich den Stick mit KeyTool.efi noch im PC stecken hatte. Da das nicht signiert ist, kommt es zur Secure-Boot-Verletzung. Ich habe mich ewig zu Tode gesucht.

Am Ende hat es alles geklappt und hat mich, wenn auch nebenher, 4 Wochen meiner Lebenszeit gekostet. Aber damit wäre bewiesen, dass es auch Anfänger hinbekommen können und dass es doch einen Weg gibt, die Sicherheit aufrecht zu erhalten.

Grüße,

__Seraph_

[Andi · Accepted solution]

Hallo @__Seraph_ und Hut ab für diesen Bericht.

Gruß - Andi

[__Seraph_]

Hallo @Andi.

Vielen Dank. 😎 Vielleicht hilft es ja jemandem.

Und in dem Zuge kann ich gleich noch einen kleinen Fehler eingangs korrigieren: Die verbaute CPU ist ein i7-6700.

Grüße,

__Seraph_