Hilfe, die SecureBoot Zertifikate laufen ab!
So oder so ähnliche Zeilen habe ich vor kurzem das erste Mal auf der Arbeit in einer Meldung gelesen und mir gedacht: Oje, der nächste Aufschrei, dass irgendwann irgendwas nicht mehr funktionieren könnte.
Aber was bedeutet das nun wirklich? Erstmal, bestehende Windows-Installationen laufen weiter. Dein Notebook, dein PC wird weiter funktionieren. Probleme könnten entstehen, wenn du deine Geräte neu installieren möchtest.
Was bedeutet das für mich? Ich habe so einiges an Hardware herumstehen. Angefangen bei einem Microsoft Surface Pro7, einer Workstation, einem ca. 10 Jahre alten Fileserver, einem kleinen PC unter dem Fernseher und noch das ein oder andere Equipment fürs Testlab. Einige Geräte, wie jene mit Windows 11 nutzen SecureBoot. Diese Geräte sind von diesem Ablauf Ende Juni betroffen. Und nicht alle haben eine Verbindung ins Internet.
Was passiert jetzt also?
Erstmal nichts Gravierendes. Meine Notebooks und PCs funktionieren, soweit mir bis jetzt bekannt, problemlos weiter. Bei Neuinstallationen kann es aber zu Problemen kommen, weil neuere Betriebssysteme die neuen Zertifikate brauchen, nicht mehr installiert werden können.
Meine Windows Geräte haben die Zertifikate bereits vor Monaten über Windows Updates erhalten und befinden sich bereits in folgendem Ordner: C:\Windows\System32\SecureBootUpdates
Diese Zertifikate müssen jetzt bis Juni in den BootManager und am besten auch ins UEFI der Geräte eingetragen werden. Auch das sollte in der Theorie automatisch passieren. Zumindest wenn die Geräte nicht viel älter als 4 Jahre sind. Meine sind bis auf das Surface alle älter. Teilweise wesentlich älter.
Wie prüft man nun, ob der PC die Zertifikate schon installiert hat
Dazu gibt es auf github unter folgendem Link einige Skripte:
https://github.com/cjee21/Check-UEFISecureBootVariables
Diese sind zum Überprüfen, ob die Zertifikate schon auf dem Rechner vorhanden sind. Ob sich diese bereits in den Windows SecureBoot Datenbanken befinden und ob diese auch im BIOS bzw. UEFI vorhanden sind. Die Skripte sind, wie anzunehmen als Administrator auszuführen.
Zusätzlich wird noch folgende Powershell-Zeile benötigt (ebenfalls als Administrator ausführen) um den Zertifikatsnamen in der SecureBoot-DB auszulesen.
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes) -match “Windows UEFI CA 2023”
Erhält man den Wert “true” ist das Zertifikat in der Datenbank. Bei “false” fehlt dieses noch.
Los geht’s mit dem ersten Kandidaten
Der TV-Rechner, ein HP Elitedesk 600 G4 hat noch nie Windows 11 Updates bekommen. Ist auch mit keinem Netzwerk verbunden, hat kein Internet. Ist also komplett von der Außenwelt abgeschnitten. Automatisch bekommt dieser Client also nichts.
Wie die Screenshots der Batch-Files zeigen, ist auch noch kein neues Zertifikat installiert.
Da der TV-Rechner keine Anbindung ans Netzwerk hat, nutze ich zuerst ein ISO zum Inplace-Upgrade von Windows 11 23H2 auf 25H2. Nach dem Upgrade auf 25H2 waren die Zertifikate noch nicht da, wie die Screenshots zeigen.
Danach die nächsten Updates mit dem WSUS Offline Update Stick installiert. Auch nach diesem Updatevorgang war der Zertifikats-Status unverändert. Wichtig ist dabei das Ergebnis der „Check UEFI PK, KEK, DB and DBX.cmd“.
Forcieren der Updates
Oder: Ich will meine Zertifikate jetzt auf eigenes Risiko tauschen und nicht auf Microsoft oder Updates vom Hersteller warten.
Warten würde bei meinem TV-Rechner ohne Internetverbindung auch nichts bringen. Mit dem Ausführen der „Apply 2023 KEK, DB and bootmgfw update.cmd“ und „Apply DBX update.cmd“ wird das Einspielen der Zertifikate forciert. Nach dem Ausführen sollte man ca. 15min warten.
Das SecureBoot Eventlog zeigt dann das Ergebnis.
Und wie in der ersten Zeile ersichtlich sollte, das System nun neu gestartet werden.
Der erneute Check mit der “Check UEFI PK KEK DB and DBX.cmd” zeigt jetzt folgendes Ergebnis.
Und die Auswertung des Zertifikatnamens sieht so aus.
Die Zertifikate sind jeweils in den “Current-Datenbanken” installiert. Einzig im UEFI den “Default-Datenbanken” sind die Zertifikate noch nicht angekommen. Das Bedeutet, wenn ich jetzt das System zurücksetze muss ich die Zertifikate wieder installieren. Bei neuen Betriebssystemen könnte es auch Probleme geben, wenn sich diese nur mit den neuen Zertifikaten installieren lassen.
Hier wäre dann die Lösung, zuerst eine ältere Version zu installieren, die Zertifikate einzuspielen und anschließend das Betriebssystem per InPlace Upgrade zu aktualisieren. Oder, wenn möglich für die Installation des neuen Systems SecureBoot auszuschalten. Dann die benötigten SecureBoot Zertifikate zu installieren. Erst danach SecureBoot einzuschalten.
Angeblich wird aktuell von Microsoft noch ein notwendiges “Windows Secure Boot Allowed Key Exchange Key (KEK) Update” verteilt. Ob dieses in manchen Fällen die Zertifikate auch ins UEFI schreiben kann, wird sich zeigen. Bei meinem TV-Rechner werde ich das, wenn möglich, manuell zu einem späteren Zeitpunkt installieren.
Wann sollte man warten und wann selbst tauschen?
Wenn du ein relativ neues Gerät hast, möglicherweise auch noch von HP, DELL, Microsoft oder auch Lenovo und dieses regelmäßig eine Internetverbindung hat, würde ich an der Stelle auf Updates vom Hersteller warten.
Bei alten Geräten, so wie ich habe oder PCs, Laptops ohne Internetverbindung muss man selbst aktiv werden.
Mein DELL-Notebook hat das Zertifikat bereits durch ein UEFI-Update erhalten. Hier sind die Haken bei den “Default-Datenbanken” vorhanden, aber bei “Current” noch nicht.
Somit steht fest, “Current” aktualisiert Windows, die “Default” der Hersteller.
Hinterlasse einen Kommentar