News Probleme mit älteren Systemen: Microsoft stoppt teils Rollout von Secure-Boot-Zertifikaten

[Warhead]

Das Problem sind vorallem Geräte die Windows 11 in älterer Version (22H2,23H2) haben.

wusste bisher noch gar nicht, dass die überhaupt noch SecureBoot-Updates bekommen würden weil eigentlich eol...

zudem laufen gerade diese versionen dann auch auf Kisten, die teilweise nichtmal ein uefi haben, geschweige denn secureboot oder tpm...die haben dann aber eben auch keine Probleme

was scheinbar eher mal wieder ein problem zu sein scheint, ist wohl dann wiedermal bitlocker. was mir der käse auf einem privaten system bringen soll, erschließt sich mir bis heute nicht, daher hab ich das auch nirgends aktiv

 

[whats4]

gehe ich das Risiko ein

also mit freuden freiwillig in Chárybdis versinken, bloß um skylla zu vermeiden?
der weg mag sich unterscheiden, aber in der scheisse landest du. sooner or later.

 

[Hyourinmaru]

Microsoft betont zudem ausdrücklich, dass Nutzer Secure Boot nicht deaktivieren sollten, wenn das Zertifikatsupdate noch nicht installiert wurde. Zwar fehlt in diesem Fall die aktuelle Zertifikatsbasis, ein aktiviertes Secure Boot bietet jedoch weiterhin einen deutlich höheren Schutz vor Schadsoftware während des Systemstarts als ein vollständig deaktivierter Schutzmechanismus.

Kann problematisch sein. Auf dem Notebook meines besten Freundes bspw., ein MSI GE62VR 6RF Apache Pro, sind nur die alten Zertifikate von 2011 vorhanden. Das Windows 11 24H2 auf diesem Gerät hat offenbar den Windows-Bootloader und Windows-Kernel nur noch mit den 2023er Zertifikaten. Inzwischen wirft das Gerät mit aktiviertem Secure Boot eine Security Violation-Warnung und verhindert den Start ins Windows.

Windows selbst bekommt es nicht hin, die neuen Zertifikate einzuspielen. Entweder weil das Gerät nicht unterstützte Hardware verwendet und via Rufus installiert wurde oder weil die UEFI-Firmwareimplementierung fehlerhaft ist, wie im Artikel beschrieben. Ich musste hier dann vorvorletztes Wochenende mit sbctl unter einem Live Linux eingreifen und die 2023er Zertifikate ins UEFI laden.

Aber offenbar ist die CMOS-Batterie leer und damit auch die neuen Zertifikate wieder weg, denn vorgestern kam die Security Violation-Fehlermeldung wieder. Ich musste meinen besten Freund dann via Telefon ins und durch das UEFI geleiten, damit er Secure Boot deaktiviert bekommt.

 

[HasleRuegsau]

Scheiss Secure Boot und TPM, macht nur Probleme. Nutzen quasi null.

 

[Ranayna]

Ich habe noch nie eine Situation gesehen wo es Sinn gemacht hätte, das Zertifikate für Software-Signaturen ablaufen können.

Alle Zertifikate laufen irgendwann ab. Auch Codesigningzertifikate haben ein Ablaufdatum.
Nur prueft da in der Regel niemand das Ablaufdatum.

Schon jetzt kann es schwer werden, unsignierte Software auszufuehren, jenachdem wie scharf Windows eingestellt ist. Microsoft will da ja auch hin:
https://www.windowslatest.com/2026/...-properly-signed-apps-and-drivers-by-default/

Von da aus ist es nur noch ein kleiner Schritt, auch zu fordern, dass die Zertifikate auch aktuell sein muessen.

 

[jimmy13]

@whats4 Wie Odysseus gehe ich das Risiko ein. Eine gewisse Gefahr besteht grundsätzlich, wenn man sich in solche Fahrwasser begibt. Immerhin hat er Charybdis auch überstanden, wenn auch nicht ganz unversehrt.

 

[Ranayna]

Wenn man wenigstens selbst irgendwie die Installation der Zertifikate regeln könnte, wäre das zumindest etwas akzeptabel.

Gibt es nicht UEFIs wo man selber Zertifikate installieren kann?
Ich habe etliche entsprechende Anleitungen gesehen, wo erklaert wird wie man die Zertifikate erneuert, wenn es weder UEFI- noch Windows Updates gibt.

 

[jimmy13]

@Ranayna Da muss ich gestehen, dass ich das nicht mit absoluter Sicherheit sagen kann.
Alle Guides zum "manuellen" Updaten, die ich bisher finden konnte, beziehen sich darauf, dass man einen Registry-Wert setzen und dann den entsprechenden Updatetask manuell anschieben muss. Das eigentliche Update erfolgt aber weiterhin über diesen Task und ist, meinem Verständnis nach, kein wirklich manuelles oder direktes Update der Zertifikate.

Edit:
Vielleicht probiere ich das mit einer dieser Anleitungen aus und schaue mal, was dabei herauskommt.

@Hyourinmaru Danke, für diese Info. Müsste mal nachsehen, ob das bei einem Asus B350 auch so eine Möglichkeit gibt.

 

[Hyourinmaru]

Gibt es nicht UEFIs wo man selber Zertifikate installieren kann?

Die meisten Consumer-Mainboards im DIY-Markt sollten das können, mein MSI MAG X870E TOMAHAWK WIFI kann das bspw. Im UEFI den Secure Boot-Modus von Standard auf Custom stellen, dann hat man die Schlüsselverwaltung, wo man auch selber Zertifikate reinladen kann.

Bei den Notebooks sieht es eher mau aus, da kommt es ganz auf die Implementierung seitens des OEM an. Im UEFI vom Notebook meines besten Freundes bspw. lässt sich der Secure Boot-Modus zwar von Standard auf Custom stellen und eine Schlüsselverwaltung gibts dort auch, allerdings hat der OEM keine Möglichkeit implementiert, dort eigene Zertifikate reinzuladen.
Da ist ein Live Linux mit sbctl dann die einzige Möglichkeit.

 

[Corros1on]

Microsoft sollte das mit Windows vielleicht auch einfach lassen - das ist ja nur noch lächerlich.

Und was dann? (ernsthafte Frage)

 

[Matthias B. V.]

Bei mir hat das Windows Update auch das Surface direkt in den Bitlocker geschossen…

Den Schlüssel konnte man wieder einspielen aber dennoch peinlich!

 

[floTTes]

Wenn man wenigstens selbst irgendwie die Installation der Zertifikate regeln könnte, wäre das zumindest etwas akzeptabel. Aber bei der ganzen Geschichte sind wir vollständig von MS und deren funktionierendem Updatesystem abhängig.

Bullshit, erst einlesen und dann kannst mitreden.

Selbst Linux bietet mittlerweile komfortables SB-Handling.

 

[jimmy13]

@floTTes Danke für die ausführliche Information, dass ich falsch lag. Zum Glück hast du auch gleich eine entsprechende Information beigefügt, dass ich das mit einem ANDEREN System so einfach machen kann.
Zum Glück haben wir Leute wie dich, die regeln, wer denn genau mitreden darf und wer nicht. So bleibt dieses Forum sauber und bietet viele Informationen für alle, die weniger genau bescheid wissen.

 

[floTTes]

Ja, sorry, auf falsche Narrative reagiere ich wohl allergisch.

Versuch"s mal mit den SB-Artikeln der MS-KB. Da solltest du fündig werden.

 

[User38]

Und was dann? (ernsthafte Frage)

Dann steigen wir alle auf Linux um und sind glücklich

 

[jimmy13]

@floTTes Wie auch immer, solche "Zurechtweisungen" gehen schöner. Mittlerweile hab ich das über die in Windows 11 integrierte Art gemacht.

Habe das Update meiner Zertifikate auf einem Asus Prime B350-Plus mit UEFI 6232 erfolgreich durchgeführt. Dazu natürlich erst, sofern noch nicht aktiv, SecureBoot im UEFI selbst aktivieren. Danach eine PowerShell mit Adminrechten gestartet und folgende Befehle genutzt:

1. Confirm-SecureBootUEFI
   (um sicher zu sein, dass es aktiviert ist "True")
2. [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
   (um zu überprüfen, welchen Stand man gerade hat. "True" für alles auf Stand und man muss nichts weiter tun, "False" für zu alte Zertifikate, die ein Update brauchen)
3. Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 22852 -Type DWord
   (den Registry-Key auf den Wert setzen, damit ein Update auch angestoßen werden kann)
4. Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
   (den eigentlichen Updatetask starten, der das Update durchführt)

Danach wurde empfohlen, das System mindestens zwei Mal neu zu starten, da es angeblich ein mehrstufiger Prozess ist, der nach nur einmaligem Neustart nicht unbedingt schon abgeschlossen ist. Bei mir war aber schon nach einem Neustart die Prüfung (zweiter Punkt oben) auf die aktuellen Zertifikate auf "True" und somit eigentlich durch, aber dennoch insgesamt drei Mal neu gestartet.

Jetzt bleibt SecureBoot bei mir erstmal aktiv und ich werde es, solange es problemlos läuft, so lassen. Sobald das aber den Start von anderen Rettungssystemen von bspw. meinem VentoyStick verhindern sollte, wird es wieder deaktiviert.

Diese Angaben sind ohne Gewähr und ich überlasse es jedem selbst, diesen Weg, sofern nötig, einzuschlagen. Falls irgendwo ein Fehler oder eine bessere Option verfügbar sein soll, immer her damit.

 

[Nebula123]

Bei mir sind TPM und Secure Boot grundsätzlich deaktiviert und alles läuft ohne Probleme, egal ob Windows oder Linux 😜

die SB- & TPM-Pflicht ist bei Win11 nur vorgeschoben, dass es auch ohne geht zeigen die Hacks und die Anforderungen für Win11 IoT wo das nur "optional" ist.

 

[floTTes]

Jetzt bleibt SecureBoot bei mir erstmal aktiv und ich werde es, solange es problemlos läuft, so lassen. Sobald das aber den Start von anderen Rettungssystemen von bspw. meinem VentoyStick verhindern sollte, wird es wieder deaktiviert.

Dann würde ich dir empfehlen, deine Rettungssysteme MS-SB-tauglich zu machen ... oder eigenen Zertifikate zu installieren.

Hier wird wieder mit so viel Unwissen um sich geworfen, dass man sich kaum wegducken kann.

 

[jimmy13]

@floTTes Ob ich das wirklich immer in der Hand haben werde, ist dabei eine andere Frage. Aber soweit möglich, werde ich das tun. Ventoy bietet das ja von sich aus schon an.

 

[csch92]

Ich mene ich persönlich habe nur selten Probleme mit Windows 11
Aber das Gefühlt fast täglich irgend ein neuer fehler auftaucht ist ja schon peinlich oder?
Zu Linux werde ich trotzdem nicht wechseln, das ist mir einfach zu viel frickeln