Secure Boot Zertifikate und Signaturen verstehen — KMU IT Spice

Erstellt mit ChatGPT

English version

Da am 17.06.2026 sowie am 19.10.2026 verschiedene Certificate Authories (CA) Zertifikate ablaufen, die für Secure Boot eingesetzt werden, habe ich mich intensiv mit den Zertifikaten im UEFI BIOS und den Signaturen von Windows Bootloadern in der EFI-Partition auseinandergesetzt. Bei meinen Recherchen im Internet fand ich zwar viele Quellen zum Thema, jedoch konzentrierten sich die meisten auf die Zertifikate im BIOS und nicht so sehr auf die Signaturen der Bootloader. Ausserdem sind mir die verschiedenen Artikel oft zu wenig genau oder haben zu wenig Tiefe.

Das hat mich angespornt, diesen Artikel zu schreiben. Weniger über das Problem der ablaufenden CA-Zertifikate (da bin ich etwas spät dran), dafür mehr über das neue Wissen, das ich bei meinen Recherchen gesammelt habe. Es mussten zum Teil Workarounds her und Widersprüchlichkeiten gelöst werden. So habe ich etwa herausgefunden, wieso Get-AuthenticodeSignature das falsche Tool ist, um die Signaturen der Bootloader zu prüfen. Doch dazu später mehr.

Voraussetzungen

Folgendes setze ich voraus:

• Ein Windows Gerät
• Basiswissen zu PowerShell
• Admin-Rechte

Ziel

Mit diesem Blogbeitrag möchte ich mein Wissen rund um UEFI CA-Zertifikate und Bootloader Signaturen im Bezug auf Secure Boot festhalten und teilen. Vielleicht hilft es einem Admin, auf dem allerletzten Zacken die eigenen Geräte zu prüfen, bevor nach dem 17.06. Geräte schlimmstenfalls nicht mehr Starten.

Technische Details

Secure Boot setzt ein UEFI BIOS mit korrekt installierten Zertifikaten zur Überprüfung von Signaturen, etwa von Bootloadern, voraus. Sie werden oft “Keys” genannt und sind unabhängig von der klassischen Zertifikatshierarchie im Web. Die CA-Zertifikate, die ins UEFI BIOS installiert werden, bilden den “Trust Anchor” für Secure Boot — egal ob öffentlich vertraut oder nicht.

Es werden die folgenden Keys unterschieden:

• PK (Platform Key): Der oberste Schlüssel für Secure Boot. Er identifiziert den Besitzer der Secure-Boot-Konfiguration und autorisiert Änderungen an den Secure-Boot-Schlüsseln. In der Regel ist ein OEM bzw. Microsoft Key installiert. Mit “Key” ist der öffentliche Schlüssel gemeint. Wer den privaten Schlüssel besitzt, kann die gesamte Secure-Boot-Konfiguration des Systems kontrollieren.
• KEK (Key Exchange Keys): Sie autorisieren Änderungen an den Signaturdatenbanken (db und dbx). Mit einem gültigen KEK-signierten Update kann man zum Beispiel neue vertrauenswürdige Zertifikate in die db eintragen, alte oder kompromittierte Zertifikate über die dbx sperren oder Hashes bestimmter Bootloader erlauben oder verbieten.
• db (Allowed Signature Database): Die db enthält vertrauenswürdige Zertifikate, öffentliche Schlüssel oder Hashes. Mit diesen Einträgen werden Signaturen von UEFI-Anwendungen (z. B. Bootloadern) validiert.
• dbx (Forbidden Signature Database): Entgegen zu db enthält die dbx gesperrte Zertifikate, Schlüssel oder Hashes, die trotz sonstiger Vertrauensstellung nicht mehr verwendet werden dürfen.

Weiter müssen, wie schon angedeutet, die Bootloader und weitere vom Betriebssystem geladene Komponenten, korrekt signiert sein. Die Signaturen müssen eine Kette bilden und ultimativ mit den im UEFI BIOS installierten Zertifikaten überprüft werden können.

In diesem Zusammenhang nimmt es mich daher wunder, welche Zertifikate im UEFI BIOS hinterlegt sind und mit welchem Zertifikat und CA die Bootloader von Windows signiert sind.

Die im UEFI BIOS installierten Zertifikate prüfen

Die Zertifikate im UEFI BIOS liegen binär vor. Am besten ist es, wenn man weiss, welches Zertifikat im Detail man finden möchte. Dann kann mittels PowerShell (als Administrator) nach dem Zertifikat gesucht werden. Als Beispiel orientiere ich mich an den neuen Zertifikaten, welche für Secure Boot ab dem 17.06.2026 wichtig sind:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match 'Microsoft UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

Die ersten beiden werden in der db gesucht, das letzte im KEK. Die Ausgabe ist dann jeweils “true” oder “false”.

Auch der Name vom Platform Key kann herausgefunden werden:

PS C:\Users\marco> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).Bytes)
?Y?????J*?H???r???N?<?"?A?c?9????0??0???        ???k??n0
0j1
   0    UJP10U
            Kanagawa10U
                      Yokohama10U

Lenovo Ltd.10U
320624103436Z0j1novo Ltd. PK CA 20120
                0       UJP10U
                            Kanagawa10U
                                      Yokohama10U

Lenovo Ltd.10U
?0?     *?H?? Lenovo Ltd. PK CA 20120?"0
???]bc??wRf?_?"?q:K?
...

Soweit so gut.

Bootloader-Signatur überprüfen

Hier wird es herausfordernder. Grundsätzlich kann mit folgenden Befehlen die verstekte EFI-Partition lesend eingebunden und mit PowerShell die Signatur überprüft werden:

mountvol Z: /S
Get-AuthenticodeSignature z:\EFI\Microsoft\Boot\bootmgfw.efi | fl *
Get-AuthenticodeSignature Z:\EFI\Boot\bootx64.efi | fl *
mountvol Z: /D

Da die meisten Seiten zum Thema Secure Boot und ablaufende Zertifikate nicht richtig auf eine Prüfung der Signatur der Windows Bootloader eingehen, habe ich intuitiv zu Get-AuthenticodeSignature gegriffen.

Beim Ausprobieren hatte ich jedoch folgendes bemerkt:

• Get-AuthenticodeSignature gibt mir für dieselbe Datei in einer Admin-PowerShell eine andere Ausgabe als in einer PowerShell, die ich als SYSTEM gestartet habe.
• Auf anderen, vergleichbaren Systemen hatte ich in der Admin-PowerShell andere Ausgaben als auf meinem Referenzsystem, obwohl dieselben Schritte nachvollzogen wurden.

Das liess mich genauer hinschauen. Wieso diese Unterschiede?

Unterschiedliche Signaturtypen

Eine Datei kann grundsätzlich mehrere Signaturen haben (es kommt auf den Dateityp an) und es gibt zwei Arten, wie eine Datei signiert sein kann:

• Eingebettete Signaturen: Das ist das, was allgemein als “Signatur” verstanden wird. Die Signatur ist direkt in die Datei eingebettet bzw. daran angehängt.
• Katalog-Signaturen: Dabei handelt es sich um eine andere Art, wie mit Signaturen umgegangen wird und wie Signaturen überprüft werden. Der Hash der vorliegenden Datei wird dabei (mit vielen anderen Datei-Hashes) in einem Katalog (*.cat) gespeichert. Dieser Katalog wird danach signiert. Stimmt die Signatur der Katalogdatei und stimmt der Hash der vorliegenden Datei mit dem Hash vom Katalog überein, so wird der Datei vertraut.

Get-AuthenticodeSignature Eigenheit

In der Doku zu Get-AuthenticodeSignature bei Microsoft habe ich etwas interessantes zum Thema gefunden:

The Get-AuthenticodeSignature cmdlet gets information about the Authenticode signature for a file or file content as a byte array. If the file is both embedded signed and Windows catalog signed, the Windows catalog signature is used.

Get-AuthenticodeSignature bevorzugt also die Signaturen vom Katalog. Daher ist es nicht unbedingt geeignet, die Signatur von Treibern, Bootloadern, Bibliotheken und anderen Systemdateien zu prüfen.

In meinem Fall wollte ich bei dem Unternehmen, für das ich arbeite, automatisiert die Signatur des Windows-Bootloaders auf den Endgeräten der Benutzer überprüfen. Ziel war es festzustellen, ob die Systeme bereits alle relevanten Updates erhalten hatten, die im Zuge der Umstellung der für Secure Boot verwendeten Zertifikate erforderlich sind. Die Ausgabe war ernüchternd, da die Signatur vom Katalog nach wie vor mit einem alten Zertifikat vorliegt und nur die eingebettete Signatur mit einem neueren Zertifikat gemacht wurde. Get-AuthenticodeSignature hat mir lediglich die Werte der Signaturen über den Katalog ausgegeben.

Wieso aber die Admin-PowerShell und die SYSTEM-PowerShell vom selben System unterschiedliche Resultate liefern, ist mir nach wie vor schleierhaft.

Hier übrigens die alte und neue CA für alle, die selber kurz prüfen möchten:

Alte CA: Microsoft Windows Production PCA 2011 → Aktion notwendig Neue CA: Windows UEFI CA 2023

Bootloader Signatur mit Sysinternals sigcheck prüfen

Die Signatur lässt sich verlässlicher mit sigcheck.exe von Systinternals prüfen. Der neue Code-Block in PowerShell sieht dann so aus:

mountvol Z: /S
sigcheck -i z:\EFI\Microsoft\Boot\bootmgfw.efi
sigcheck -i Z:\EFI\Boot\bootx64.efi
mountvol Z: /D

Für mich und meinen Zweck hat das gepasst, obwohl sigcheck nicht explizit die eingebettete Signatur oder diejenige über den Katalog anzeigt, sondern die Datei wohl über Windows APIs verifiziert und das Ergebnis anzeigt. Um festzustellen, ob ein Windows-Bootloader mit einem Zertifikat von der erwarteten Zertifizierungsstelle signiert ist, reichte dieser Grad der Überprüfung aus.

Bootloader Signatur im GUI prüfen

Die mit mountvol Z: /S eingebundene Partition ist im Explorer nicht zu sehen oder nicht zu öffnen. Ich habe mir dabei mit 7zip beholfen. Das Tool habe ich auf meinen Systemen installiert und es hat mir schon ab und zu weitergeholfen, wenn andere Tools (wie der Explorer) versagten oder nicht verfügbar waren.

In der selben PowerShell, mit der mountvol ausgeführt wurde, wird 7zFM.exe gestartet. Über dessen Fenstermanager kann zu z:\EFI\Microsoft\Boot* navigiert werden. Dort per Rechtsklick die Eigenschaften der Datei bootmgfw.efi anzeigen lassen und im Reiter Digital Signatures* die Signaturen prüfen.

Hinten: 7zFM.exe; vorne ist die eingebettete Signatur sowie die Katalogsignaturen sichtbar

Tipps für ein Update in letzter Minute

Sollte jemand noch alte Zertifikate im UEFI BIOS haben und/oder einen Windows Bootloader, der noch mit einem Zertifikat der CA Microsoft Windows Production PCA 2011 signiert ist, verwenden, gibt es Handlungsbedarf.

Grundlagen & manuelles Triggern

In der Registry eines Geräts ist gut zu erkennen, ob das Update ausgeführt wurde, ob es dabei Fehler gab oder ob alles OK sein sollte.

Die folgenden beiden Pfade sind wichtig:

• Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
• Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

In dem ersten Schlüssel gibt es einen DWORD-Wert AvailableUpdates, der in der Regel auf 0 steht. Er kann mit der Bitmaske 0x5944 konfiguriert werden, was bedeutet, dass alle Updates (UEFI BIOS Zertifikate & Bootloader) ausgeführt werden sollen.

Unter dem zweiten Schlüssel ist der Zustand zu erkennen. Bei mir sieht es so aus:

Werte des Registry-Schlüssels “Servicing”

Interessant sind die beiden Werte:

• UEFICA2023Status: Zeigt “NotStarted”, “InProgress” oder “Updated” an.
• WindowsUEFICA2023Capable: Kennt die Werte 0–2: 0 — Keine 2023er Zertifikate im UEFI BIOS; 1 — 2023er Zertifikate im UEFI BIOS vorhanden; 2 — 2023er Zertifikate im UEFI BIOS vorhanden & System startet über den signierten Bootmanager von 2023.

Weitere Einträge, Infos zu AvailableUpdates sowie zu Fehlern sind in der Dokumentation von Microsoft ersichtlich.

Für das Update selbst ist ein Scheduled Task verantwortlich, der alle 12 Stunden ausgeführt wird. Der Task mit Namen Secure-Boot-Update ist im Task Scheduler unter \Microsoft\Windows\PI* zu finden. Er muss, nach dem Setzen eines korrekten Werts bei AvailableUpdates, zwei Mal ausgeführt werden — jeweils mit Neustarts danach. Nach jedem Durchlauf ändert sich die Bitmaske von AvailableUpdates und auch die anderen Werte wie etwa UEFICA2023Status* passen sich entsprechend an.

Weiter gibt es im Event Viewer Einträge, welche erfolgreiche Updates und Fehler melden. Interessant sind die Event IDs 1801 und 1808. Alles weitere ist bei Microsoft dokumentiert.

Update über Intune anstossen

Das Update kann relativ einfach über Intune konfiguriert werden.

In einer Configuration Policy vom Typ Settings Catalog wird Enable Secureboot Certificate Updates auf Enabled konfiguriert und an die Geräte verteilt. Die Policy erstellt auf den Clients in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot den DWORD-Eintrag AvailableUpdatesPolicy mit dem Wert 0x5944. Er übersteuert, was in AvailableUpdatesPolicy konfiguriert ist und löst so den Update-Prozess aus.

Update-Prozess per Intune Policy anstossen

Danach muss gewartet werden, bis der Sheduled Task ausgeführt wird. Er kann natürlich auch manuell oder auf andere Weise gestartet werden.

In dem Blogbeitrag wird gezeigt, wie geprüft werden kann, ob sich bestimmte Zertifikate im Speicher vom UEFI BIOS befinden oder nicht. Weiter wurde klar, wie die Signaturen der Windows Bootloader effektiv überprüft werden können. Das Wissen über die Unterschiede von eingebetteten Signaturen und Signaturen über Katalogdateien kann zukünftig wertvoll sein, wenn andere Dateien, etwa ein Treiber, analysiert werden muss.

Die Tipps rund um das Update der Signaturen, Zertifikate und CAs bezüglich Secure Boot helfen womöglich einem Admin, seine Umgebung auf den neusten Stand zu bringen und sicherzustellen, dass Geräte auch zukünftig booten.

Ein Hinweis zu guter Letzt: Auch Server, Linux Systeme (wenn sie Secure Boot einsetzen) und USB-Sticks mit Images sind betroffen und benötigen zukünftig korrekt signierte Bootloader. Spätestens wenn Microsoft & co. entscheiden, die alten CAs und Bootloader in den dbx einzutragen, wird es düster für Systeme ohne Update.