[quote=John-Boy post_id=457402 time=1777532837 user_id=38926]HP ProBook 470 G5 mit BIOS 01.31.00 Rev.A vom 11. Feb. 2025[/quote]
Hat HP beim BIOS 01.31.00 Rev.A Upate ein CA 2023 Zertifikat zur KEKdefault und DBdefault hinzugefügt?
(Get-SecureBootUEFI -Name KEKdefault -Decode).Subject | Select-String -Pattern "CA 2023"
(Get-SecureBootUEFI -Name DBdefault -Decode).Subject | Select-String -Pattern "CA 2023"
(Get-SecureBootUEFI -Name KEKdefault -Decode).Subject
(Get-SecureBootUEFI -Name DBdefault -Decode).Subject

[quote]Muss ich wohl auf eine Lösung von HP warten :betruebt:[/quote]
Gibt es ein aktiven Punkt im HP UEFI:
Reiter Security / BIOS Sure Start / Sure Start Secure Boot Keys Protection.

Das UEFI blockiert Secure Boot Änderungen mit dieser Einstellung.
Diese Einstellung kann nur lokal am Laptop geändert werden.
Deaktiviere den Punkt im UEFI, um Änderungen zu erlauben.

(Get-SecureBootUEFI -Name PK -Decode).SerialNumber

[quote=John-Boy post_id=457404 time=1777535742 user_id=38926]Die Reg. sieht so aus[/quote]
Da ist ein KEKLastUpdateError gesetzt.

Hat HP KEK bereitgestellt?
Lese die SerialNumber vom PK Platformkey aus.
[CODE](Get-SecureBootUEFI -Name PK -Decode).SerialNumber[/CODE] Gibt es die Nummer (ohne führende Nullen) in der KEK Update Liste?https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/kek_update_map.json

Bin erst mal zwei, drei Tage weg...

Der steht auf "Pause". Wird kein Update installieren und das System bootet noch mit dem CA 2011. Da hilft nur abwarten. Aber wenigstens wird dadurch auch der Widerruf des CA 2011 nicht ausgeführt.

Die Reg. sieht so aus
[img]https://i.postimg.cc/7L0p8VxN/Zwischenablage-20260430-01.jpg[/img]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Die Einträge in der Registry sind eventuell etwas ausführlicher:

[code]HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing[/code]

Aber da dürfte jetzt auch nur drinstehen, dass es auf "Pause" steht. Aber eventuell steht da der Grund, warum das so ist. Aus irgendeinem Grund hat die gesammelte Telemetrie ergeben, dass ein automatisches Update bei dem Gerät gar nicht oder nicht zuverlässig möglich ist. Aber das kann dann letztendlich nur Microsoft zusammen mit HP klären.

Und wie es bodu schon geschrieben hat, wenn ds UEFI-Setup eine Option dafür bietet, könnte man auch versuchen, die .bin Dateien manuell in das UEFI zu schreiben. Aber das ist auch nicht so einfach. Gerade nach dem April Update ist das etwas unübersichtlich mit dem .bin Dateien geworden. Bis März war das noch einfacher.

[quote=bodu post_id=457401 time=1777487306 user_id=45968]
Welches HP-Gerät wird verwendet?
[/quote]


HP ProBook 470 G5 mit BIOS 01.31.00 Rev.A vom 11. Feb. 2025 (gibt kein neueres)
in der Ereignisanzeige sind keine Einträge
Bitlocker ist deaktiviert

Muss ich wohl auf eine Lösung von HP warten :betruebt:

[quote=John-Boy post_id=457399 time=1777480149 user_id=38926]Ist mein HP-Gerät ist auf einer Liste von Systemen, bei denen ein Secure-Boot-Update Probleme machen könnte?[/quote]
Das deutet auf einen Sonderfall, das HP UEFI kann Änderungen blockieren.
Gibt es Einträge in de Ereignisanzeige, System, Filter Quelle TPM-WMI
Z.B. "The Secure Boot update KEK 2023 was blocked due to a known firmware issue on the device.

Manchmal lässt sich das KEK CA 2023 im HP UEFI einspielen, oder im Setup Mode Signaturen einspielen.
Gibt es ein Bitlocker Wiederherstellungsschlüssel?

Edited:
Welches HP-Gerät wird verwendet? Für alte Geräte bietet HP kein BIOS Update, ein manuelle Lösung wird in Aussicht gestellt.
Support for HP PCs outside of service life
https://support.hp.com/us-en/document/ish_13070353-13070429-16

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
[img]https://i.postimg.cc/FK8YsgXq/2.jpg[/img]
[quote]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.[/quote]

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

[quote]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.[/quote][quote]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.[/quote]

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.

@DK2000

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

Gruß Grobi847

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.

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

Bei mir hat sich unter Servicing folgendes geändert:

ConfidenceLevel = Under Observation - More Data Needed

geändert auf

ConfidenceLevel = High Confidence

@bodu:

[quote]Die PCA 2011 und SVN DBX Einträge können manuell angefragt werden. [/quote]
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.

[quote]Das genannte Script mit 'Fail 3' berücksichtigt das noch nicht. Hier ist Geduld angebracht. [/quote]
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.

[quote]Die Ausgabe erinnert stark an securebootrecovery.efi[/quote]
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.

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. :ohno: