Ende Juni 2026 ist ein Microsoft-Zertifikat ausgelaufen, von dem du wahrscheinlich noch nie gehört hast – und trotzdem entscheidet es darüber, ob dein Linux-Rechner überhaupt noch hochfährt. Nicht dein GRUB, nicht dein Kernel, nicht deine Distribution. Microsofts Signatur. Selbst wenn du kein einziges Microsoft-Produkt nutzt.

Das „Microsoft Corporation UEFI CA 2011”-Zertifikat hatte eine Laufzeit von 15 Jahren. Jetzt ist die Zeit um. Ob dein Linux noch bootet, hängt davon ab, welche BIOS-Version auf deinem Rechner läuft und ob die neuen Zertifikate bereits hinterlegt wurden. Bei manchen Systemen läuft alles weiter wie bisher. Bei anderen siehst du beim nächsten Start einen „Secure Boot Violation”-Fehler – und nichts geht mehr.

Windows hat übrigens eine Gnadenfrist bis Oktober 2026. Linux nicht.

Was ist Secure Boot, und warum hängt Linux an Microsoft

Secure Boot ist ein UEFI-Mechanismus, der sicherstellen soll, dass nur vertrauenswürdige Bootloader geladen werden. Das Ziel: Schadsoftware wie Rootkits blockieren, die sich vor dem Betriebssystem einnisten und dadurch praktisch unsichtbar werden. Die Firmware prüft beim Start die digitale Signatur des Bootloaders gegen eine Liste vertrauenswürdiger Zertifikate. Passt die Signatur nicht, bleibt der Rechner stehen.

Klingt erstmal sinnvoll. Das Problem: Die Zertifikate, denen die UEFI-Firmware vertraut, kommen standardmäßig von Microsoft. Nicht von Canonical, nicht von Red Hat, nicht von der Linux Foundation. Von Microsoft. Auch wenn du Ubuntu, Fedora oder Debian nutzt.

Warum? Weil Microsoft aus praktischen Gründen nicht nur die eigenen Windows-Bootloader signiert, sondern auch die der großen Linux-Distributionen. Das ermöglicht Dual-Boot-Setups und den Einsatz von Linux auf Systemen mit aktiviertem Secure Boot, ohne dass jeder Hardware-Hersteller jede Distribution einzeln signieren müsste. Technisch pragmatisch. Politisch: eine Abhängigkeit.

Was jetzt passiert ist

Nach 15 Jahren sind die alten Zertifikate abgelaufen. Microsoft hat drei Zertifikate erneuert:

  • „Microsoft Corporation KEK CA 2011” → „Microsoft Corporation KEK 2K CA 2023”
  • „Microsoft Corporation UEFI CA 2011” → „Microsoft Corporation UEFI CA 2023”
  • „Microsoft Windows Production PCA 2011” → „Windows UEFI CA 2023”

Das erste und zweite sind Ende Juni 2026 ausgelaufen, das dritte läuft im Oktober 2026 aus. Linux-Bootloader sind vom zweiten Zertifikat abhängig, das bereits abgelaufen ist. Windows-Bootloader vom dritten, das noch läuft.

Microsoft nennt das selbst „the first global, large-scale secure boot certificate update”. Das ist kein Randthema. Das trifft jeden Rechner mit aktiviertem Secure Boot, auf dem Linux läuft oder laufen soll.

Ob dein System noch bootet, hängt davon ab, ob die neuen Zertifikate bereits in der UEFI-Firmware hinterlegt sind. Das wiederum hängt von der BIOS-Version ab, vom Mainboard-Hersteller, davon, ob du die Firmware in den letzten Monaten aktualisiert hast, und davon, ob die Distribution selbst die Zertifikate nachgeladen hat. Eine klare Aussage „betroffen” oder „nicht betroffen” gibt es nicht. Du merkst es beim nächsten Neustart.

Dual-Boot, Azure, Tails – wer genau betroffen ist

Dual-Boot-Systeme: Wenn du Windows und Linux parallel nutzt, kannst du die neuen Zertifikate über Windows Update beziehen. Microsoft verteilt sie als Teil der regulären monatlichen Updates. Einmal unter Windows gestartet, Update installiert, Neustart – und Linux bootet wieder. Das ist die einfachste Lösung, setzt aber voraus, dass Windows noch funktioniert.

Reine Linux-Systeme: Wenn du kein Windows installiert hast, hilft dir der fwupd-Daemon. Bei Linux-Distributionen mit GNOME-Desktop läuft das Update automatisch über GNOME Software. Du bekommst eine Benachrichtigung, klickst auf „Installieren”, Neustart – fertig. Voraussetzung: fwupd muss installiert und aktiviert sein, was bei Ubuntu, Fedora und den meisten GNOME-basierten Distributionen standardmäßig der Fall ist.

Azure-VMs: Besonders übel trifft es Linux-VMs auf Microsoft Azure mit „Trusted Launch” oder „Confidential VMs” mit aktiviertem Secure Boot. VMs, die vor April 2024 erstellt wurden, können nicht sicher aktualisiert werden, weil die Disk-Encryption-Keys im virtuellen TPM versiegelt sind. Diese VMs müssen komplett neu aufgesetzt werden. Inklusive Datenmigration, Downtime, Testaufwand. Für Unternehmen und Vereine, die auf Azure setzen, ist das kein Patchday, sondern ein Projekt.

Tails: Die Privacy-Distribution Tails zeigt seit Version 7.7 einen aktiven Warndialog an, wenn ein Computer veraltete Microsoft-Secure-Boot-Zertifikate verwendet. Tails ist die einzige mir bekannte Distribution, die das Problem proaktiv kommuniziert. Andere Distributionen schweigen oder verstecken das in Release Notes, die niemand liest.

Was du jetzt konkret tun kannst

1. Prüfen, ob du betroffen bist

Wenn dein Linux noch bootet, bist du entweder nicht betroffen oder die neuen Zertifikate wurden bereits installiert. Wenn dein Linux nicht mehr bootet und du eine „Secure Boot Violation”-Fehlermeldung siehst, bist du betroffen.

2. Windows Update nutzen (für Dual-Boot)

Starte Windows, installiere alle verfügbaren Updates über Windows Update, starte neu. Die neuen Zertifikate werden automatisch eingespielt. Linux sollte danach wieder booten.

3. fwupd nutzen (für reine Linux-Systeme)

Öffne GNOME Software oder ein Terminal und prüfe, ob fwupd installiert ist:

fwupdmgr get-updates

Wenn Updates verfügbar sind, installiere sie:

fwupdmgr update

Starte danach neu. Bei GNOME-Distributionen läuft das normalerweise automatisch im Hintergrund, du musst nur auf die Benachrichtigung reagieren.

4. Firmware-Update vom Hersteller

Geh auf die Support-Seite deines Mainboard- oder Notebook-Herstellers, lade die aktuellste BIOS-/UEFI-Firmware herunter und installiere sie. Manche Geräte benötigen zuerst ein Firmware-Update, bevor die Zertifikat-Updates greifen. Das ist die sauberste Lösung, aber auch die aufwendigste.

5. Secure Boot deaktivieren

Wenn nichts davon funktioniert oder du keine Zeit für Updates hast: Geh ins BIOS (meist F2, F10, Entf oder ESC beim Hochfahren, je nach Hersteller), suche den Menüpunkt „Secure Boot” und deaktiviere ihn. Dein Linux bootet dann wieder. Der Preis: Du verlierst den Schutz, den Secure Boot bieten soll. Rootkits und Bootkits können sich wieder vor dem Betriebssystem einnisten, ohne dass Secure Boot sie blockiert.

Das ist die radikalste Lösung, aber für viele Privatpersonen und kleine Vereine trotzdem die pragmatischste. Secure Boot schützt vor einer Bedrohung, die für die meisten Nutzer*innen theoretisch bleibt. Ein System, das gar nicht erst hochfährt, ist das konkretere Problem.

Für Neuinstallationen: Vorsorge statt Nachsorge

Wenn du gerade dabei bist, Linux neu zu installieren oder auf ein anderes System umzuziehen: Stelle sicher, dass die Firmware aktuell ist, bevor du installierst. Lade das neueste BIOS-/UEFI-Update vom Hersteller herunter und spiele es ein. Dann installiere eine aktuelle Linux-Distribution mit aktuellem fwupd (mindestens Version 2.1.1, besser neuer). Aktiviere fwupd explizit, wenn es nicht standardmäßig läuft.

Das kostet dich zehn Minuten mehr Installationszeit, erspart dir aber den Aufwand später, wenn das nächste Zertifikat ausläuft oder Microsoft ein weiteres DBX-Update verteilt, das alte Bootloader blockiert.

Was das für digitale Unabhängigkeit bedeutet

Hier ist der Punkt: Du nutzt kein Windows. Du nutzt keine Microsoft-Cloud. Du hast bewusst auf Linux gesetzt, weil du die Kontrolle über dein System behalten willst. Und trotzdem hängt dein Rechner an Microsofts Zertifikaten. Microsoft entscheidet, welche Bootloader vertrauenswürdig sind. Microsoft gibt vor, wann Zertifikate auslaufen. Microsoft verteilt die Updates – oder eben nicht.

UEFI Secure Boot wurde von einem Industriekonsortium entwickelt, in dem Microsoft federführend war. Die Zertifikate kommen von Microsoft, weil Microsoft die Plattform kontrolliert. Nicht technisch, sondern strukturell. So wurde es designed.

Alternativen? Du kannst eigene Secure-Boot-Keys in die Firmware laden und ausschließlich deine eigenen Bootloader signieren. Das funktioniert technisch, ist aber für Normalnutzer*innen viel zu komplex und bricht bei jedem Kernel-Update, wenn der neue Kernel nicht mit deinem Key signiert ist. Du kannst auf Hardware mit Coreboot oder Libreboot setzen, die vollständig freie Firmware nutzen – aber das sind Nischenprodukte, die du nicht im Elektromarkt kaufst.

Oder du deaktivierst Secure Boot. Dann hast du die Kontrolle zurück, aber keinen Schutz mehr gegen Bootkits. Eine Zwickmühle.

Warum das jetzt erst ein Thema ist

Secure Boot gibt es seit 2011. Die Zertifikate waren von Anfang an auf 15 Jahre begrenzt. Das war bekannt. Trotzdem ist das Problem erst jetzt sichtbar geworden, weil die meisten Nutzer*innen und selbst viele IT-Dienstleister*innen nicht wussten, dass die Zertifikate überhaupt eine Ablaufzeit haben.

Das liegt daran, dass Secure Boot für die meisten einfach funktioniert hat. Du installierst Linux, Secure Boot ist aktiv, alles läuft. Niemand musste sich Gedanken über Zertifikate machen, weil sie im Hintergrund erneuert wurden – oder eben nicht. Erst jetzt, wo die ersten Systeme nicht mehr booten, wird klar, wie fragil die Abhängigkeit ist.

Ein Vorgeschmack war das DBX-Update vom August 2025. Microsoft hat damals mit einem Update der „Datenbank verbotener Signaturen” zahlreiche Bootloader blockiert, weil sie Sicherheitslücken hatten, die Malware wie BlackLotus ausnutzen konnte. Viele Linux-Distributionen starteten danach nicht mehr. Das war technisch richtig, aber kommunikativ ein Desaster. Distributionen haben teilweise Wochen gebraucht, um neue Bootloader zu signieren und zu verteilen.

Das jetzige Zertifikat-Auslaufen ist dieselbe Mechanik, nur mit umgekehrtem Vorzeichen: Nicht die Bootloader wurden blockiert, sondern die Zertifikate, die sie signiert haben, sind einfach abgelaufen. Das Ergebnis ist dasselbe: System bootet nicht.

Was du daraus mitnehmen kannst

Wenn dein Linux-System heute nicht mehr bootet, weil ein Microsoft-Zertifikat ausgelaufen ist, dann ist das kein technisches Versagen deiner Distribution. Es ist ein Strukturproblem. Du kannst die besten Werkzeuge nutzen, den saubersten Debian-Server aufsetzen, auf Proprietary Software verzichten – und trotzdem hängst du an einer Infrastruktur, die du nicht kontrollierst.

Das gilt nicht nur für Secure Boot. Das gilt für Firmware-Updates, für Treiber, für Hardware-Zertifizierungen, für Cloud-APIs, für Bezahldienste, für Messaging-Protokolle. Digitale Unabhängigkeit ist kein Zustand, den du einmal erreichst und dann abhaken kannst. Es ist ein ständiger Balanceakt zwischen Pragmatismus und Kontrolle.

Das abgelaufene Zertifikat ist ein Symptom. Die Diagnose lautet: Wer die Plattform kontrolliert, kontrolliert das System. Und die Plattform gehört Microsoft.

Reden wir über deinen Umstieg.

Wenn du raus willst aus der Microsoft-Logik, aus dem Kontozwang, aus der stillen Abhängigkeit vom US Cloud Act, dann begleite ich dich beim Umstieg. Linux-Migration, Server-Infrastruktur, digitale Unabhängigkeit – nicht als Theorie, sondern als konkrete Schritte.

Reden wir über deine Technik.

Schreib mir eine E-Mail: Kurz beschreiben, was du vorhast oder was dich beschäftigt. Ich melde mich in der Regel innerhalb eines Werktages. hallo@chrislo.de

Kein Kontaktformular, keine Pflichtfelder, keine Datenspur. Einfach schreiben.