ets-mse/secure-boot-cert-servicingEigenständige Bewertung und Wartung für den Zertifikatswechsel von Secure Boot 2011 bis 2023 (CVE-2023-24932 / KB5025885). Standardmäßig nur Bewertung; keine Abhängigkeiten, kein Netzwerk, keine Telemetrie.
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 Secure-Boot-Zertifikate, die Microsoft 2011 ausgestellt hat, laufen ab und werden durch Versionen von 2023 ersetzt.
| Zertifikat | Datum | Speicher | Rolle |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | abgelaufen am 24. Juni 2026 | KEK | Autorisiert Updates für DB und DBX |
| Microsoft UEFI CA 2011 | abgelaufen am 27. Juni 2026 | DB | Signiert Drittanbieter-Loader / Option ROMs |
| Windows Production PCA 2011 | 19. Oktober 2026 | DB | Signiert den Windows-Bootloader |
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.
| Eigenschaft | Detail |
|---|---|
| Standardverhalten | Nur Bewertung. Keine Schreibvorgänge ohne -Apply. |
| Abhängigkeiten | Keine. Keine Module, kein Installationsprogramm. Windows PowerShell 5.1. |
| Netzwerkzugriff | Keiner. Es kontaktiert keinen Host. |
| Telemetrie / Berichterstattung | Keine. Alles, was es findet, gibt es in Ihrer Konsole aus. Nichts verlässt den Rechner. |
| BitLocker-Wiederherstellungsschlüssel | Werden nie gelesen, ausgegeben oder übertragen. Es prüft nur, ob ein Wiederherstellungskennwort-Schutz existiert. |
Was -Apply schreibt | Genau ein Registrierungswert: AvailableUpdates = 0x5944 unter HKLM\SYSTEM\CurrentControlSet\Control\Secureboot. Der dokumentierte KB5025885-Opt-in. Additiv — es fügt das Zertifikat von 2023 hinzu, ohne das von 2011 zu entfernen. |
| Unumkehrbare Aktionen | Hart verweigert. Das 0x80-DBX-Sperrbit ist permanent, solange Secure Boot aktiviert bleibt; das Skript verweigert jeden Wert, der es enthält, es sei denn, -AllowRevocation wird explizit übergeben. Übergeben Sie es nicht. |
| Neustarts | Es startet den Rechner nie neu und fordert den Benutzer nie zur Eingabe auf. |
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
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
| Befund | Bedeutung | Exit |
|---|---|---|
ReadyToArm | KEK 2023 vorhanden, DB noch nicht migriert, kein Opt-in erfolgt. -Apply ist der nächste Schritt. | 0 |
HalfMigrated | Die Firmware vertraut der 2023-CA, aber der Rechner bootet weiterhin einen 2011-signierten Loader. Heute kein Problem; würde nicht booten, falls 2011 jemals gesperrt würde. Das Boot-Manager-Update ist weiterhin erforderlich. | 0 |
HalfMigrated-Armed | Wie oben, und bereits aktiviert. Starten Sie den Rechner neu — führen Sie -Apply nicht erneut aus. | 0 |
AlreadyQueued | Aktiviert, wartet auf Microsofts gestaffelten Rollout. | 0 |
InProgress / RebootPending | Wartung läuft. Neu starten und erneut ausführen, um den Fortschritt zu beobachten. | 0 |
FullyMigrated | Fertig. Der Boot-Manager ist 2023-signiert. | 2 |
BlockedNoKek2023 | KEK 2023 fehlt. Installieren Sie zuerst anstehende Windows-Updates und/oder das OEM-BIOS-Update. | 3 |
BlockedFirmwareKek | Die Firmware hat kein KEK, das vom Plattformschlüssel dieses Rechners signiert ist. Benötigt ein OEM-BIOS-Update (oder auf einer VM ein Host-Update). | 3 |
NotApplicable-* | Legacy-BIOS oder Secure Boot deaktiviert. | 2 |
Error | Die Wartung hat einen Fehler gemeldet; der Fehlercode wird ausgegeben. | 0 |
Der Bericht zeigt Wartungsstatus und Migrationsstatus getrennt.
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.
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.
-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.