Secure-Boot-Zertifikatswechsel – Bewertung und Wartung

Ein einzelnes, eigenständiges PowerShell-Skript, das den Secure-Boot-Zertifikatsstatus eines Windows-Rechners für den Wechsel 2011 → 2023 (CVE-2023-24932 / KB5025885) bewertet und – nur wenn Sie es ausdrücklich darum bitten – diesen Rechner in die Microsoft-Wartungspipeline aufnimmt.

Veröffentlicht von Exchange Technology Services für Kunden und Partner, die ihre eigenen Endgeräte verwalten.

Die Kurzfassung

Die Secure-Boot-Zertifikate, die Microsoft 2011 ausgestellt hat, laufen ab und werden durch Versionen von 2023 ersetzt.

Zu keinem dieser Zeitpunkte hört ein Rechner auf zu booten. Microsofts Leitfaden besagt, dass ein Gerät, das ohne die neuen Zertifikate das Ablaufdatum erreicht, „weiterhin normal starten und funktionieren“ wird.

Verloren geht die Fähigkeit, Sicherheitsupdates für die frühe Bootphase zu erhalten – neue Secure-Boot-Sperrungen, BitLocker-Bypass-Mitigationen, Boot-Manager-Korrekturen. Das ist eine sich ansammelnde Gefährdung, kein Ausfall.

Nach dem 19. Oktober 2026 validiert ein Rechner, dessen Firmware Windows UEFI CA 2023 nie aufgenommen hat, auch keine neu signierten Windows-Startmedien mehr, was Wiederherstellungs-, Installations- und PXE-Medien betreffen kann.

Das KEK ist das Tor. Ohne Microsoft Corporation KEK 2K CA 2023 in der Firmware kann Windows Update das DB-Update überhaupt nicht ausliefern. Ein Rechner, dem es fehlt, kann nicht behoben werden, bis das KEK über Windows Update oder ein OEM-BIOS-Update eintrifft. Das ist in der Praxis der häufigste Blocker, und das Skript meldet ihn explizit, statt einen Wert zu schreiben, der nichts bewirken würde.

Was dieses Skript tut und was nicht

Ausführen

Windows PowerShell 5.1, als Administrator — das Lesen der UEFI-Variablen erfordert erhöhte Rechte.

1. Datei entsperren (Windows blockiert heruntergeladene Skripte):

Unblock-File .\Invoke-SecureBootCertServicing.ps1

2. Bewerten — sicher, nimmt keine Änderungen vor:

powershell.exe -ExecutionPolicy Bypass -File .\Invoke-SecureBootCertServicing.ps1

3. Anwenden, nur wenn die Bewertung ergibt, dass der Rechner bereit ist:

.\Invoke-SecureBootCertServicing.ps1 -Apply -SuspendBitLocker

Erfassen der Ausgabe

Der Bericht wird mit Write-Host geschrieben, wird also auf der Konsole angezeigt und von Start-Transcript aufgezeichnet. Eine einfache >-Umleitung erfasst ihn nicht, ebenso wenig das Piping an einen anderen Befehl.

Start-Transcript C:\Temp\secureboot.log
.\Invoke-SecureBootCertServicing.ps1
Stop-Transcript

Für eine maschinenlesbare Kopie, nützlich beim Sammeln von Ergebnissen in einer Flotte:

.\Invoke-SecureBootCertServicing.ps1 -JsonPath C:\Temp\secureboot.json

Befunde

Zwei Achsen, bewusst nicht zusammengeführt

Der Bericht zeigt Wartungsstatus und Migrationsstatus getrennt.

• Wartungsstatus — was Microsofts Pipeline laut eigener Aussage tut.
• Migrationsstatus — was tatsächlich für den Boot-Pfad zutrifft.

Diese beiden können in der Praxis durchaus voneinander abweichen. Ein Rechner kann UEFICA2023Status = Updated melden, während beide Boot-Manager-Binärdateien auf der Festplatte weiterhin 2011-signiert sind — das passiert, wenn die Firmware die 2023-CA bereits vorregistriert ausgeliefert hat, sodass die Zertifikatsseite abgeschlossen war, während die Boot-Manager-Seite nie ausgeführt wurde. Fasst man beide in einem Feld zusammen, wird dieser Rechner als fertig gemeldet, obwohl er nur halb migriert ist.

Aus demselben Grund leitet das Skript den Status nicht aus WindowsUEFICA2023Capable ab. Microsofts Dokumentation sagt über diesen Wert wörtlich: „Nur als Referenz — diesen Schlüssel nicht verwenden, wenn Sie den Status von Secure-Boot-Updates abfragen.“ Er wird nur als Diagnose erfasst.

BitLocker

Die Wartungsschritte verändern den Firmware-Zustand, wodurch sich die TPM-PCRs verschieben können, an die ein BitLocker-Schutz gebunden ist, was beim nächsten Start zur Aufforderung nach einem Wiederherstellungsschlüssel führen kann.

• Das Skript weigert sich, ein geschütztes Volume ohne Wiederherstellungskennwort-Schutz zu aktivieren — es gäbe keinen Weg zurück.
• Es kann nicht überprüfen, dass Sie eine Kopie dieses Schlüssels besitzen. Vergewissern Sie sich, dass Ihr Hinterlegungsprozess intakt ist, bevor Sie -Apply in großem Umfang ausführen.
• -SuspendBitLocker setzt den Schutz über den nächsten Neustart hinweg aus, sodass die Änderung ohne Aufforderung neu versiegelt wird. BitLocker wird danach automatisch wieder fortgesetzt.
• Der Bericht gibt Ihr PCR-Profil an. Ein PCR-7-basiertes Profil ist für den Zertifikatszusatz im Hinblick auf Measured Boot unbedenklich. Ein Profil mit PCR 0/2/4 deckt Firmware- und Boot-Manager-Messungen ab, die diese Schritte tatsächlich verändern — höheres Risiko einer Aufforderung.

Der BitLocker-Status wird auf drei unabhängigen Wegen gelesen (Get-BitLockerVolume, manage-bde und Win32_EncryptableVolume) und abgeglichen. Wenn die Leser abweichen oder keiner das Volume lesen kann, verweigert das Skript Änderungen an der Firmware, statt zu raten.

Parameter

Virtuelle Maschinen sind standardmäßig ausgeschlossen: Die 2023-CA erreicht die Firmware-Basislinie über ein BIOS-Update, und die Firmware einer VM stammt von ihrem Hypervisor — ein Gast auf einem nicht aktualisierten Host kann die Migration nicht selbst abschließen.

Was nach dem Anwenden zu erwarten ist

• Es wird nicht mit dem ersten Neustart abgeschlossen. Windows wendet zuerst das Zertifikatsupdate an, dann das Boot-Manager-Update, typischerweise über mehr als einen Neustart hinweg, mit einer geplanten Aufgabe dazwischen.
• Microsoft steuert dies pro Gerät. Das Setzen des Werts stellt die Arbeit in die Warteschlange; der gestaffelte Rollout von Microsoft entscheidet, wann jeder Rechner berechtigt ist. Wenn nichts zu passieren scheint, führen Sie es erneut aus und lesen Sie die Zeile „Microsoft-Gate“ — sie nennt den Grund, z. B. „Under Observation - More Data Needed“.
• Sie können es jederzeit erneut ausführen, um den Fortschritt zu prüfen. Es ist sicher, es wiederholt auszuführen.

Validierung

Ende-zu-Ende getestet unter Windows 11 (Build 26200, PowerShell 5.1, ausgeführt als SYSTEM), UEFI mit aktiviertem Secure Boot, BitLocker vollständig verschlüsselt mit TPM- + Wiederherstellungskennwort-Schutz auf einem PCR-7,11-Profil:

• Einen halb migrierten Rechner korrekt erkannt — Firmware vertraut Windows UEFI CA 2023, während bootmgfw.efi weiterhin von Microsoft Windows Production PCA 2011 signiert war — und ihn nicht als fertig gemeldet, obwohl dieser Rechner gleichzeitig UEFICA2023Status = Updated und WindowsUEFICA2023Capable = 2 meldete.
• Alle drei BitLocker-Leser stimmten überein und wurden abgeglichen.
• Verweigerungs-Gates verifiziert: virtuelle Maschine (Exit 2) und das 0x80-Sperrbit (Exit 1).
• -Apply schrieb 0x5944, bestätigt durch unabhängiges Lesen der Registrierung.
• -SuspendBitLocker gefolgt von einem Neustart: Der Rechner kehrte ohne Wiederherstellungsaufforderung zurück, und BitLocker wurde automatisch fortgesetzt.
• Start-Transcript erfasste den vollständigen Bericht; die JSON-Ausgabe enthielt kein Wiederherstellungsschlüsselmaterial.

Noch nicht beobachtet: ein Rechner, der die vollständige Migration zu FullyMigrated abschließt. Der letzte Schritt wird durch Microsofts gestaffelten geräteweisen Rollout gesteuert, der außerhalb der Kontrolle aller liegt. Das Skript zeigt den genannten Grund dieses Gates an, statt es als unerklärten No-op stehen zu lassen.

Lizenz

MIT — siehe LICENSE. Wird wie besehen ohne Gewähr bereitgestellt. Überprüfen Sie es, bevor Sie es in Ihrer Umgebung ausführen; es ist genau aus diesem Grund eine einzelne lesbare Datei.