Im Juni 2026 laufen UEFI Secure Boot-Zertifikate für Windows ab. Im Oktober 2026 trifft es dann das nächste ablaufende UEFI-Zertifikat für den Secure Boot. Microsoft versucht seit geraumer Zeit, diese Secure Boot-Zertifikat im UEFI auszutauschen. In einem Beitrag im Windows-Blog hat Microsoft sich zum 10. Februar 2026 darüber ausgelassen, was bei abgelaufenen Zertifikaten passiert.
Ablaufende UEFI Secure Boot-Zertifikate
Die vor 15 Jahren erstmals (für Windows 8-Maschinen) ausgestellten und im UEFI von Geräten ausgerollten Secure Boot-Zertifikate laufen im Juni 2026 ab. Microsoft hat im Techcommunity-Beitrag Act now: Secure Boot certificates expire in June 2026 folgende Tabelle mit der Liste der ablaufenden Zertifikate veröffentlicht.
Seit Jahren versucht Microsoft diese ablaufenden Zertifikate mittels Updates zu aktualisieren – aber mit mäßigem Erfolg. Fehlgeschlagene Installationen oder nicht mehr bootende Systeme waren die Folge. Bei manchen Mainboards muss das UEFI vom Hersteller aktualisiert werden, bei anderen kann es per Windows Update erfolgen.
Microsoft hat in den Supportdokumenten zu den Windows Sicherheitsupdates für Windows vom 13. Januar 2026, z.B. für KB5074109 für Windows 11 24H2-25H2, erneut an die in diesem Jahr ablaufenden UEFI-Zertifikate erinnert. Im Januar und Februar 2026 hat Microsoft die nächste Welle an Secure Boot-Zertifikats-Updates gestartet. Im Februar 2026 sollen die aktualisierten Zertifikate breiter ausgerollt werden, nachdem im Januar eine erste Welle für "kompatible Maschinen" bereitgestellt wurde.
Und es rumpelt an allen Ecken und Enden. Zum 3. Februar 2026 ist mir obiger Post auf X von Microsofts Mitarbeiterin ariaupdated untergekommen. Der verweist auf den Microsoft-Beitrag Secure Boot status report in Windows Autopatch und kündigt an, dass Secure Boot Status-Reports in Windows Autopatch verfügbar seien. Ich habe beim Schreiben des Beitrags mal kurz auf die Seite geschaut und folgende Botschaft gefunden.
Important
The Secure Boot status report is temporarily unavailable in Windows Autopatch. This documentation remains published for reference and will be updated when the report becomes available.
Die Halbwertszeit für solche Ankündigungen sinken spürbar, ich tippe auf Probleme – und der Einwurf von MVP Rudy Ooms signalisiert dies ebenfalls.
Was passiert im Juni 2026 bei veralteten Zertifikaten?
Zum 10. Februar 2026 hat Microsoft den Beitrag Refreshing the root of trust: industry collaboration on Secure Boot certificate updates im Windows-Blog veröffentlicht. Dort wird nochmals erwähnt, dass das 2011 vorgestellte Secure Boot eine grundlegende Sicherheitsfunktion von Windows und Windows Server sei, die bereits ab dem Einschalten des Geräts greift. Es trage dazu bei, dass nur vertrauenswürdige, digital signierte Software ausgeführt werden kann. Durch das Blockieren von nicht vertrauenswürdigem Code in der frühesten Phase des Startvorgangs hilft Secure Boot dabei, sich gegen komplexe Bedrohungen zu schützen, die später nur schwer zu erkennen sind, schreibt Microsoft.
Aber was ist, wenn das ablaufende Secure Boot-Zertifikat im UEFI nicht aktualisiert werden kann oder vom Benutzer nicht aktualisiert wird? Bleibt der Rechner nach dem Einschalten mit einer Warnung stehen? Für meine Wenigkeit und viele Leser und Leserinnen war unklar, was genau passiert. Vermutung war: Es passiert nichts, die Systeme booten weiterhin, auch wenn das Secure Boot-Zertifikat abgelaufen ist.
Genau das stellt Microsoft jetzt klar: Hat ein Gerät die neuen Secure Boot-Zertifikate nicht vor Ablauf der 2011-Zertifikate erhalten, passiert nichts. Das System funktioniert weiterhin normal, bootet und die vorhandene Software läuft weiter. Aber es gibt eine Einschränkung:
- Das Gerät wechselt laut Microsoft in einen eingeschränkten Sicherheitszustand, der seine Fähigkeit zum Empfang künftiger Schutzmaßnahmen auf Boot-Ebene einschränkt.
- Im Laufe der Zeit könne dies auch zu Kompatibilitätsproblemen führen, da neuere Betriebssysteme, Firmware, Hardware oder Secure Boot-abhängige Software möglicherweise nicht mehr geladen werden können.
Nun ja, so mancher Nutzer hat Secure Boot auf seinen Rechnern deaktiviert – bei Linux muss man sich derzeit auch keine Gedanken um Secure Boot-Zertifikate machen. Und Windows 10-Systeme werden auch mit Secure Boot ohne Zertifikatsupdates weiter laufen. Lediglich neue Windows-Versionen werden möglicherweise auf solchen Maschinen Probleme bereiten. Wobei ich das eher als "theoretische" Möglichkeit sehe, denn neue Windows 11-Versionen werden eh immer mehr Hardware-Anforderungen stellen, so dass ein Secure Boot-Zertifikat das geringere Übel darstellt. Und neuere Geräte sollten bereits mit den 2023er Secure Boot-Zertifikaten ausgeliefert werden. Weitere Details sind im Microsoft-Beitrag Refreshing the root of trust: industry collaboration on Secure Boot certificate updates nachzulesen.
Ä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
Frage: BlackLotus-Schwachstelle und ablaufendes UEFI-Zertifikat – was droht uns?
Windows 10/11 KB5053484: Neues PS-Script für Zertifikate in Boot-Medien
Windows 10: Chaos beim Austausch neuer Secure Boot-Keys?
FAQ und Script zur Secure Boot-Absicherung gegen CVE-2023-24932 (Black Lotus)
Windows Januar 2026 Update tauscht Secure Boot Zertifikat
MVP: 2013 – 2016
Von einem seriösen Lieferanten würde man ja erwarten, dass er ein Programm (oder Äpp) bereitstellt, das der normale Benutzer einfach starten kann und welches den Status der betreffenden Zertifikate anzeigt (grün=OK, rot=Handlungsbedarf).
Als besonderen Luxus könnte so ein Programm dann sogar anbieten, nicht aktuelle Zertifikate direkt auszutauschen.
Ich weiß, ich bin ein Träumer …
Träumer in der Tat! Vergleiche doch mal "whynotwin11" von einem Drittanbieter (schnelle, klare, einfache Auflistung, warum auf einem PC kein Win11 läuft – in einer simplen .exe ohne Installation) mit der "Lösung", die MS dafür angeboten hat. Einfach und clever kann man dort nicht, macht sich statt dessen vermutlich ewig Gedanken über die "User experience".
Die Statusanzeige ist laut dem oben verlinkten Microsoft-Blogpost in Arbeit: "In the coming months, messages about the certificate update status will be available in the Windows Security App to help consumers track the certificate updates more closely". Ja, es wäre besser, wenn diese Anzeige längst schon da wäre.
Die Funktion zum Austauschen nicht aktueller Zertifikate gibt es schon. Auf hinreichend getesteten Systemen macht sie das ganz automatisch. Auf anderen Systemen kann man sie nur mit einem Registry-Eintrag triggern. Das ist nicht sehr komfortabel, aufgrund der denkbaren Risiken aber verständlich.
und genau so funktioniert es auf Crome OS Flex, unter "Firmware Updates". die drei updates einen nach einander anclicken, und fertig!
Mein einer Rechner hat mit den Februarupdates die Zertifikate aktualisiert bekommen. Asus-Board 650 irgendwas für AMD. Nach dem BIOS Update Stand 12/25 waren die noch nicht da.
Ein kleines Prüftool wäre aber schon schön, das die Powershell-Funktion etwas einrahmt
Gibt es Infos zu virtuellen Maschinen? Wer kümmert sich da?
so als Einstieg:
if(!(Get-Module -ListAvailable -Name 'UEFIv2')){
Install-Module 'UEFIv2' -scope CurrentUser -Force -Confirm:$false
}
Import-Module -Name UEFIv2
und dann schauen ob die neuen verfügbar sind:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
Ergebnis ist true oder false, wenn noch nichts da ist. Ich hatte noch diesen Registry-Eintrag gemacht:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f
Das Hyper-V Team will im März ein Update veröffentlichen wo die Zertifikate für 2023 eingebaut werden.
https://github[.]com/microsoft/secureboot_objects/issues/318
Wir ignorieren das Thema erstmal und warten ab. Mit Einschränkungen rechnen wir nicht.
Ich verweise mal auf die Deskmodder-Seite – dort wird von einem Script gesprochen, mit dem man den Status der Zertifikate prüfen können soll:
httpx://www.deskmodder.de/blog/2026/02/10/was-passiert-wenn-die-secure-boot-zertifikate-unter-windows-11-und-windows-10-ablaufen/
Wenn sich die Zertifikate so einfach austauschen lassen, dann müsste das auch für Malware möglich sein.
Und darüber kann dann die ganze Secure Boot Funktion ausgehebelt werden.
Um das zu verhindern müssten die Zertifikate schreibgeschütz sein und sich nur per BIOS-Update austauschen lassen.
Wobei man die Zertifikate gar nicht austauschen müsste, wenn die gleich eine entsprechend lange Laufzeit hätten.
Z.B. anstatt 15 Jahre 30 Jahre.
| Wobei man die Zertifikate gar nicht austauschen müsste, wenn die gleich eine
| entsprechend lange Laufzeit hätten.
Das ist ein Trugschluss. Das würde nur funktionieren, wenn beim Rechnererwerb jeweils ein neues 30 Jahre gültiges Zertifikat erzeugt und installiert wird. Wird ein Rechner aber ~ 18 Monate vor Ablauf des aktuell noch gültigen Zertifikats gekauft, muss dieses halt innerhalb der nächsten 18 Monate ausgetauscht werden, wenn man die Funktionalität darüber hinaus nutzen möchte.
Das ist ein Trugschluss:
Heutige Rechner halten gar nicht so lange. Mein PC ist mit Baujahr 2011 (i7-2600) schon ein Methusalem, aber 30 Jahre Nutzungsdauer wage ich zu bezweifeln …
Wobei das nicht zwangsläufig am Versagen der Hardware liegt, sondern an den Einsatzzwecken, die von Jahr zu Jahr immer höhere Leistung einfordern. Selbst das Surfen im WWW lässt 10 Jahre alte CPUs doch arg ins Schwitzen kommen, es sei denn, sie fielen beim Kauf in oder in die Nähe der High-End-Kategorie. Dann geht da durchaus noch was.
Mein 15 Jahre altes ALDI-Laptop, neu ~500 €, also weit weg von High-End, funktioniert wunderbar im Web, Surfen, Streamen (als Zuspieler für den alten FHD-Fernseher) etc. Es wurde nur eine kleine SSD für ~20 € nachgerüstet, da die mechanische System-Platte wirklich übel lahm war.
OS: Windows 11 Home (allerdings ohne SecureBoot)
das Zertifikat müsste natürlich auf lange bevor es abläuft für neue Geräte ausgetauscht werden, z.B.: 10 Jahre vor Ablauf.
Ob nun 15 Jahre gültig, 30 Jahre gültig oder unbegrenzt gültig macht sicherheitsmäśig ohnehin praktisch keinen Unterschied. Also wieso überhaupt die blöde Idee, hier ein Ablaufdatum einzubauen?
Stimmt deswegen werden wir ja in wenigen Jahren dann mit Zertifikaten beglückt, die eine Gültigkeit von 47 Tagen haben. Das wird auf so manchem Nostalgie Service so richtig lustig werden da eine Automatisierung hinzubekommen
Die Zertifikate lassen sich eben NICHT "so einfach" austauschen, sonst hätten wir ja das ganze Theater nicht. Das Austauschen im laufenden System (durch das OS oder Malware) bedingt, dass die Zertifikate selbst mit geheimen Schlüsseln signiert sind, die nur Microsoft bzw. der Hardwarehersteller (PK) besitzt. Gleiches gilt für ein Firmwareupdate aus dem laufenden System heraus.
Die Laufzeit von Zertifikaten ist immer ein Kompromiss. Von der Sicherheit her will man eine möglichst kurze, von der Bequemlichkeit eine möglichst lange.
Und es ist ja auch noch nie vorgekommen, dass Zertifikate kompromittiert wurden. Schon gar nicht Root-Zertifikate, und erst recht nicht bei Microsoft.
Äh, Moment, das war doch was…
For those who want to update Certs on the Firmware level but leave Windows untouched a short guide.
=============================================================
SECURE BOOT KEK/DB/DBX ENROLLMENT — LINUX LIVE GUIDE
=============================================================
SAFETY NOTES:
– Boot in UEFI mode with Secure Boot ENABLED in BIOS
– This updates your UEFI firmware NVRAM — Windows OS is untouched
– Existing keys are preserved unless you explicitly remove them
– Manual download URLs are official Microsoft sources
– If a dry-run lists keys for removal, use the manual add-only path
————————————————————-
1. Boot Linux Live (Fedora or Mint)
————————————————————-
# Fedora:
# Boot Fedora Live USB in UEFI mode → "Try Fedora"
sudo -i
# Linux Mint:
# Boot Mint Live USB in UEFI mode → "Try Linux Mint"
sudo -i
————————————————————-
2. Install sbctl
————————————————————-
# Fedora:
dnf update -y
dnf install sbctl -y
# Linux Mint / Ubuntu:
apt update
apt install git make gcc -y
git clone https://github.com/f-secure-foundry/sbctl.git
cd sbctl
make
make install
————————————————————-
3. Optional: Export current firmware keys (backup)
————————————————————-
mkdir /tmp/secureboot_backup
sbctl export-keys –directory /tmp/secureboot_backup
# Saves PK.cer, KEK.cer, DB.cer, DBX.cer
————————————————————-
4. Inspect current Secure Boot state
————————————————————-
sbctl status
# Records existing key hashes/sizes for comparison
————————————————————-
5. DRY-RUN: simulate automatic enrollment
————————————————————-
sbctl enroll-keys –microsoft –dry-run
Check the output:
– Keys listed under "To be added:" should include:
* Microsoft Corporation KEK 2K CA 2023
* Windows UEFI CA 2023
* (Optionally) Microsoft UEFI CA 2023
– There should be no unexpected keys under "To be removed:"
– If no removals and adds look correct, it is safe to proceed
– If any existing critical keys are going to be removed, stop and use manual add-only path
————————————————————-
6. PATH A — Automatic (if dry-run looks clean)
————————————————————-
sbctl enroll-keys –microsoft
# Downloads latest Microsoft keys and enrolls them
————————————————————-
7. PATH B — Manual add-only (if dry-run shows removals)
————————————————————-
7.1 Download certificates manually:
– Microsoft KEK 2K CA 2023 (KEK):
https://go.microsoft.com/fwlink/?linkid=2239775
– Windows UEFI CA 2023 (DB):
https://go.microsoft.com/fwlink/?LinkId=2239776
– Microsoft UEFI CA 2023 (DB):
https://go.microsoft.com/fwlink/?linkid=2239872
– Microsoft Option ROM UEFI CA 2023 (DB):
https://go.microsoft.com/fwlink/?linkid=2284009
# Save these files into /tmp/ms_keys/
7.2 Dry-run manual add
sbctl enroll-keys –manual /tmp/ms_keys –dry-run
# Verify no removals appear in output
7.3 Apply manual add-only
sbctl enroll-keys –manual /tmp/ms_keys
————————————————————-
8. Verify enrollment
————————————————————-
sbctl status
# KEK, DB, DBX should show new 2023 cert hashes
# Old keys still present
————————————————————-
9. Reboot back to Windows
————————————————————-
– Remove Live USB
– Boot normally
– Optional PowerShell verification:
Confirm-SecureBootUEFI → True
Get-SecureBootUEFI -Name KEK
Get-SecureBootUEFI -Name db
Get-SecureBootUEFI -Name dbx
————————————————————-
Relevant Official Information
————————————————————-
– Microsoft guidance on Secure Boot certificate expiry and new 2023 CAs:
https://support.microsoft.com/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e
– Microsoft Secure Boot certificate binaries repository:
https://github.com/microsoft/secureboot_objects/releases
– Microsoft KEK/CA download links:
KEK 2K CA 2023: https://go.microsoft.com/fwlink/?linkid=2239775
Windows UEFI CA 2023: https://go.microsoft.com/fwlink/?LinkId=2239776
Microsoft UEFI CA 2023: https://go.microsoft.com/fwlink/?linkid=2239872
Microsoft Option ROM UEFI CA 2023: https://go.microsoft.com/fwlink/?linkid=2284009
————————————————————-
Safety Recap
————————————————————-
– Dry-run first and inspect output
– Use manual add-only if removals are flagged
– Export existing keys as a backup
– No cleanup needed — keys persist across reboots
– Updates firmware only; Windows remains untouched
=============================================================
Danke :-)
Das seht ja fast so einfach aus wie die kursierenden Powershell-Lösungen :-D
Mal sehen, welche Methode mein Schwiegervater bevorzugen wird.
Ich las mal (finde den Link gerade nicht, kann ihn aber, wenn gewünscht, nachreichen), das man nach solchen Verrenkungen sein UEFI nicht mehr updaten kann, sollte es vom Boardhersteller später noch Updates geben. Daher wäre so etwas eher für "end of life/out-of-support"-Hardware geeignet. Stimmt das?
@Dino:
Please TEST such installation scripts before presenting it here online!
Why? The installation of sbctl here:
git clone https://github.com/f-secure-foundry/sbctl.git
does not work because this user has stopped the project.
THANK YOU for NOTHING!
Ich habe DualBoot Systeme mit Linux Mint 20.3, basierend auf Ubuntu 20.04. Für diese Version gibt es aber leider keine lauffähige sbctl Version. Hab es dann versucht, lief auch (zusätzliche Bibliotheken …) aber dann ging es trotzdem nicht. Nur Ärger aber keine Lösung!
Und für die DELL Systeme mit gesperrtem UEFI klappt das sowieso nicht. Wie man Optiplex Systeme in den Setup Mode bringt finde ich auch nirgendwo. Key´s resetten schon probiert.
Lösung: secure boot einfach abschalten.
>Lösung: secure boot einfach abschalten.
>
Wozu? Nur temporär, für den irrsinnigen Fall, dass man sich ausgesperrt hat (FAT32 EFI fälschlicherweise vor der DB aktualisiert) kann man problemlos ein Downgrade des Bootloaders nach CA 2011 machen.
Danach spielt man das DB update über den 0x40 er Regkey ein und startet den Update-Task, bis das System spurtet (braucht mehrere Versuche, (!) SecureBoot muss davor wieder an sein (!).
Beweis:
*https://i.postimg.cc/3RGGjPLV/downgrade-recovery.png
Danach kann man das Upgrade erneut versuchen, wie ich ganz weit unten beschrieben habe. Wie gesagt, bitte einfach Geduld besitzen, wenn Windows den Regkey und Task erst nach dem 6x Reboot oder 6x Upgrade-Anstoß zum DB update ausführt.
Ich will ja glauben, man kann jedes System recovern. Ja die DB updates über Windows nativ gehen auch sehr gut! Nur nicht sofort, wenn man ungeduldig ist.
—
GB: Danke, dass Du den Stern * vor das https gesetzt hast. Dein letzter Kommentar wurde offenbar durch meine Anti-SPAM-Filter nach Freigabe komplett ausgeblendet. Erst als ich die Links mit *https deaktiviert habe, erschien der Kommentar nach Freigabe.
Ich würde etwas widersprechen, dass man sich bei Linux keine Gedanken machen muss. Wenn man eine Distribution wie Ubuntu oder Fedora nutzt, bieten diese einen von Microsoft signierten shim loader, der derzeit von der "Microsoft UEFI CA 2011" signiert ist. Man kann also prinzipiell mit meist vorinstallierten Standardzertifikaten Secure Boot aktiv haben.
Wenn diese Distributionen aber mal einen neuen shim loader verteilen müssen, der dann wieder von Microsoft signiert ist, wird (nach meinem Verständnis) dieser von der neuen "Microsoft UEFI CA 2023" signiert sein, da die alte CA ausläuft.
Vertraut das UEFI dieser CA noch nicht, wird es da auch Probleme geben, bzw. man muss Secure Boot dann abschalten, damit das OS doch starten kann.
Du hast insofern Recht, wenn man bei Linux auf Secure Boot setzt. Ich habe auf meinem Mint-Notebook Secure Boot im UEFI deaktiviert, um ggf. mit Virtualbox arbeiten zu können.
Die aktuellen Versionen von Virtualbox arbeiten problemlos mit Secure Boot, sowohl im Host wie auch im Guest. Zumindest bei mir (Host Mint 21.3 und Windows 10, Guest Windows 11).
Das verstehe ich nicht:
Zitat 1:
"Hat ein Gerät die neuen Secure Boot-Zertifikate nicht vor Ablauf der 2011-Zertifikate erhalten, passiert nichts. Das System funktioniert weiterhin normal, bootet und die vorhandene Software läuft weiter."
—
Sobald die 2011-Zertifikate abgelaufen sind und es die 2023-Zertifikate im UEFI nicht gibt, dann verweigert die Secure-Boot-Funktion im UEFI das Starten des Bootloaders.
Würde es trotzdem funktionieren, dann wäre Secure-Boot völlig sinnlos.
Zitat 2:
"Das Gerät wechselt laut Microsoft in einen eingeschränkten Sicherheitszustand"
—
Ist das eine Umschreibung dafür, dass Secure-Boot einfach abgeschaltet wird?
Darauf deutet Zitat 3 hin:
"Secure Boot-abhängige Software möglicherweise nicht mehr geladen werden können."
—
Klar, wenn Secure-Boot deaktiviert ist, dann funktionieren Anti-Cheat Kernel-Module und davon abhängige Spiele nicht mehr.
Das "möglicherweise" kann man getrost streichen.
Es funktioniert garantiert nicht mehr.
Microsoft hätte auch Klartext reden können:
Wenn das neue Zertifikat nicht da ist, dann schalten wird Secure-Boot ab, kurz bevor das alte Zertifikat abgelaufen ist.
Wenn Windows die Secure-Boot-Funktion im UEFI abschalten kann, dann ist dieser Schutz sinnlos.
Sowas dürfte normalerweise nur ein Admin selber direkt im UEFI machen dürfen.
Die Tatsache, dass Anti-Cheat Kernel-Module von Windows geladen werden, konterkariert Secure-Boot ebenfalls, denn das bedeutet, dass Microsoft potentielle Rootkits mit einem Secure-Boot-Zertifikat zertifiziert. Microsoft wird nämlich nicht den Quellcode von jeder Version dieser Anti-Cheat-Module analysieren.
Meine Lesart ist etwas anders – ob ich unrecht habe, wird sich dann ab Juni 2026 zeigen. Solange ein signiertes Microsoft UEFI Secure Boot-Zertifikat vorhanden ist, startet das bestehende System – auch wenn das Zertifikat abgelaufen ist. Es war ja seit 2011 gültig. Erst wenn dieses Zertifikat fehlt oder manipuliert wurde, streikt der Boot-Lader.
Microsoft könnte – so interpretiere ich den Hinweis – irgendwann künftig in neuen Windows-Versionen (oder Builds) den Boot-Loader so modifizieren, dass dieser ein abgelaufenes Secure Boot-Zertifikat wie ein fehlendes oder manipuliertes Zertifikat behandelt.
Ich hatte angenommen, dass das UEFI auch das Ablaufdatum eines Zertifikats berücksichtigt, das Zertifikat bei Überschreitung des Ende-Datums als "fehlend" oder "ungültig" wertet und nicht mehr bootet.
Falls das nicht der Fall sein sollte, dann ist der ganze Aufstand mit dem Zertifikattausch unnötig, weil er auch bei ungültigem Zertifikat bootet.
Eventuell gibt es auch Unterschiede zwischen den Mainbordherstellern, wie sie die Zertifikate bewerten.
Vielleicht bootet es auf MSI, aber nicht auf ASUS oder Gigabyte?
NAJA….:
– Die Systeme grundsätzlich auch weiterhin booten, da die Gültigkeit (Ablaufdatum) der Zertifikate offensichtlich beim Bootvorgang nicht überprüft werden. Das läst sich auch leicht nachstellen/ausprobieren.
Aber
– Die meisten Admins machen wahrschleinlich die Prozesskette 5944, welche die Schritte 80 (CA 2011 in die DBX) und 200 (SVN) nicht enthalten. Sonst sieht die Sache etwas anders aus.
– Außerdem ist auch denkbar, dass die hersteller irgendwann Bios-Updates bringen, bei denen CA 2011 bereits in der DBX ist.
Es gibt schon Konstellationen, bei denen Systeme nicht mehr booten würden
Es wird auch Probleme mit DRM-geschützten Medien geben, denn die werden nur auf einer "trustet Platform" abgespielt und diese verlangt Secure-Boot.
Wird Netflix etc noch funktionieren, wenn das Secure-Boot-Zertifikat im UEFI abgelaufen ist?
Ja, Netfilx wird noch funktionieren, denn es läuft auch auf meinen Linux-Kisten, bei denen Secure Boot, TPM und das ganze Gedöns deaktiviert sind und auf einem MacBook von 2010. Vielleicht nur in 720p, aber grundsätzlich laufen tut es zumindest zur Zeit auch ohne.
Für Intune war der Artikel recht hilfreich > https://www.tbone.se/2026/01/09/update-secure-boot-certificate-by-using-intune-remediation/
Endlich werden die Rechner mit Secure Boot sicher, wenn sich nach Ablauf der Certs dann kein Windows mehr booten. Mit Sicherheit hat Secure Boot nichts zu tun. Es ist typische Scheinsicherheit von Microsoft. Ein Bootloader ist mit einem Zertifikat signiert, dem die jeweilige Hardwareplatfrom vertraut, was der Bootloader dann wirklich bootet spielt ja keine Rolle. Oder wie nochmal unterbindet MS jetzt das einer verseuchte Windows Installationsmedien in die Welt bringt?
Eher ist das wieder so eine Blase, die den Hardwareherstellern neue Verkäufe bringt. Denn wer sein Bios nicht Updated mangels fehlender Updates bzw. es so Verbaut, dass MS es nicht Updaten kann, der sorgt zwangsläufig dafür, dass mit Secure Boot dann ab Oktober neue Hardware benötigt wird.
Musste MS nicht schon mal vor Jahren was machen, weil ihre Secure Boot doch nicht so Secure war?
Tolle Abhängigkeiten die da wieder geschaffen werden für ein System, das so ziemlich nichts mit Security am Hut hat.
Edit: Weil hier immer nur von Client OS die Rede ist, was ist mit den ganzen Server Systemen ab Windows Server 2012 R2 mit ESU bzw. generell 2016, 2019 und höher. Da machen die besagten Updates wohl nichts. ich hab noch nie erlebt, dass am Patchday der Server 2019 je ein Winre Update gemacht hätte. Das haben wir nun händisch aktualisiert bei den Servern bei uns mit Secure Boot.
Wie immer Microsoft erzwingt irgendwas und lässt dann die Kundschaft dumm im Regen stehen.
Hersteller wie DELL und Lenovo könnten ja bei ihren alten Kisten einfach mal aktualisierte Versionen der UEFI Secure Boot Datenbanken, also PK, KEK, DB und DBX bereitstellen, die man dann manuell via UEFI BIOS selber einspielt. Dafür müssten Firmen wie DELL aber verraten, in welchem Format diese Datenbanken (evtl. ist die Bezeichnung von mir falsch) sind bzw. wie man diese via UEFI BIOS selbst aktualisieren kann.
Doch Support für ältere Systeme bietet eben kaum ein Hersteller an, weil man lieber Kohle macht mit aktuellen PC´s oder Laptops.
Diese Verweigerungshaltung einiger Hersteller wird demnächst zu massivem Anschwillen des Hardwaremülls führen. Die Altmetallverwerter wird´s freuen.
Es sei denn, viele Firmen und Verwaltungen schwenken endlich um auf Linux.
Das aber ist ein "feuchter" Traum, wenn man sieht, was derzeit in Bayern so abläuft.
Bei diversen älteren Dell-Systemen kann man die Sachen manuell einspielen.
Gesehen habe ich das beim Optiplex 3020 und Precision T3620.
Quelle? Gibt´s dazu im Netz eine Beschreibung oder einen Link?
Der intelligente geneigte User (i.e. bereit zum selbststudium einer doku) wird hier und hier fündig:
*https://media.defense.gov/2023/Mar/20/2003182401/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20230317.PDF
*https://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/KEK
Also ich hatte null probleme uralt UEFI BIOSse zu aktualisieren mit version von anno 2015. Absolut gar nichts ist kaputt, es gibt keine gängelung. Man spielt die variablen aus den BINs einfach ein.
Ich hatte die variablen sogar vorher gelöscht und auf uralt factory settings gesetzt (!) um das zu prüfen.
Das mag bei Systemen, die höchstens 5-10 Jahre alt sind gut funktionieren. Aber eben nicht bei allen. Trotzdem sind diese Tipps hier gut, weil sie sicher dem einen oder anderen helfen werden. Daher Danke schön dafür!
Meine alten DELL´s (Optiplex 9010, 7010, 3010) jedenfalls weigern sich nach wie vor standhaft, arbeiten aber ohne SecureBoot und ohne TPM 1.2 klaglos mit einem angepassten Windows 11, sogar mittlerweile 25H2.
Und bis Ende 2025 funktionierte Windows Update bei diesen Geräten auch mit SecureBoot und mit TPM. Aktuell nur noch ohne.
Und ja, der Hersteller sagt ja offiziell: diese Systeme laufen nicht mit Windows 11. Und sie tun es trotzdem. Noch! ;-)
Danke für die Rückmeldung und das es einigermaßen hilfreich war!
Ja leider sind gerade bei Insyde BIOSsen viele Optionen absolut sinnfrei versteckt, nicht mal entfernt. Bevor alles mit RSA2048 signiert war konnte man lustige Hex-Edits machen um die Profi-Einstellungen freizuschalten. Aber ich komme vom Thema ab!
Ich glaube nach wie vor, dass du/Sie zumindest eine Chance haben wenn der Bootloader und die DB auf 2011 gesetzt sind.
Es geht wirklich aus dem OS heraus, allerdings dauert das oft viele Neustarts mit der Registry flag und der geplanten Aufgabe.
Was ist das genaue Fehlerbild, wenn man mit der Powershell die PK, KEK, DB, DBX und EFI-Partition untersucht?
Vielleicht findet man noch die Lösung gemeinsam.
Ich war bei einem Optiplex 3020 damit erfolgreich, im Setup den Custom Mode einzuschalten und als weiteren KEK den von Microsoft signierten KEKUpdate_Microsoft_PK3d8660c0.bin hinzuzufügen. Den Rest hat dann Windows automatisch gemacht.
Brauchen die Hersteller nicht, weil die Aktualisierung/Austausch der o.g. Datenbanken über z.B. Windows-Updates möglich und vorgesehen ist.
Dass das nicht so richtig klappt, liegt alleine an Microsoft. Ich sehe die Hardware-Hersteller deswegen nicht in der Pflicht…..
Das stimmt nicht ganz. Die Hersteller müssen für jeden von ihnen selbst erstellten PK eine jeweils damit signierte Fassung des KEK-2023-Zertifikates erstellen und an Microsoft schicken, damit die Aktualisierung über Windows vollständig möglich ist. Da hapert es z. B. bei Dell mit manchen PKs.
Hört hört!
Hier ein PowerShell Script von *https://pastebin.com/YfiBMeAp
<# README
Pre-test:
powershell -ExecutionPolicy Bypass D:\test_partition_and_db_v2.ps1
Update DB:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x40 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
2x reboot or brute force, whichever works
test again with line 2
Update EFI partition bootloader:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x100 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
2x reboot or brute force, whichever works
test again with line 2, done # >
$PSVersionTable.PSVersion.ToString() + "`n"
function Format-Color([hashtable] $Colors = @{}, [switch] $SimpleMatch) {
$lines = ($input | Out-String) -replace "`r", "" -split "`n"
foreach($line in $lines) {
$color = ''
foreach($pattern in $Colors.Keys){
if(!$SimpleMatch -and $line -match $pattern) { $color = $Colors[$pattern] }
elseif ($SimpleMatch -and $line -like $pattern) { $color = $Colors[$pattern] }
}
if($color) {
Write-Host -ForegroundColor 'Green' $line
} else {
Write-Host -ForegroundColor 'Red' $line
}
}
}
echo "Checking FAT32 EFI partition..."
mountvol S: /S
$sig = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate
$sig = [System.Security.Cryptography.X509Certificates.X509Certificate]::CreateFromSignedFile("S:\EFI\Microsoft\Boot\bootmgfw.efi")
$sig2 = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList $sig | Select-Object -ExpandProperty 'issuer'
echo $sig2 | Format-Color @{ 'CA 2023' = 'dummy' }
mountvol S: /D
echo "Checking SecureBoot DB..."
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' | Format-Color @{ 'True' = 'dummy' }
Richtet sich an Fortgeschrittene, nichts für anfänger, aber man muss auch kein Experte sein.
Die Devise ist hartnäckig sein. Windows will oft nicht direkt die DB oder den Bootloader updaten.
https://borncity.com/blog/wp-content/uploads/2026/02/proof.png
Execution Policy mit bypass wie beim Skript oben nötig (logisch).
Have fun, habe heute 3 Machinen startklar gemacht. Das Skript von cjee21 setzt den Fokus nicht hinreichend auf die EFI FAT32 partition der Systemfestplatte. Es ist nicht so schwer wie viele Behaupten. Windows ist nur stur.
Powershell als Admin starten, aber das sollte klar sein, wenn man mounten, unmounten will ;)
Secureboot sollte auch aktiv sein in msinfo32 sonst bringen die Regkeys nix.
—
GB: Hab das Bild im Blog abgelegt, und den PS-Code hier hin kopiert – falls die externen Links brechen
@Günni
Danke das ist lieb von dir. Hatte die Paste auf 1 Jahr gesetzt, aber manchmal werden die auch bei Fehlerkennung gelöscht.
Ich hoffe es hilft dem ein oder anderen Leser! Danke auch für des Hosten der PNG.
Für die extremst "Nassgeschwitzten" unter euch:
4x (Revoked: True) korrekte Revozierung vor Okt/Nov 2026
Beweis:
https://i.postimg.cc/bYtfX8V9/volle-revozierung.png
Wie man manuell ein DBX append im UEFI BIOS oder aus dem OS selbst heraus macht wisst ihr ja.
(siehe: CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20230317.PDF)
*https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt
*https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt
*https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt
Ihr solltet davon nur 2x brauchen, wenn ihr den Schritt mit 0x80 aus der CVE advisory bereits hinter euch habt.
Jetzt können wir bis Dezember und länger chillen!
Nvm, es sind natürlich 2*3=6 mal (revoked:True)
Die dopplung kommt dadurch zustande, das die 3 certs in der default als auch current DB durch 3 Einträge in der DBX revoziert wurden.
https://i.postimg.cc/KYDCNrf4/volle-revozierung2.png