Leidiges Thema Secure Boot Zertifikate [Hilfe]

[DK2000]

Mit der "Check UEFI PK, KEK, DB and DBX.cmd". Der liest den Wert wohl direkt aus dem UEFI aus, wenn ich den Code richtig verstehe. Sicherheitshalber hatte ich aber auch im UEFI selber nachgeschaut und der Hash für den Eintrag ist noch der vom SVN 7. Da kam bislang noch kein neuer Eintrag hinzu.

Noch einmal getestet, um wirklich sicher zu sein. Das Skript liest den Wert direkt aus dem UEFI. Wenn ich den besagten Eintrag im UEFI lösche, ändert sich die Ausgabe:

Screenshot 2026-04-21 105808.png

SVN 7 ist raus. Also passt das mit dem Skript. Aber erneut über Windows in die DBX eintragen, geht gerade nicht. Kommt nur mit:

DBXSVNLastUpdateError: 80070002 (= Datei nicht gefunden)

Kommt jetzt bei mir in Retail und Release Preview nach manuellem anstoßen des SVN Updates. Egal. Wird schon eine passende Datei erscheinen.

Ah ja, selbst das mag er gerade nicht.

DBXPCA2011RevokeLastUpdateError: 80070002 (= Datei nicht gefunden)

Jedenfalls in der 25H2 Retail. Na mal weiter beobachten.

[Tante Google]

[Sam2]

DK2000
Danke fürs Testen.
Mal ganz simpel gefragt: Sollte das nicht ausreichen?

[moinmoin]

Damit hast du alles, was notwendig ist. Besser geht nicht

[Sam2]

Damit hast du alles, was notwendig ist. Besser geht nicht

Das ist mein allerletzter Beitrag zu diesem Thema!
Schluss, Ende, Feierabend!

Klarer und deutlicher geht es nicht.
Die Antwort von moinmoin ist vielleicht auch für andere User interessant.

[CUEFIDBXFail3]

Defender sagt:
Der sichere Start ist aktiviert und alle Zertifikate ok, nichts weiter erforgerlich - wirklich?

Nun nach dem 25H2-04 Update - Fail 3
Current UEFI DBX - 2025-10-14 (v1.6.0) [x64] : FAIL: 3 failures, 428 successes detected

Code: Alles auswählen

Checking for Administrator permission...
Running as administrator - continuing execution...

24 April 2026
Manufacturer: HP
Model: HP
BIOS: AMI, F.26
Windows version: 25H2 (Build 26200.8246)

Detected x64 UEFI architecture. Ensure that this is correct for valid DBX results.
Secure Boot status: Enabled

Current UEFI PK 
√ HP UEFI Secure Boot PK 2017
Default UEFI PK
√ HP UEFI Secure Boot PK 2017
Current UEFI KEK 
√ Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False) 
√ HP UEFI Secure Boot KEK 2017

Default UEFI KEK
√ Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)
√ HP UEFI Secure Boot KEK 2017

Current UEFI DB
√ Microsoft Windows Production PCA 2011 (revoked: True)
X Microsoft Corporation UEFI CA 2011
√ Windows UEFI CA 2023 (revoked: False)
√ Microsoft UEFI CA 2023 (revoked: False)
√ Microsoft Option ROM UEFI CA 2023 (revoked: False)
√ HP UEFI Secure Boot DB 2017

Default UEFI DB
√ Microsoft Windows Production PCA 2011 (revoked: True)
X Microsoft Corporation UEFI CA 2011
√ Windows UEFI CA 2023 (revoked: False)
√ Microsoft UEFI CA 2023 (revoked: False)
√ Microsoft Option ROM UEFI CA 2023 (revoked: False)
√ HP UEFI Secure Boot DB 2017

Current UEFI DBX
2025-10-14 (v1.6.0) [x64]   : FAIL: 3 failures, 428 successes detected
Windows Bootmgr SVN         : 8.0
Windows cdboot SVN          : 3.0
Windows wdsmgfw SVN         : 3.0
Statistics                  : 24435 Bytes, 470 SHA256 hashes, 1 X.509 certs, 4 SVNs

Drücken Sie eine beliebige Taste . . .

[Opa Olaf]

Bei meinen MSI Thin 15 B12UC-1437DE Laptop half mir folgende Vorgehensweise.
https://de.msi.com/faq/faq-11370
Dieses Secure Boot Recovery Tool genau nach Anweisung ausgeführt und Neustart brachte über WU innerhalb von 10 Minuten
"Update der zulässigen Signaturdatenbank (DB) für sicheren Start" Und alles sieht soweit gut aus in Registry und dem Sicheren Start.
Da es sich um ein Microsoft Secure Boot Recovery Tool handelt dürfte es auch auf andere Systeme anwendbar sein.
Aber bitte auf eigene Gefahr!

[bodu]

Der sichere Start ist aktiviert und alle Zertifikate ok, nichts weiter erforgerlich - wirklich?

Die Aussage 'nichts weiter erforderlich' bezieht sich auf die aktuelles Windows Update Verhalten: KEK und DB CA 2023. PCA 2011 wird zur Zeit nicht in der DBX gesperrt. Demnach ist zur Zeit nichts weiter erforderlich.

Die PCA 2011 und SVN DBX Einträge können manuell angefragt werden.
In der Konsequenz sind die Bootmedien auf die monatlich aktuelle SVN anzupassen.

Die nicht dokumentiereten Spielregeln haben sich im April geändert.
Z.B. gibt es Dateien C:\Windows\System32\SecureBootUpdates\DBXUpdate2024.bin und
C:\Windows\System32\SecureBootUpdates\DBXUpdate2024Legacy.bin
Das genannte Script mit 'Fail 3' berücksichtigt das noch nicht. Hier ist Geduld angebracht.
Da scheint etwas auf kleineren NVRAM Speicherbedarf mit PCA 2011 in dbx vorbereitet zu werden.

Dieses Secure Boot Recovery Tool genau nach Anweisung ausgeführt und Neustart brachte über WU innerhalb von 10 Minuten
"Update der zulässigen Signaturdatenbank (DB) für sicheren Start" Und alles sieht soweit gut aus in Registry und dem Sicheren Start.

Die Ausgabe erinnert stark an securebootrecovery.efi
viewtopic.php?t=34066&start=105#p456756

Prüfe noch auf den KEK Eintrag 'KEK 2K CA 2023'

Code: Alles auswählen

(Get-SecureBootUEFI -Name KEK -Decode).Subject 

[Opa Olaf]

PowerShell 7.6.1
PS C:\Users\oweid> (Get-SecureBootUEFI -Name KEK -Decode).Subject
CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US

Noch eine Frage: Wenn man jetzt im Bios unter Secure Boot diese Factory default Keys wieder laden würde. Sind dann die neuen Keys wieder verschwunden? Ich vermute mal das es so ist und werde das nicht testen.

[DK2000]

@bodu:

Die PCA 2011 und SVN DBX Einträge können manuell angefragt werden.

DBX SVN hat er bei mir jetzt automatisch in der 25H2/26H1 (jeweils Retail/Release Preview) eingetragen. Da musste ich nicht weiter machen. Nur in den Insidern Beta/Dev/Canary ist das noch anders. Da steht DBX SVN noch auf 5.0 und die Canary-Kr hat den Bootmanger mit SVN 9.0. CA 2011 wurde bei mir noch nirgends widerrufen. Habe ich nur so mal nebenbei in der Canary-Kr manuell eintragen lassen.

Das genannte Script mit 'Fail 3' berücksichtigt das noch nicht. Hier ist Geduld angebracht.

Bei mir ist alles "Grün". 431 von 431 Einträgen vorhanden (s. Screenshot von mir weiter oben) Und wenn ich mir da Screenshots von anderen Usern anschaue, passt das auch mit 431 Einträgen. Warum das jetzt bei CUEFIDBXFail3 anders ist, kann ich nicht sagen.

Das hat er seit einer Weile in allen Kanälen aktualisiert (VMs und Tablet). Das aktuelle Skript berücksichtigt das. Es verwendet zum Prüfen die eigentlich aktuelle DBXUpdate.bin vom Oktober 2025. Allerdings ist das nicht die aktuelle DBXUpdate.bin aus dem Update. Die neue ist deutlich kleiner. Keine Ahnung, was da jetzt wieder der Plan von Microsoft ist. Eventuell muss DBXUpdate.bin und DBXUpdate2024.bin gleichzeitig installiert werden. Oder eine andere Kombination.

Vielleicht müsste ich mal wieder die DBX aus dem UEFI löschen und mal schauen, was dann passiert. Obwohl müsste ich dann wohl manuell machen, da dank UEFI-Update ist das alles wieder nicht mehr als "High Confidence" eingetragen. Oer muss warten, bis wieder genug Daten zum neuen UEFI zusammenkommen.

Die Ausgabe erinnert stark an securebootrecovery.efi

Ist dasselbe Tool, nur schon in bootx64.efi umbenannt, so dass man es gleich auf einen Stick oder in die ESP kopieren kann. Aber die genau Funktionsweise ist mir da noch nicht ganz klar. Ich habe es mal wieder ausführen lassen und das Einzige, was es gemacht hat, war das widerrufene CA 2011 wieder als nicht-widerrufen aktualisiert. Alles andere hat sich nicht verändert.

[Grobi847]

Bei mir hat sich unter Servicing folgendes geändert:

ConfidenceLevel = Under Observation - More Data Needed

geändert auf

ConfidenceLevel = High Confidence

[Grobi847]

Ich weiß nur nicht wann, und durch was sich der Eintrag in der Reg-DB geändert hat.
hat da einer von den Spezis einen Tipp?
Gruß Grpbi847

[DK2000]

Das macht der Updater.

Der schaut in der passenden .json Datei in "C:\Windows\System32\SecureBootUpdates\BucketConfidenceData.cab" nach und wenn der den Hash in der Liste "High Confidence" vorfindet, welcher in der Registry unter "BucketHash" steht, dann wird das auch so in der Registry eingetragen. Es wurden dann genug Daten gesammelt, so dass Dein System als "High Confidence" angesehen werden kann und die Updates sollten automatisch erfolgen.

[Grobi847]

@DK2000

Danke für die Info.
Warum wird aber dieses Update nirgends dokumentiert?

Gruß Grobi847

[DK2000]

Das steht in den Release Notes vom KB5083769 (26200.8246):

With this update, Windows quality updates include additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Devices receive the new certificates only after demonstrating sufficient successful update signals, maintaining a controlled and phased rollout.

Mit diesem Update beinhalten die Windows-Qualitätsupdates zusätzliche hochvertrauende Gerätetargeting-Daten, wodurch die Abdeckung der Geräte erhöht werden, die automatisch neue Secure Boot-Zertifikate erhalten können. Geräte erhalten die neuen Zertifikate erst, wenn sie ausreichend erfolgreiche Update-Signale nachweisen und eine kontrollierte und schrittweise Einführung gewährleisten.

Welche Geräte da nun genau neu eingetragen wurden, steht natürlich nirgends. Auch der Wechsel von SVN 7.0 auf SVN 8.0 wurde leider nirgends erwähnt.

[John-Boy]

Ist mein HP-Gerät ist auf einer Liste von Systemen, bei denen ein Secure-Boot-Update Probleme machen könnte?
Der Text deutet darauf hin aber weiteres ist nicht zu erfahren

Sicherer Start
Der sichere Start ist aktiviert, aber Ihr Gerät ist von einem bekannten Problem betroffen. Um das Risiko zu verringern, werden Zertifikatupdates für den sicheren Start vorübergehend angehalten, während Microsoft und Partner auf eine unterstützte Lösung hinarbeiten. Das Update wird automatisch fortgesetzt, sobald es aufgelöst wurde.