[English]Ich stelle mal ein Thema hier im Blog ein, was noch "ein paar Tage Zeit hat", aber arg unangenehme Folgen haben könnte. Im Herbst 2026 läuft ein Zertifikat in Windows aus, welches im UEFI dafür sorgt, dass der Secure Boot ausgeführt werden kann. Zu diesem Zeitpunkt war das Zertifikat 15 Jahre gültig, aber alle Maschinen, die nicht aktualisiert werden, werden zum Stichtag nicht mehr im Secure Boot-Modus starten können.
Anzeige
Windows und das Secure Boot CA
Ich bin die Tage über nachfolgenden Tweet von Gunnar Haslinger auf das Thema gestoßen und stelle es heute mal hier im Blog zur Information ein.
Der Sachverhalt, um des es geht, ist mir wenigen Worten beschrieben. Microsoft nutzt ein UEFI-Zertifikat, welches sich in einer Datenbank befindet. Das von Microsoft in Windows propagierte Secure Boot greift auf dieses Zertifikat zu, um die Integrität zu prüfen. Secure Boot hängt also von der Gültigkeit dieses Zertifikats ab. Ist das Zertifikat in der Datei bootmgfw.efi auf der UEFI-Partition ungültig, kann die Maschine nicht mehr im Secure Boot starten.
Eine Beschreibung der Secure Boot-Abläufe und -Hintergründe lässt sich in diesem Blog-Beitrag nachlesen.
Das Windows Production PCA 2011
Das bisher verwendete Zertifikat wurde aber vor langer Zeit, konkret im Jahr 2011, ausgestellt und läuft am Montag, den 19. Oktober 2026, nach 15 Jahren Gültigkeit, aus. Maschinen, die Secure Boot verwenden und bis zu diesem Zeitpunkt nicht aktualisiert wurden, können dann nicht mehr starten. Das dürfte vor allem Windows-Systeme betreffen, die keine Updates per Internet erhalten.
Anzeige
Das Black Lotus-Problem
Mit den Sicherheitsupdates von Mai 2023 hat Microsoft ja versucht, die Schwachstelle im Secure Boot, die durch die Hackergruppe BlackLotus und deren UEFI-Bootkit ausgenutzt wird, zu schließen. Die Schwachstelle CVE-2023-24932 bezieht sich auf eine Sicherheitslücke in dem in Windows-Betriebssystemen verwendeten Secure Boot, die das Ausführen nicht vertrauenswürdiger Software während des Startvorgangs ermöglicht.
Ich hatte im Blog-Beitrag BlackLotus UEFI-Bootkit überwindet Secure Boot in Windows 11 berichtet. Und im Beitrag Windows und das (BlackLotus) Secure Boot-Desaster: Wie ist bei euch der Status? bin ich auf die Problematik eingegangen, dass Administratoren manuell eingreifen müssen, um den Secure Boot abzusichern.
Neues Windows UEFI CA 2023
Um das Problem mit dem auslaufenden Zertifikat zu lösen, hat Microsoft das Update KB5025885 zur Absicherung bereitgestellt (siehe KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus) vom Mai 2023). Es gibt zudem einen Supportbeitrag zum Update KB5025885, in dem sich der Hinweis findet, doch das Windows-Sicherheitsupdate vom 9. Juli 2024 oder ein späteres kumulatives Sicherheitsupdate unter Windows zu installieren, um die benötigten Absicherungen gegen Black Lotus zu bereitzustellen.
In diesem Blog-Beitrag findet sich auch der Hinweis, dass mit dem Update ein neues Zertifikat (Windows UEFI CA 2023) bereitgestellt wird, um das alte Windows Production PCA 2011 zu ersetzen. Administratoren in Unternehmensumgebungen finden im Supportbeitrag zu KB5025885 entsprechende Hinweise, welche Schritte zusätzlich auszuführen sind. Wer seine Windows-Systeme mit einem Schutz vor Black Lotus und der Secure Boot-Schwachstelle CVE-2023-24932 versieht, ist auch auf das oben skizzierte Szenario eines auslaufenden UEFI-Zertifikats vorbereitet.
Im Laufe des Jahres 2024 führt Microsoft dann verschiedene Härtungsmaßnahmen aus, die ich im Blog-Beitrag Update zur Windows-Härtung in 2024/2025 – Stand März 2024 angerissen habe. Auf neowin.net gibt es diesen Artikel, der ebenfalls auf die Härtungsmaßnahmen hinweist.
Ähnliche Artikel:
BlackLotus UEFI-Bootkit überwindet Secure Boot in Windows 11
KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus)
Update zur Windows-Härtung in 2024/2025 – Stand März 2024
Anzeige
Wer sich böse Überraschungen im Oktober (Enforcment by Microsoft) sparen will, sollte jetzt anfangen zu testen. Auf garytown.com gibt es Powershellscripte, welche alle von MS beschriebenen Schritte abarbeiten (es sind ja mehrere Reboots erforderlich). Das ganze packetiert und dann ausgerollt. Bei uns bis dato keine Probleme. Danach nicht vergessen, alle Bootmedien anzupassen.
https://garytown.com/configmgr-task-sequence-kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932
Danke!
Danke!
Guten Morgen zusammen,
hab gerade die Datei C:\Windows\Boot\EFI\bootmgfw.efi kontrolliert und hier ist noch das alte CA2011 Zertifikat installiert.
Hätte das nicht im Juli kommen sollten?
Das ganze Thema ist mir etwas unschlüssig. Wird das noch automatisiert?
Kommt da noch was, oder muss man selbst "rumpfuschen"?
Besten Dank und eine schöne Restwoche
Sebastian
In diesem verlinkten Supportbeitrag KB5025885 steht noch eine ganze Menge Krämpel drin, der zusätzlich gemacht werden muss.
Da muss ein riesen Geschiss gemacht werden. Da muss das Zertifikat in diese Datenbank installiert werden und dann ein neuer Bootmanager, der dann mit dem neuen Zertifikat signiert ist, erstellt werden. Aber schon beim ersten Schritt gibt es bei einigen wohl Probleme (siehe Known Issues unten). Ich habe da kein Bock drauf.
Ok …
habe gerade gesehen dass die C:\Windows\Boot\EFI\bootmgfw.efi bei uns nur bis 14.11.24 geht … ich blicks nicht
In der Registry is an meinem PC der key vorhanden
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000002
Das habe ich auch, aber die Gültigkeit beginnt am 16.11.2023, das kann also nicht das fragliche Zertifikat sein.
Es geht um das Zwischenzertifikat "Windows Production PCA 2011" im Zertifikatpfad.
ah ok – habs gefunden.
hier steht 19.10.2026
und natürlich auch windows 11 betroffen – hoffe ja, dass bis dahin noch eine einfache Lösung kommt.
Das manuelle rumfuhrwerken an allen Rechnern ist ja wohl n schlechter Witz
Das klingt ja fast beruhigend.
Lt. diverser Artikel in der c't war schon von Oktober 2024 die Rede:
https://www.heise.de/ratgeber/Naechster-Akt-im-Secure-Boot-Drama-Startverbot-fuer-alle-Windows-Bootloader-9709428.html
https://www.heise.de/ratgeber/Windows-Vom-Startverbot-bedrohte-Bootloader-identifizieren-pruefen-reparieren-9649679.html
In der letzten Zeit habe ich dazu aber keine Aktualisierungen gesehen.
Oder werfe ich da was durcheinander?
Das ist ja alles gut und schön. Was hilft mir das, wenn die Installationsmedien von Microsoft derzeit noch immer das alte Zertifikat inkludiert haben. Denn das Juli Update ist bspw. beim aktuellen iso File von Windows 11 23H2, das Home User downloaden können, nicht inkludiert.
Richtig, so wie es auch für Server 2019 keine aktualisierte ISO gab, nur für 2022 (welchen wir nicht einsetzen). Musste dann Secureboot abschalten als ich den Server neu installierte, Danke MS für gar nichts.
Ablaufende Zertifikate, immer wieder ein Segen für die Menschheit.
vor allem was ich nicht verstehe. auf meinem lenovo laptop kann ich im bios sämtliche secure boot keys löschen bzw. ein restore factory keys durchführen. wie will microsoft das verhindern. die factory keys sind ja wohl für das schlechte zertifikat dann.
oder muss jeder bios hersteller, dann explizit ein update machen, dass die factory keys aktualisiert?
Jep, die kommen wohl vom Mainboardhersteller (in diesem Fall Lenovo) https://learn.microsoft.com/en-us/answers/questions/1423466/what-is-install-the-default-secure-boot-keys-optio . Einfach krank wie das gehandhabt wird. Es reicht ja nicht das sich die Hersteller die Keys klauen lassen ( https://www.borncity.com/blog/2024/08/02/pkfail-und-weitere-uefi-fehler-gefhrden-tpm-und-systeme/ ) und "do not ship"-Versionen ausliefern, jetzt laufen die Dinger auch noch ab.
Weil du Secureboot leider nicht verstehst.
Seh dir mal die Spec and und sag mir was die Firmware im BIOS mit dem .efi File des OS zu tun hat? Richtig, nix. Die haben eigene certs.
Die Kette wird eben Schritt für schritt abgelaufen:
[https://i.imgur.com/KJcCGZP.png]
[https://i.imgur.com/wMs3eko.png]
Addendum:
[https://i.imgur.com/wMs3eko.png]
ok. ich hab mal spasseshalber alle keys im uefi bios für secure boot löschen lassen. warum bootet danach kein windows mehr bzw. kein usb stick mit windows installer wenn es da absolut keinen zusammenhang gibt?
erst als ich restore factory keys machte, war ich wieder in der lage den windows installer usb stick zu booten.
Leider verstehen Sie das auch nicht.
Wie ich schon in einem anderen Beitrag geschrieben habe ist mir die ganze Secure Boot Funktion, so wie sie momentan gelebt wird, absolut suspekt. Daher ist das bei uns grundsätzlich abgeschaltet und das werde ich auch bei neuen Rechnern weiterhin machen.
Ich verstehe aber auch nicht, warum MS es ganz offensichtlich nicht hinbekommt, sowas per Automatik auszurollen. Nein, es sind wieder zig manuelle Schritte nötig, damit das funktioniert. So wie auch seinerzeit bei dem tollen Update für die WinRE, wo sie es dann irgendwann einfach aufgegeben haben.
Und da soll nochmal jemand kommen und behaupten, Linux wäre ein "Frickelsystem". Das kann man von Windows inzwischen durchaus auch behaupten.
Wie lässt du dann Windows 11 sicher laufen?
Unsere Softwareverteilung installiert das auch bei deaktiviertem Secure Boot via PXE und das ganz ohne irgendwelche Eingriffe. Läuft auch problemlos, auch mit Updates. Secure Boot ist ganz offensichtlich technisch nicht erforderlich dafür.
Was für ein ätzender Prozess. Hab es jetzt bei meinem Laptop und einem Server durchgeführt. Lief zum Glück problemlos. Alles weitere wird man dann sehen, wenn die Zertifikate wirklich ausgetaucht werden irgendwann in der Zukunft. Am Hyper-V Host würde ich dringend empfehlen den Autostart der VMs über die ganze Zeit auf "Aus" zu stellen. Der rödelt sich sonst nur einen ab bei den 10 Neustarts, die man machen muss :)
hätte ich nicht gemacht. oder hast du installations- und recovery medien, die die neuen keys schon inkludiert haben?
KB-Artikel ganz gelesen? Dort wird erklärt, wie man ein Recovery Medium anschließend selbständig erstellen kann. Ich habe das jetzt nur auf der alte Kiste durchgeführt. Der neue Server hat anscheinend die neuen Signaturen schon geladen. Zumindest hat da der Befehl zum überprüfen der Datenbank ohne mein Zutun sofort "True" angezeigt.
Oh ich habe auf einer (offline betriebenen) Produktionsmaschine einer Anlage folgenden interessanten Fall entdeckt. Das Cert für die bootmgfw.efi eines Win2019 ist bereits im Februar 2024 abgelaufen. Die Intermediate in der Kette ist die besagte PCA 2011, gültig bis 2026.
Muss ich jetzt Sorge haben, dass die Kiste nicht mehr bootet?
Ich glaub das muss ich mir heute mal anschauen..
meines von meinem firmen pc ist bis 14.11.2024 gültig. darüber hab ich mir aber noch keine gedanken gemacht. ich nehm an das wird microsoft ja mit irgendeinem mechanismus aktualisieren.
Habe das gerade getestet, die Kiste bootet (warm) zumindest durch. Also ein abgelaufenes Cert allein ist noch kein KO Kriterium, kann es auch nicht sein, weil die besagte Kiste recht frisch 2023 erst installiert wurde. Erst wenn der besagte Intermediate 2026 ausläuft wirds ernst.
Da wird Crowdstrike harmlos gegen wirken wenn MS das vermasselt. Die Chancen stehen gut, hoffen wir mal ;-)
Daumen drücken und abwarten :-) .
sie haben das winre ja auch vermasselt.
wenn ich privat mein lenovo t590 installiere, wo ich ins ms iso grad mal die chipset treiber reinpackte. kracht das cu beim winre part. weil initial die winre partition von ms mit 783MB angelegt wird, wo dann noch 20 MB oder so frei sind. ich habs dann mal auf 2GB vergrössert, das cu deinstalliert und wieder installiert und schon wird winre aktualisiert.
einziger nachteil, wenn man an der winre partition hand anlegt erscheint die plötzlich als partition in der systemwiederherstellung. keine ahnung wie man das dem ding abgewöhnen kann. stört mich aber vorerst nicht.
der windows os installer ist ja auch strunz dumm. selbst wenn ich am ende der disk beim paritionieren noch platz lassen würde. wird das ignoriert und er erstellt halt fix seine 783MB winre partition.
>>> wenn man an der winre partition hand anlegt erscheint die plötzlich als partition in der systemwiederherstellung. keine ahnung wie man das dem ding abgewöhnen kann. <<<
S. (1) ab "The common steps are:".
(1) learn.microsoft.com/en-us/answers/questions/427448/how-to-properly-hide-a-recovery-partition
ich hab das gemacht
https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf
und nun?
willst mir erklären, dass die anleitung von Microsoft Mist ist? Vor allem in deinem Diskussionsthread geht es um mbr partitionen. derartige habe ich nicht. ich habe gpt
und die partition hat auch keinen pfad oder laufwerksbuchstaben. daher kann auch keiner entfernt werden
vergrössere doch einfach mal auf einem windows 11 testsystem die recovery partition gemäß. https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf
und dann schau bei Systemwiederherstellung und du wirst nehmen C auch diese Windows RE tools Partition finden, die Systemwiederherstellung auf aus hat. Vor der Erweiterung ist sie nicht vorhanden. Und nun bitte erklär mich nochmal wie man dieses Verhalten abstellen kann.
Die WinRE muss an die Systempartition anschließen. Mit <=1GB erscheint sie nicht mehr in der Systemwiederherstellung.
Vielen Dank für die Information. Das erklärt es. Ich hab meine WinRE Partition Sicherheitshalber 2GB gross gemacht. Ist das Verhalten bei MS dokumentiert oder hast du das durch Probieren rausgefunden?
Hallo Zusammen,
irgendwie sehe ich den Wald vor lauter Bäumen nicht :)
unter C:\Windows\Boot\EFI
die bootmgfw.efi angeschaut und bei uns steht folgendes drinnen:
Ausgestellt für: Microsoft Windows
Asugestellt von: Microsoft Windows Production OCA 2011
Gültig ab 16.11.2023 bis 14.11.2024
sind wir die Beta Tester und deswegen wird es bei uns im November 24 schon ungültig ? :)
Nein, das ist richtig. Das Signaturzertifikat von bootmgfw.efi heißt Microsoft Windows und läuft am 14.11.2024 ab. Soviel ich weiß, ist das bei Signaturzertifikaten nicht weiter schlimm, weil die eine Gegensignatur von einem TimeStamp-Server besitzen (sollten). Der bestätigt, dass zum Zeitpunkt der Signatur das Zertifikat gültig war. Sonst würde ganz viel Software nicht mehr ausgeführt werden können. Die Zwischenzertifizierungsstelle, die siehst du, wenn du beim Zertifikat auf den Reiter Zertifizierungspfad wechselst, das in der Mitte, das Microsoft Windows Production PCA 2011, das im Oktober 2026 abläuft. Aber auch das wäre kein Problem. Problem ist, dass Microsoft die Lücke CVE-2023-24932 so löst, dass das Zertifikat der Zwischenzertifizierungsstelle irgendwann (Date to be announced – Enforcement Phase) fix widerruft und in die Secure Boot UEFI Forbidden List (DBX) einträgt. Und dann geht nix mehr.
Bitte sagst mir, wenn ich was falsch verstanden habe! Danke!
>>> Erst wenn der besagte Intermediate 2026 ausläuft wirds ernst. <<<
Da mal bitte ein Beispiel aus der Vergangenheit. Der gewichtigste Fall von ungültig ist, wenn das Zertifikat selbst abgelaufen ist. Ist dieser Ablauf unkritisch, dürfte sich der Ablauf eines Intermediates erst recht nicht bemerkbar machen.
Dann könnte man sich das ganze System aber so auch gleich sparen (oder das Zert für 50 Jahre ausstellen), oder?
…vielleicht habe ich mich missverständlich ausgedrückt. So wie ich die KBs lese wird es in der letzten Deployment Phase von MS aktiv blockiert.
"we are adding the "Windows Production PCA 2011" signing certificate to the Secure Boot Disallow List (DBX) to untrust all boot managers signed by this certificate. This is a more reliable method for ensuring that all previous boot managers are untrusted."
Never the less… das wird ein Gaudi, den viele (noch) nicht am Schirm haben…. noch können wir wetten ;-)
Microsoft hat offenbar mit dem Juli-Update begonnen, die Sache schrittweise umzusetzen, wenn auch lt. Artikel nicht aktiviert. Bei uns ist auf jeden Fall PCR 4 zusätzlich zu 7 und 11 aktiviert worden. Wir hatten zum Glück keine Rechner, die ein BitLocker-Recovery benötigt hätten. Allerdings wundert es mich nicht, dass bei dem Update das bei manchen Rechnern auftritt. Microsoft tut ja so, als wüssten sie nicht weshalb das vorkommen kann: "We are investigating the issue and will provide an update when more information is available."
Das Juni-Update funktioniert nicht mit TPM 2.0. Mai-Update benutzen.
Korrektur,
Das Juli-Update funktioniert nicht mit TPM 2.0. April-Update benutzen.
Übrigens, das aktuelle Thunderbird-Update scheint buggy zu sein, wurde bei mir gestern automatisch aktualisiert, seit dem ist das User-Interface größtenteils englisch, nur wenige Menüeinträge, Dialoge, Icon-unterschriften usw. sind in Deutsch. Sicher uninteressant für diesen Blog…
es ist weitgehend "uninteressant für diesen Blog, was Firefox, Edge und Thunderbird" meinen updaten zu müssen. Ich habe lange genug berichtet. Hat allenfalls ein paar hundert Leser interessiert (letzter TB-Artikel hat 356 Abrufe). Ergo schreibe ich über ausgesuchte Themen, zu denen ich Bock habe, und die mir wichtig sind. Da passt es auch mit den Abrufen.
PS: Gerade den TB auf Nebula updaten lassen – hier auf den schnellen Blick alles in Ordnung. Ich könnte mich fragen "was mache ich falsch, dass ich …" – aber diese Fragen sind es mir nicht wert ;-)
Finde ich gut, dass du dich jetzt auf die wesentlichen Themen fokussierst. Die Aktuelle auswahl ist interessant und gut selektiert!
Kann ich nicht bestätigen. Hab manuell installiert und alles ist noch auf deutsch.
Gruß
>das aktuelle Thunderbird-Update scheint buggy zu sein
Da es *auch* für TB wie FF mehrere Kanäle gibt kann man das pauschal nicht behaupten. TB ESR-Kanal 128.1.0 läuft perfekt und FF DevEd 130.0b1 ebenso. Rest teste ich nicht.
Was ist jetzt mit all den Windows RT tablets bei denen man SB nicht ausschalten kann, und die keine updates mehr erhalten.
Sind die jetzt Elektroschrott?
Und wen ja kann man MSFT in regress nehmen?
Wenn das so ist ist es ja ein versteckter Kill-switch der beim kauf nicht offen gelegt wurde, das ist IMHO kriminell.
Falls sie aus Österreich schreiben:
Eine uneingeschränkte, außergerichtliche, entgeltliche rechtliche Beratung im Einzelfall dürfen demnach nur bestimmte Personen in Deutschland vornehmen, nämlich im Wesentlichen nur Rechtsanwälte, Rechtsbeistände, Steuerberater und Patentanwälte.
1. Es steht IMHO dabei daher ist es eine Meinung meine Meinung und wir haben Meinungsfreiheit.
2. In AT gibt es keine Abmahnungen von daher ist e'h alles egal.
Kann Ihnen trotzdem nicht sagen, wie sie gegen MS vorgehen können ;)
Ich gar nciht da ich solchen mist in weiser vorraussicht gar nciht erst kaufen.
Aber wäre schon lustig wenn alle die noch so ein untaugliches gurken tablet irgendwo in der lade herumliegen haben auf einmal einpaar 100€ von MSFT einklagen könnten.
Das würde mich sehr freuen.
Einfach verkaufen und bei diesen [kreatives Wort] nie wieder einkaufen!
So mache ich das jedenfalls. Ist zwar nicht nett, aber wenigstens ärgert sich jemand anderes. Noch geht die Hardware ja noch, oder? Also ist ein Verkauf legitim. Wenn MS den anderen Secondhand-Käufer reinlegt, waren Sie es nicht!
In diesem Sinne, Verzeihung für mein autistische Antwort, aber ich kann wirklich nicht helfen, keiner hier kann das. Alles was ärger macht: Verkaufen, solange es funktioniert!
>>> Eine uneingeschränkte, außergerichtliche, entgeltliche rechtliche Beratung … <<<
Eine solche – insb. eine entgeltliche – hat der Nutzer DavidXanatos auch nicht begehrt. Können Sie sich Ihre Frustration nicht anders von der Seele schreiben?
Mensch das war ein Witz! Leute wollen immer gleich Firmen verknacken oder wissen was man tun soll. Das kann aber faktisch nur ein rechtsbeistand.
Habe doch oben geschrieben ein Verkauf von funktionierender Hardware die vom OEM bald EOL wird ist legitim. Es muss ja nur beim Verkauf gehen. Der Kunde wird ja von MS hängen gelassen, sollte kein Update kommen.
Hier sind trotzdem keine Anwälte die verbindlich erklären können was sonst geht. Eine Rückgabe von Elektrogeräten weil Updates nicht kommen wäre ein schönes Gesetz in der Fantasiewelt wo alles fair ist.
Die wurden bis 2015 Hergestellt. Der Support für Windows 8.1 ist ende 2023 abgelaufen.
Große OS Updates werden damit wahrscheinlich auch nicht gehen. Die Dinger haben ja nur 1-2GB RAM. Das war damals schon sehr wenig.
Mit Windows 8.1 wird man in Zukunft nicht mehr viel machen können.
Selbst Sky hat zuletzt angekündigt, das die Sky Go App nicht mehr unter Windows 7 und 8.1 unterstützt wird.
Was würde eigentlich passieren, wenn man das Gerät Offline in das UEFI startet und darin das Datum zurückstellt?
Würden dann die Surface RT Geräte wieder das Installierte Windows starten?
Falls Juristerei irgendetwas mit gesundem Menschenverstand zu tun hat, könnte es so laufen:
Du verklagst Microsoft, bekommst vor Gericht recht, und Microsoft wird dazu verurteilt, Dir den Zeitwert des nicht mehr benutzbaren Geräts in Höhe von 20 Euro zu ersetzen.
Ich hab mir jetzt fast 3000 unserer Rechner angeguckt und musste folgendes feststellen:
100 Rechner haben folgenden Eintrag in der Registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000002
Die anderen 2900 Rechner diesen hier:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000000
… ich kann aber nirgendwo finden, was der Wert 2 bedeuten soll. 0 scheint der Standardwert zu sein. Dieser wird auch wieder gesetzt, nachdem man die ersten beiden Schritte durchlaufen hat und die .efi Datei erneuert wurde.
Weiß jemand, was der Wert 2 bedeutet?
Gem (1) "Anzahl der verfügbaren Updates für den sicheren Start."
Keine Ahnung was das heissen soll, evtl. etwas wie 'Ihr Secure Boot Mechanismus ist im Patch-Rückstand, Sie müssen noch zwei verfügbare Updates einspielen!'
(1) learn.microsoft.com/de-de/windows/privacy/required-windows-diagnostic-data-events-and-fields-2004
Ein DBX-Update steht bereit. Nach einem Neustart wird es installiert und der Wert ist wieder 0.
Achtung : betrifft auch Windows 11 24H2 IoT …
Ich habe mir die Anwendung des Updates jetzt endlich genauer angesehen. Im Großen und Ganzen ist da nicht viel dabei. Juli 2024 Update installieren, nach und nach 4 Regkeys setzen und den Rechner dazwischen jeweils 2x neu starten. In der Not kann man das mit Group Policy Preferences oder einem Login Script lösen.
Der vielleicht aufwändigere Teil -wenn man es vor hat- überall das BIOS automatisch zu aktualisieren. Weil dann muss vorher der BitLocker angehalten werden usw.
aus meiner Sicht ist das ganz großer Mist:
Im Image ist noch das alte Zertifikat drin, damit wird aktuell das BS installiert.
Dann macht man das Update auf das "Neue" und setzt das alte auf die Sperrliste.
Aber dann:
setzt man Secure Boot im BIOS zurück, bootet das System nicht mehr da das "Neue" nicht bekannt -> lt Anleitung soll man dann USB Stick mit "Rettungs" -Loader erstellen.
Will man das BS auf ein bereits umgestelltes System installieren, wird das wohl auch nicht mehr gehen, da das "alte" ja auf der Sperrliste ist …
Und noch etwas: hier war der Zugrif auf die EFI Partition mit mountvol S: /s nicht möglich.
Erst ein per dispart – assign letter=s auf die EFI Partition brachte abhilfe.
Moin,
ich glaube Windows7 Home Premium hat weder BitLocker noch Secure Boot.
Find ich gut.
Problem wird aber sein, dass Windows 7 im Online-Betrieb in Probleme läuft, da die Unterstützung von Browser-Aktualisierungen etc. drastisch abnimmt. Lokal mit fester Software betrieben -> vermutlich kein Problem. Bei Browsern, Mail-Clients etc. erwartet ich in Zukunft zunehmend Probleme.
Ja, leider wird es immer enger was Browser, Mail-Clients etc. angeht.
Hier mal ein kurzes Update zur Wiederherstellung. Leider habe ich mit anpassen der Boot Medien selber bisher nicht soviel erfolg gehabt. Selbst mit dem erstellten recovery drive ist nach der Wiederherstellung wieder das alte Zertifikat vorhanden. Irgendwas scheint da nicht ganz zu klappen.
Was bisher mehrfach in einer Testumgebung geklappt hat:
-Ursprüngliche Installation per Recovery wiederherstellen.
-Windows wird danach noch nicht booten darum wieder ab in die Recovery und die Eingabeaufforderung öffnen.
-Volume S mounten (efi Partition)
-Notepad.exe starten (umspäter die Veränderung prüfen zu können)
-die bootmgfw.efi vom recovery drive per copy in die efi partition schieben und dort die vorhandene(falsche) Datei überschreiben.
-jetzt kann man in Notepad auf "Öffnen" gehen, zur kopierten bootmgfw Datei navigieren und die Zertifikatfolge überprüfen. Sollte jetzt das 2023 Zertifikat drin stehen.
-Danach reboot und läuft.
Das ganze geht genauso, wenn man secureboot zwischenzeitlich aussetzt, Windows auf übliche Weise neu installiert, und dann die bootmgfw per drag&drop in die S: Partition kopiert. Danach wieder ins BIOS, secure boot aktivieren und läuft.
Wäre gerne über bessere Lösungen offen bezüglich angepasster Boot Medien.
Gruß
Da wäre vielleicht noch zu erwähnen, dass da noch 2 weitere Runden mit gleichem Potenzial kommen:
Der Austausch des third party UEFI CA (Microsoft UEFI CA 2011) und der Austausch des Key Exchange Key CA (Microsoft Corporation KEK CA 2011).
Das third party CA wird für hardware mit eigener Firmware benötigt, bootfähige RAID Controller z.B.. Das KEK CA zertifiziert db und dbx.
MS schreibt dazu:
"Meanwhile, efforts to update the Microsoft UEFI CA 2011 (aka third-party UEFI CA) and Microsoft Corporation KEK CA 2011 will begin late 2024, and will follow a similar controlled rollout process as this DB update."
Quelle:
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/updating-microsoft-secure-boot-keys/ba-p/4055324
Das UEFI CA 2023 kam schon im Februar, KB5036210.
Das Windows UEFI CA 2023 ersetzt das alte Windows Production PCA 2011.
Dass der Name geändert wurde und es jetzt ähnlich heißt, ändert nichts daran, dass weiterhin parallel das Microsoft UEFI CA 2011 als third party CA existiert und auch ersetzt werden muss (zumindest wenn man Hardware mit eigener, zum Booten erforderlicher Firmware hat).
Das UEFI CA 2011 wird nicht widerrufen, da es nicht genutzt wird.
Welcher Teil von
"Meanwhile, efforts to update the Microsoft UEFI CA 2011 (aka third-party UEFI CA) and Microsoft Corporation KEK CA 2011 will begin late 2024"
war unklar? (Quelle ist in meinem ersten Kommentar verlinkt)
Solange secure boot aktiviert ist erkennen zumindest meine HPE Server den (HPE) Raid Adapter weder im Bios noch nutzen sie ihn zum Booten, wenn die Signatur des Microsoft UEFI CA 2011 Zertifikat nicht in der db aufgeführt ist.
(Der Adapter ist dabei sehr wohl vom Betriebssystem aus sichtbar und funktioniert- halt nur nicht für secure boot)
Das UEFI CA 2011 wird nicht ersetzt und nicht ausgetauscht und bleibt gültig in der DB. Im Zitat wird sogar deren Aktualisierung in Aussicht gestellt.
btw
Die meisten, wenn nicht alle Treiber, sind mit dem Production CA 2011 signiert.
Und nicht vergessen, nach der Umstellung/Update funktionert die "alte" Backupchain nicht mehr. (ohne fummeln)
Helft mir mal bitte auf die Sprünge – der Artikel ist KB5025885 – das update jedoch nicht?
Ich habe jetzt im Artikel einmal was vom Update vom 09.04 gelesen und vom 09.07.
Keins dieser Updates bei uns im WSUS hat die KB Nummer – welches Update ist denn genau vonnöten bzw kann mir jemand die KB Nummer des Updates nennen, von dem hier die Rede ist?
Ganz einfach. Sie öffnen den Link zur CVE und suchen aus der Liste das Update, welches auf Ihr System passt.
Gruß
Das Update ist in den normalen monatlichen Updates enthalten, muss aber manuell aktiviert werden.
Die dazu notwendigen (jetzt 4) Schritte sind in KB5025885 beschrieben.
Schritt 4 (SVN) ist optional und sehr (!!) aufwendig.
July 9, 2024—KB5040442 (OS Builds 22621.3880 and 22631.3880) – Win11
July 9, 2024—KB5040427 (OS Builds 19044.4651 and 19045.4651) – Win10