Das Datum ist vorbei; die Prüfung bleibt wichtig

Mit Stand vom 24. September 2026 ist der Übergang keine Warnung vor einem künftigen Termin mehr: Das Zertifikat Microsoft Corporation UEFI CA 2011 wurde seit dem 26. Juni nicht mehr für neue Signaturen verwendet. Microsoft hat die Signierung von UEFI-Anwendungen von Drittanbietern auf die Zertifizierungsstellen von 2023 umgestellt, darunter Microsoft UEFI CA 2023; für Option ROMs gibt es eine eigene Stelle von 2023. Das genaue Datum ist wichtig, weil frühere Schlagzeilen teilweise den Eindruck erweckten, Secure Boot selbst habe ein Ablaufdatum. Das stimmt nicht: Abgelaufen sind bestimmte Zertifikate, mit denen bestimmte Komponenten signiert werden. (Microsoft-Leitfaden für Linux-Distributionen)

Secure Boot ist eine UEFI-Firmwarefunktion, die die Signaturen von Startprogrammen prüft, bevor sie ausgeführt werden dürfen. Zur Kette können der Bootmanager des Betriebssystems, Zwischenlader und UEFI-Treiber gehören, einschließlich Firmwarekomponenten, die als Option ROMs bezeichnet werden. Die Vertrauensdatenbank db enthält zugelassene Zertifikate oder Images; die Sperrdatenbank dbx führt Elemente auf, die nicht geladen werden dürfen. Der Status eines PCs hängt somit von den in der Firmware eingetragenen Schlüsseln und den konkreten Signaturen der zu startenden Komponenten ab, nicht einfach vom Alter des Geräts. (Microsoft-Übersicht zu OEM Secure Boot)

Ablauf ist nicht dasselbe wie Widerruf

Entscheidend ist der Unterschied zwischen dem Einstellen neuer Signaturen mit einem Zertifikat und dem Widerruf des Vertrauens in dieses Zertifikat oder ein damit signiertes Programm. Der Ablauf des Zertifikats von 2011 verhindert, dass es über Microsofts Verfahren zum Signieren neuer Komponenten verwendet wird; für sich genommen entfernt er den Schlüssel jedoch nicht aus der db-Datenbank der Firmware und macht auch nicht automatisch alle zuvor signierten Dateien ungültig. Laut Microsoft kann ein bereits von der 2011er Stelle signierter Linux-shim weiterhin starten, wenn die Firmware dieser Stelle noch vertraut und weder shim noch dessen SBAT-Stufe widerrufen wurden. (Microsoft-Leitfaden für Linux-Distributionen)

Ein Widerruf ist eine andere Maßnahme: Einträge in dbx können bestimmte Zertifikate oder Komponenten blockieren. Steht ein Image sowohl auf der Vertrauens- als auch auf der Sperrliste, hat der Widerruf Vorrang. Ein Rechner kann heute also noch einen älteren Loader starten und zugleich nicht darauf vorbereitet sein, künftig eine korrigierte Version zu erhalten, die nur mit dem Zertifikat von 2023 signiert ist. Ein erfolgreicher Start beweist nicht, dass die Kette aktuell ist: Er bestätigt lediglich, dass die Firmware den bei diesem Start verwendeten Startpfad akzeptiert. (Microsoft-Übersicht zu OEM Secure Boot)

Was Windows und Nutzer eines gewöhnlichen Desktop-PCs bemerken können

Für Windows erklärt Microsoft, dass ein Gerät ohne die neuen Zertifikate möglicherweise weiterhin startet und reguläre Updates installiert. Die wichtigste Folge betrifft die Zukunft: Der PC erhält oder validiert womöglich keine künftigen Schutzmaßnahmen und Updates für die Startumgebung, etwa für den Bootmanager und weitere früh ausgeführte Komponenten. Das bedeutet weder, dass Windows am Tag nach Ablauf nicht mehr funktioniert, noch, dass jeder Rechner sofort ein BIOS-Update benötigt. Die Kompatibilität hängt vom Modell, der OEM-Firmware und dem tatsächlichen Zustand der Schlüssel-Datenbanken ab. (Microsoft-Hinweise zu Zertifikatsupdates)

Microsoft beschreibt auf seiner Seite für Nutzer und Administratoren risikoreichere Szenarien, wenn die Firmware veraltet ist oder die Aktualisierung fehlschlägt: Validierungsfehler, BitLocker-Wiederherstellungsaufforderungen, Startblockaden oder fehlende Startfähigkeit. Das sind mögliche Probleme unter bestimmten Umständen, nicht die zwangsläufige Folge eines Kalenderdatums. Sinnvoll ist, Windows und Firmware über die offiziellen Kanäle des Herstellers aktuell zu halten und UEFI-Schlüssel nicht eigenmächtig zu ändern, um vermeintlich vorzugreifen. Wird der Rechner von einer Organisation verwaltet, sollten Sie deren Verfahren befolgen und keine manuellen Änderungen vornehmen. (Microsoft-Hinweise zu Zertifikatsupdates)

Linux und Dual Boot: Die Kombination aus Signaturen und Schlüsseln ist entscheidend

Unter Linux ist shim bei vielen Secure-Boot-Distributionen die übliche Zwischenkomponente: Die Firmware prüft dessen Signatur, anschließend kontrolliert shim die nächsten Elemente der Kette, etwa GRUB und den Kernel. Microsoft beschreibt zwei mögliche Unvereinbarkeiten: Ein System, dessen Firmware nur der CA von 2023 vertraut, akzeptiert keinen ausschließlich mit der CA von 2011 signierten shim; ein System, das nur 2011 vertraut, akzeptiert keinen ausschließlich mit 2023 signierten shim. In beiden Fällen reicht es nicht, einfach „die neueste Version“ zu installieren: Der installierte Loader und die von der Firmware vertrauten Zertifikate müssen zusammenpassen. (Microsoft-Leitfaden für Linux-Distributionen)

Beim Dual Boot kann Windows auf kompatiblen Geräten als Bereitstellungskanal für bestimmte Updates dienen. Das beweist jedoch nicht, dass der Linux-Loader oder jede Distribution bereits bereit ist. Die Maintainer müssen Komponenten veröffentlichen, die mit den neuen Stellen signiert sind, prüfen, ob die Ziel-Firmware sie erkennt, und Sperrlisten sowie die SBAT-Richtlinie berücksichtigen. Red Hat empfiehlt beispielsweise, sowohl die Vertrauensdatenbank der Firmware zu aktualisieren, sofern ein geeignetes Update verfügbar ist, als auch den shim der Distribution. Außerdem warnt Red Hat davor, das Zertifikat von 2011 einfach zu widerrufen, da dadurch Komponenten, die noch davon abhängen, möglicherweise nicht mehr starten. Übertragen Sie den Zeitplan einer Distribution nicht auf alle anderen. (Microsoft-Leitfaden für Linux-Distributionen)

Status prüfen, ohne Schlüssel blind zu ändern

Prüfen Sie auf einem privaten Windows-PC Windows Update sowie in der Windows-Sicherheits-App den Bereich Gerätesicherheit > Sicherer Start, sofern er in Ihrer Version verfügbar ist. Microsoft dokumentiert Hinweise und Statusanzeigen für Zertifikatsupdates; bei verwalteten Geräten können Anzeige und Bereitstellung anders gesteuert sein. Für Administratoren nennt die Dokumentation Indikatoren wie den Registrierungswert UEFICA2023Status und Systemereignisse, darunter die Ereignisse 1801 und 1795. Diese Informationen helfen, ein ausstehendes Update von einem Firmwarefehler zu unterscheiden. Nutzer sollten jedoch eine einzelne Meldung nicht ohne die Hinweise für ihre Edition und ihr Gerät interpretieren. (Microsoft Windows Release Health)

Unter Linux können Werkzeuge wie mokutil anzeigen, ob Secure Boot aktiviert ist, und Zertifikate in der Firmwaredatenbank untersuchen; der Red-Hat-Leitfaden erläutert außerdem, wie sich shim-Signaturen erkennen lassen. Die Ergebnisse sind vorsichtig zu bewerten: Eine angezeigte CA von 2023 garantiert nicht, dass alle Komponenten aktuell sind. Ihr Fehlen kann für einen neuen Startpfad relevant sein, ohne zu bedeuten, dass der Rechner jetzt ausfällt. Bei Verschlüsselung, gemessenem Start oder TPM-gebundener automatischer Entsperrung können Änderungen an UEFI-Datenbanken Messwerte wie PCR7 verändern und eine Prüfung der Konfiguration erfordern. Erfassen Sie den Ausgangszustand, bevor Sie etwas ändern. (Red-Hat-Hinweise zu Secure-Boot-Zertifikaten)

Was tun, wenn der Hersteller kein Update anbietet?

Ermitteln Sie zunächst das genaue Modell des Mainboards oder Desktop-PCs und prüfen Sie dessen Supportseite: Updates für UEFI-Datenbanken hängen oft vom Firmwarehersteller oder OEM ab. Installieren Sie unter Windows die über Windows Update angebotenen Aktualisierungen und prüfen Sie den vom System gemeldeten Status. Verwenden Sie unter Linux den von der Distribution empfohlenen Mechanismus, etwa fwupd, sofern Gerät und Update unterstützt werden. Bei verwalteten Rechnern sind ein Pilotversuch und eine schrittweise Einführung vorsichtiger, als eine Änderung ohne Validierung auf eine ganze Geräteflotte auszurollen – insbesondere bei BitLocker, Dual Boot oder eigenen Schlüsselrichtlinien. Microsoft empfiehlt, zuerst die OEM-Firmware zu prüfen und repräsentative Updates zu testen, bevor der Rollout ausgeweitet wird. (Microsoft-Hinweise zu Zertifikatsupdates)

Ist kein Firmwareupdate verfügbar, gibt es keine allgemeingültige Antwort, die künftige Kompatibilität garantiert. Fragen Sie beim Hersteller und bei der konkreten Distribution nach, halten Sie BitLocker-Wiederherstellungsinformationen und wichtige Daten bereit und vermeiden Sie es, die alte CA zu löschen, UEFI-Variablen nach allgemeinen Anleitungen zu beschreiben oder Secure Boot reflexartig zu deaktivieren. Red Hat warnt, dass das Entfernen oder Widerrufen der Stelle von 2011 Loader oder Option ROMs außer Betrieb setzen kann, die von ihr abhängen. Microsoft beschreibt ebenfalls inkompatible Konfigurationen, die den Start verhindern können. Das praktische Fazit ist begrenzt: Der Ablauf schaltet den Desktop nicht von selbst ab, doch Aktualisieren und Prüfen der Vertrauenskette hilft, künftig weiterhin Startsignaturen und Schutzmaßnahmen erhalten zu können. (Red-Hat-Hinweise zu Secure-Boot-Zertifikaten)