Im Juni 2026 läuft ein altes Microsoft‑Signing‑Zertifikat für UEFI Secure Boot aus. Das allein führt nicht automatisch zu Bootproblemen: Geräte starten weiterhin, solange die betreffenden öffentlichen Schlüssel in der Firmware verbleiben und nicht in die Sperrliste (dbx) aufgenommen werden. Trotzdem ist jetzt ein guter Zeitpunkt, um zu prüfen, ob Firmware‑Updates und aktualisierte Bootloader vorliegen — insbesondere für Fedora‑Systeme mit aktiviertem Secure Boot auf der x86_64‑Architektur.
Was genau läuft ab und warum betrifft das Microsoft?
UEFI Secure Boot baut auf asymmetrischer Kryptographie auf: eine private Signaturschlüssel signiert Bootloader und Kernel‑Artefakte, die Entsprechung in Form eines öffentlichen Schlüssels liegt in der Firmware und bestätigt Signaturen beim Start. Microsoft fungiert als zentrale Signier‑Instanz für die „shim“ genannte erste Bootstufe, deren öffentlicher Schlüssel in vielen Systemfirmwares vorinstalliert ist.
Microsoft nutzte lange Zeit eine Schlüsselhierarchie aus dem Jahr 2011 (üblicherweise als „2011 key“ bezeichnet). Dieses Zertifikat läuft Ende Juni 2026 ab. Seit Oktober 2025 signiert Microsoft zusätzlich mit einem neueren Schlüssel (die „2023 key“). Nachdem der 2011‑Schlüssel abläuft, werden neue shims nur noch mit dem 2023‑Schlüssel signiert.
Folgen für reale Systeme
Wichtig: Die Ablaufzeit eines Schlüssels bedeutet nicht, dass bereits ausgestellte Signaturen sofort ungültig werden oder Computer abrupt nicht mehr booten. Solange die betreffenden öffentlichen Schlüssel in der Firmware‑Datenbank (db) vorhanden sind und nicht in die Sperrliste dbx übernommen wurden, akzeptiert die Firmware die bisher signierten Komponenten.
Problematisch wird es nur, wenn Herstelleraktualisierungen die Schlüssel entfernen oder die dbx so verändert wird, dass die älteren Signaturen blockiert sind. Deshalb empfiehlt sich ein proaktives Vorgehen: Firmware‑ und shim‑Aktualisierungen einspielen, sobald der Hersteller sie bereitstellt.
Was Fedora bereits unternimmt
Fedora‑Rawhide (f45) enthält bereits eine Version des shim, die mit mehreren Schlüsseln signiert ist, um Kompatibilität zu maximieren. Fedora‑shim bettet zudem einen Fedora‑öffentlichen CA‑Schlüssel ein, mit dem nachfolgende Stufen wie grub2, der Kernel und andere für den Bootprozess notwendige Komponenten signiert werden. Beim Kernel‑Build werden Kernel‑Module mit einem flüchtigen (ephemeral) Schlüssel signiert; unter aktiviertem Secure Boot können nur signierte Module geladen werden.
Welche Systeme sind wirklich betroffen?
Die Situation betrifft nur Maschinen mit UEFI‑Firmware und nur solche Fedora‑Installationen, die Secure Boot aktiviert haben. Bei Fedora gilt die Information explizit für die x86_64‑Architektur (Intel/AMD). Systeme mit Legacy‑BIOS sind nicht betroffen.
Virtualisierte Systeme
Sogar virtuelle Maschinen nutzen UEFI‑Firmware (edk2‑ovmf) und haben vergleichbare öffentliche Schlüssel. Auch dort gelten die gleichen Überlegungen zu Signaturen und Firmware‑Datenbanken.
Praktische Prüfungen: Wie Sie den Status Ihres Systems ermitteln
Ein paar einfache Befehle helfen zu prüfen, ob Ihr System UEFI und Secure Boot verwendet und welche Schlüssel in der Firmware hinterlegt sind. Führen Sie die folgenden Befehle als normaler Benutzer oder mit sudo aus:
# Prüfen, ob UEFI aktiv ist
[[ -d /sys/firmware/efi ]] || echo BIOS
# Prüfen, ob Secure Boot aktiviert ist
mokutil --sb-state
# Auflisten der in der Firmware hinterlegten DB‑Einträge (kurze Ansicht)
mokutil --db --short
# Untersuchen, mit welchem Zertifikat ein shim signiert wurde (Beispielpfad)
sudo dnf install pesign -y
sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi
Die mokutil‑Ausgabe zeigt, ob Secure Boot aktiviert ist, deaktiviert oder ob sich das System in Setup‑Mode befindet (letzteres bedeutet, dass keine Schlüssel in der Firmware eingetragen sind). Die mokutil –db –short‑Ansicht listet die öffentlichen Zertifikate, etwa Microsoft‑Einträge für die 2011er und 2023er CA.
Mit pesign können Sie die Signatur eines EFI‑Binaries (shim, grubx64.efi, vmlinuz‑Dateien) untersuchen und so erkennen, welche Stellen die Datei signiert haben.
Aktualisieren: Was Sie tun sollten — und was Sie vermeiden müssen
Empfehlung: Prüfen Sie regelmäßig auf Firmware‑Updates und installieren Sie diese über die vom Hersteller vorgesehenen Wege. Unter Linux ist fwupd in Kombination mit dem Linux Vendor Firmware Service (LVFS) die komfortabelste Methode, um verfügbare Firmwarepakete zu erhalten und einzuspielen.
Für manche Hersteller (z. B. HP oder Fujitsu) werden die Verteilungen schrittweise freigegeben; nach einem Firmware‑Update kann ein zusätzlicher Komponentenupload folgen. Folgen Sie dabei den vom Hardware‑Hersteller empfohlenen Anweisungen.
Wichtig: Versuchen Sie nicht, Firmware‑Datenbanken manuell zu verändern, es sei denn, Sie wissen genau, was Sie tun. Entfernen Sie nicht den 2011‑Schlüssel aus der Firmware — er ist nicht kompromittiert, sondern läuft lediglich ab, und seine Entfernung kann Nebenwirkungen haben, etwa für Option‑ROMs von Peripheriegeräten.
Gleiches gilt umgekehrt: Das Hinzufügen des alten 2011‑Schlüssels in die Sperrliste dbx kann dazu führen, dass dual signierte shims nicht mehr starten. Sollte für Ihr System kein Update verfügbar sein, wenden Sie sich an den Hardware‑Hersteller.
Risiko‑Abwägung und Ausblick
Der aktuelle Status ist beruhigend: Es sind keine bekannten, ausnutzbaren Schwachstellen in shim öffentlich, die ein sofortiges Handeln erzwingen würden. Dennoch sind kryptografische Komponenten nicht statisch — neue Schwachstellen könnten entdeckt werden. Daher ist es vernünftig, Systeme auf dem neuesten Stand zu halten, Firmware‑Updates zu installieren und zu überwachen, ob Ihre Distribution aktualisierte, mit dem 2023‑Key signierte shims ausliefert.
Fazit
Das Ablaufdatum des Microsoft‑Zertifikats bedeutet keinen akuten Boot‑Notfall. Betreiber von Fedora‑Systemen mit Secure Boot sollten jedoch prüfen, ob ihre Firmware die neuen Signer‑Schlüssel enthält und Firmware‑/shim‑Updates einspielen, sobald sie vom Hersteller oder über LVFS verfügbar sind. Kontrollieren Sie mit mokutil und pesign den Status und vermeiden Sie eigenmächtige Manipulationen an der Firmware‑Datenbank.