{"id":182058,"date":"2026-06-14T14:48:26","date_gmt":"2026-06-14T12:48:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/istekaet-vremya-zhizni-sertifikata-kotorym-zaveren-zagruzchik-dlya-uefi-secure-boot-v-distributivah-linux"},"modified":"2026-06-14T14:48:26","modified_gmt":"2026-06-14T12:48:27","slug":"istekaet-vremya-zhizni-sertifikata-kotorym-zaveren-zagruzchik-dlya-uefi-secure-boot-v-distributivah-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/istekaet-vremya-zhizni-sertifikata-kotorym-zaveren-zagruzchik-dlya-uefi-secure-boot-v-distributivah-linux","title":{"rendered":"Die Lebensdauer des Zertifikats, das den Bootloader f\u00fcr UEFI Secure Boot in Linux-Distributionen bescheinigt, l\u00e4uft ab.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Entwickler von Fedora Linux haben die Situation hinsichtlich des Ablaufs des Microsoft-Zertifikats am Ende Juni klargestellt, das zur digitalen Signatur der Shim-Schicht verwendet wird, die f\u00fcr das verifisierte Booten von Linux-Distributionen im UEFI Secure Boot-Modus zust\u00e4ndig ist. Der \u00dcbergang zu einem neuen Zertifikat sollte f\u00fcr die Benutzer unauff\u00e4llig verlaufen, da das tats\u00e4chliche Ende der Lebensdauer des Zertifikats lediglich zur Folge hat, dass keine neuen Signaturen mehr erstellt werden k\u00f6nnen. W\u00e4hrend des UEFI Secure Boot wird die G\u00fcltigkeit des Zertifikats nicht \u00fcberpr\u00fcft, und es z\u00e4hlt nur der Widerruf kompromittierter Zertifikate. <\/p>\n
Vorhandene Systeme ohne das Update des Shim-Bootloaders werden weiterhin starten, solange der \u00f6ffentliche Schl\u00fcssel des Zertifikats nicht aus der Firmware entfernt oder in die Liste der zur\u00fcckgerufenen UEFI-Zertifikate (DBX) aufgenommen wird. Der Microsoft-Schl\u00fcssel zertifiziert nur die Shim-Bootschicht, die den \u00f6ffentlichen Schl\u00fcssel des Distributors enth\u00e4lt, der zur Zertifizierung von geladenen Komponenten wie dem GRUB2-Bootloader, dem Linux-Kernel, Kernel-Modulen und w\u00e4hrend des Bootvorgangs verwendeten Prozessen wie fwupd verwendet wird. Dieser Ansatz erm\u00f6glicht es Microsoft, nur die \u00c4nderungen in der Shim-Schicht zu zertifizieren und die Verifikation des Bootprozesses des Distributors eigenst\u00e4ndig zu gew\u00e4hrleisten.<\/p>\n
Das Microsoft-Zertifikat zur Signierung von Drittanbieter-Firmware f\u00fcr UEFI Secure Boot ist seit 2011 g\u00fcltig. Im Jahr 2023 wurde ein neues Zertifikat generiert, das ab Oktober 2025 f\u00fcr die Erstellung von Signaturen verwendet wird. Im Fedora Rawhide-Repository, auf dem das Release von Fedora 45 basiert, wurde bereits ein aktualisierter Shim hinzugef\u00fcgt, der mit mehreren Schl\u00fcsseln signiert ist, um maximale Kompatibilit\u00e4t mit der Hardware zu gew\u00e4hrleisten (es kann sowohl auf \u00e4lteren Firmware-Versionen ohne den \u00f6ffentlichen Schl\u00fcssel des neuen Zertifikats als auch auf Firmware-Versionen ohne den \u00f6ffentlichen Schl\u00fcssel des alten Zertifikats verwendet werden).<\/p>\n
Obwohl das Ablaufen des Microsoft-Zertifikats die Boot-Funktionalit\u00e4t nicht beeintr\u00e4chtigen sollte, empfehlen die Entwickler von Fedora den Benutzern, die Datenbank mit Schl\u00fcsseln f\u00fcr Secure Boot bei Erscheinen neuer Firmware-Versionen f\u00fcr ihre Hardware zu aktualisieren. Um festzustellen, ob das System im UEFI Secure Boot-Modus gestartet wurde, kann der Befehl mokutil --sb-state<\/code> verwendet werden, zum Anzeigen der in der Firmware vorhandenen \u00f6ffentlichen Schl\u00fcssel dient der Befehl mokutil --db --short<\/code>. Um die Schl\u00fcssel, mit denen die Shim-Schicht signiert wurde, anzuzeigen, kann der Befehl sudo pesign -S -i \/boot\/efi\/EFI\/fedora\/shimx64.efi<\/code> ausgef\u00fchrt werden, nachdem das Paket pesign<\/code> installiert wurde. Zur \u00dcberpr\u00fcfung auf Firmware-Updates und deren Installation kann der Befehl sudo fwupdmgr update<\/code> eingegeben werden. <\/p>\n
Die n\u00e4chste Version des Shim-Layers wird nur mit einem neuen Microsoft-Zertifikat signiert, und ein Firmware-Update ist erforderlich, um Ihre Systeme auf diese \u00c4nderung vorzubereiten. Das Shim-Update wird nur herausgegeben, wenn Sicherheitsanf\u00e4lligkeiten und schwerwiegende Fehler entdeckt werden, was sowohl in einem Monat als auch in einem Jahr geschehen kann. W\u00e4hrend der Existenz von Shim im Projekt wurden kritische Schw\u00e4chen gefunden, und der letzte Bericht \u00fcber Sicherheitsprobleme im Shim wurde erst vor einigen Tagen ver\u00f6ffentlicht. <\/p>\n
Im Bericht werden zwei k\u00fcrzlich entdeckte Schwachstellen, CVE-2026-8863 und \nCVE-2026-10797, erw\u00e4hnt, die die Ausf\u00fchrung von eigenem Code in einem fr\u00fchen Ladezustand bis zur \u00dcbergabe der Kontrolle an das Betriebssystem erm\u00f6glichen, den UEFI Secure Boot-Schutz umgehen und das Laden von Komponenten des Kernels ohne digitale Signatur erlauben. Die Probleme betreffen Shim-Versionen bis einschlie\u00dflich 0.9, die vor 2016 erstellt wurden. Betroffen sind sehr alte Systeme, wie \n RedHat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, ROSA Linux R10\/R9 und openSUSE mit Shim 0.9. Shim-Schichten bis einschlie\u00dflich Version 0.9 sind in die Datenbank der eingezogenen digitalen Signaturen DBX (UEFI Forbidden Signature Database) aufgenommen worden und k\u00f6nnen bei einem DBX-Update im System nicht mehr f\u00fcr das Booten im UEFI Secure Boot-Modus verwendet werden. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"