Secure Boot Zertifikate - to do

[mcdaniels 38]

Hallo zusammen,

nach gefühlten 100 Artikeln zu dem Thema stell ich fest, dass es mir noch immer nicht ganz klar ist, was denn nun eigentlich wirklich zu tun ist. Was ich glaube zu wissen:

 

• Wenn Firmware und Windows die neuen Secure-Boot-Zertifikate unterstützen, erfolgt die Umstellung weitgehend automatisch über Windows Update.
• Wenn die Firmware die neuen Zertifikate nicht unterstützt oder nicht aktualisiert werden kann, kann das System meist weiterhin mit dem vorhandenen Bootloader starten.
• Problematisch wird es jedoch bei zukünftigen Bootloadern, Neuinstallationen oder Rettungsmedien, die ausschließlich mit den neuen Microsoft-Signaturen versehen sind.
• Das System bootet nicht zwingend plötzlich nicht mehr. Die Einschränkung besteht vielmehr darin, dass zukünftig signierte Bootloader möglicherweise nicht mehr akzeptiert werden können, wenn die Zertifikatsaktualisierung nicht erfolgreich durchgeführt werden kann.

 

Aus der Unklarheit heraus, habe ich 2 Skripte bemüht, die Heise(+) zur Verfügung stellt und auf ein paar PC losgelassen. Folgend haben wir einen PC mit aktuellst-möglichen Uefi/Bios (von 2025 - etwas Aktuelleres gibt es nicht).

 

Info zu den Zertifikaten:

 

In dem Fall (oben). Eigentlich verwendet das System noch alte Zertifikate, in den Defaultwerten wären bereits neue enthalten (dbDefault, KEKDefault), PK verwendet bereits ein aktuelles Zertifikat.

 

Bootmanager-Info:

 

Der Bootmanager verwendet noch alte Zertifikate.

 

Die Frage(n): Dieser PC wäre meiner Meinung nach quasi vorbereitet, aber das finale Update wurde noch nicht ausgelöst. Was soll man in so einem Fall tun? Das Juniupdate abwarten, oder manuell eingreifen?

 

Was, wenn ich weder PK, DB und KEK aktuell bekomme? Secure Boot ausschalten als einzige Lösung?

 

Danke im Voraus!

 

[testperson 2.007]

Moin,

 

eigentlich ist das recht entspannt. Registry Key (oder GPO (Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates - Microsoft Support)) auf die Clients bringen, ggfs. den Task starten oder (bis zum nächsten Reboot) warten.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Manually reboot the system when the AvailableUpdates becomes 0x4100

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

 

Anschließend ggfs. in der Registry prüfen, ob das Update erfolgreich war bzw. im Eventlog (System -> Quelle "TPM-WMI" (Secure Boot DB and DBX variable update events - Microsoft Support)) schauen, was passiert.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
AvailableUpdates

# Sollte den Wert 0x4000 haben

 

Option 1) Alles nimmt seinen Lauf und funktioniert ( <- sehr wahrscheinlich)

Option 2) Secure Boot ist deaktiviert (und man sollte prüfen warum; Ggfs. aktivieren, sofern möglich bzw. dürfte das Gerät dann auch schon im austauschwürdigen Alter sein.)

Option 3) Es wird ein BIOS/Firmware Update benötigt ( <- eher unwahrscheinlich)

 - Es gibt eins -> Updaten

 - Es gibt keins -> Das Gerät dürfte (weit) aus dem Support sein und sich in einem austauschwürdigen Alter befinden (oder man hat vielleicht recht günstig "in China" geschoppt)

 

HTH

Jan

[mcdaniels 38]

Hallo @testperson

 

Danke für die Erklärung. Setzt das voraus, dass das CU 05/2026 am System installiert ist? 

 

D.h. aber auch: Vernichten kann man das System mit der Aktion eigentlich nicht. Entweder es klappt, oder eben nicht?

 

Gerade auf meine Kiste getestet. Interessanterweise gabs im Eventlog die Meldung, dass die Zertifikate noch nicht aktualisiert wurden, obwohl lt CT Tool alles passt.

 

Vor dem Regkey und dem Task:

 

Nach der Regkey-Aktion & Task sehe ich jetzt:

 

 

Müsste nun also passen. Der Regkey Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot steht auf 0x4000

bearbeitet 5. Juni von mcdaniels

[mcdaniels 38]

Ich habe hier mehrere Lenovo  M720q tiny (Uefi von 03/2026, Win11 25H2 und 24H2 mit CU 05/2026) da wird mir das Upgrade der Zertifikate im UEFI offenbar vom UEFI blockiert. Lt. Log "Zugriff verweigert". Hat jemand eine Idee was man dann in dem Fall macht? (Habe bereits x-fach rebootet)

 

Windows UEFI CA 2023 Status: InProgress UEFI CA 2023 Error: 2147942750 UEFI CA 2023 Error Event: 1800

 

=== Certificate Update Summary ===

[1P] Windows UEFI CA 2023 (db): Updated [1P]

Microsoft Corporation KEK 2K CA 2023 (KEK): Updated [3P]

Microsoft Corporation UEFI CA 2011 (db): Present - 3P 2023 certs required [3P]

Microsoft UEFI CA 2023 (db): Updated [3P] Microsoft Option ROM UEFI CA 2023 (db): Updated

===================================

 

--> Knackpunkt wohl: 

Microsoft Corporation UEFI CA 2011 (db): Present - 3P 2023 certs required [3P]

 

bearbeitet 9. Juni von mcdaniels

[mcdaniels 38]

Als kurzes Update zu diesem Thema: Lenovo hat da wohl seine Probleme (bestätigt), obwohl UEFI etc auf aktuellem Stand sind. Angeblich soll ein "Restore Factory Keys" via UEFI helfen. Das muss ich aber noch testen. Gott  sei Dank hab ich sonst nichts zu tun............

[mcdaniels 38]

Mittlerweile hab ich wohl den "Workflow" für die meisten unserer Lenovos herausgearbeitet, wenn der Available Updates Key auf Wert 4004 stehen bleibt bzw im TPM WMI ein Eintrag enthalten ist, dass Securebootzertifikatsupdates zur Verfügung stehen, diese aber noch auf die Firmware angewendet werden müssen (=KEK) :

 

1.) Wenn Bitlockerverschlüsselung, sicherstellen, dass der Wiederherstellungsschlüssel aufliegt.

2.) Uefi Update auf die aktuellste Version (System sicherheitshalber nach dem UEFI Update 1x booten)

3.) Key Reset im UEFI durchführen <--- Das war der eigentliche Knackpunkt

4.) Regkey auf wert 5944 setzen
 

     reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

 

Danach 

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

 

Der Registrykey "AvailableUpdates" springt dann auf 0x4000

 

Wenn man danach das Powershell-Testscript: c:\Windows\SecureBoot\ExampleRolloutScripts\Detect-SecureBootCertUpdateStatus.ps1 startet,

 

ist das SecureBootUpdate erledigt:

Available Updates: 0x4000

Update complete (Event 1808 or Status=Updated)

=== Certificate Update Summary ===
[1P] Windows UEFI CA 2023 (db): Updated
[1P] Microsoft Corporation KEK 2K CA 2023 (KEK): Updated
[3P] Microsoft Corporation UEFI CA 2011 (db): Present - 3P 2023
certs required
[3P] Microsoft UEFI CA 2023 (db): Updated
[3P] Microsoft Option ROM UEFI CA 2023 (db): Updated

 

Vielleicht kann das ja jemand brauchen

bearbeitet 12. Juni von mcdaniels

[testperson 2.007]

Ich schätze mich an der Stelle einmal glücklich, dass ich es noch nicht mit Lenovo  (M720q tiny) zu tun hatte.

 

Danke für das Updaten hier und die ganzen Informationen. 👍

[mcdaniels 38]

vor 43 Minuten schrieb testperson:

Ich schätze mich an der Stelle einmal glücklich, dass ich es noch nicht mit Lenovo  (M720q tiny) zu tun hatte.

 

...das wird noch lustig mit diesen Kisten. (Brauche bald neue Turnschuhe).

[testperson 2.007]

vor 10 Minuten schrieb mcdaniels:

...das wird noch lustig mit diesen Kisten. (Brauche bald neue Turnschuhe).

 

Evtl. hast du ja Glück und es gibt auch für die Lenovo Tiny eine WMI BIOS Schnittstelle bzw. irgendetwas, um das automatisiert auszulösen: kbl_deploy_01.pdf

[mcdaniels 38]

vor einer Stunde schrieb testperson:

Evtl. hast du ja Glück und es gibt auch für die Lenovo Tiny eine WMI BIOS Schnittstelle bzw. irgendetwas, um das automatisiert auszulösen: kbl_deploy_01.pdf

Jep, da soll es wohl etwas geben, danke! Allerdings habe ich das Problem, dass der Bitlocker nach dem Keyreset den Wiederherstellungsschlüssel wissen will. Das kann ich dann leider nur vor dem Bildschirm machen.

 

Gut, jetzt könnt ich Bitlocker aus  -> WMI Änderung (Reset) -> Booten -> Bitlocker ein und das dann alles "Scripten".

bearbeitet 12. Juni von mcdaniels