💻 Microsoft Secure Boot-Zertifikat

🔐 Secure Boot Zertifikate laufen 2026 ab

Microsoft weist auf einer offiziellen Support-Seite darauf hin, dass wichtige Secure-Boot-Zertifikate im Juni 2026 ablaufen. Diese wurden bereits 2011 signiert und sind auf eine Laufzeit von 15 Jahren ausgelegt.

Auch wenn Windows 11 weiterhin startet, werden nach Ablauf keine Sicherheitsupdates mehr für den Boot-Manager und die Secure-Boot-Komponenten installiert. Dadurch steigt das Risiko für Angriffe wie Bootkits deutlich an.

➡️ Empfehlung für Windows 11: Zertifikate rechtzeitig aktualisieren, um Sicherheitsprobleme zu vermeiden.

🐧 Hinweise für Linux-Nutzer

Vorwort

Für die meisten Nutzer ist Secure Boot nicht erforderlich. Linux schützt im laufenden Betrieb bereits viele Dinge automatisch. Optionen wie SELinux, AppArmor oder UKI sind nur nötig, wenn man das System besonders härten möchte.

⚠️ Warum das Microsoft-Secure-Boot-Zertifikat bedenklich ist

🚫 Gründe:

Proprietär und closed source – du hast keine Kontrolle darüber.
Gehört Microsoft, nicht dir oder der Linux-Community.
Wer auf freie Software setzt, will nicht von Microsoft abhängig sein.

Wer nur Linux nutzt, kann diese Panikmache von Microsoft getrost ignorieren 😉

Linux ist auch ohne Secure Boot sicher

Linux ist im laufenden Betrieb gut abgesichert, insbesondere wenn nur offizielle Paketquellen genutzt werden. Secure Boot kann zusätzlich den Systemstart schützen.
Mit eigenen Keys (db/dbx) und Unified Kernel Images (UKI) lässt sich Secure Boot vollständig vendor-unabhängig umsetzen.
SELinux (z.B. Fedora) / AppArmor (z.B. Ubuntu) sind nicht bei allen Distributionen aktiv oder standardmäßig erzwungen.
Optional nutzbar: Secure Boot über Shim + MOK oder mit vollständig eigenen Keys.

🔒 Für Fortgeschrittene: Linux unterstützt zusätzliche Boot- und Integritätsmechanismen wie UKI, IMA/EVM, signierte Module und LSMs.

🔍 Bootloader-Vergleich: GRUB vs. UKI

Feature	GRUB (klassisch)	UKI (Unified Kernel Image)
Bootloader-Typ	Stage-based, separates Kernel & Initramfs	Kernel + Initramfs + Signaturen in einem Image
Secure Boot	Optional, Microsoft Keys üblich, eigene Keys möglich	Optional, vollständige vendor-unabhängige Vertrauenskette mit eigenen db/dbx-Keys
Integritätsprüfung	Kernel/Module signierbar, teilweise Lockdown	Durchgängige Integritätskette: Kernel + Initramfs + Module + IMA/EVM
High-Security-Setup	Möglich, aber komplizierter	Integriert, einfacher zu konfigurieren
Updates & Wartung	Kernel & Initramfs separat pflegen	Image-basiert, alles in einer Einheit, konsistente Signaturen
Physischer Schutz	Read-only EFI, GRUB-Passwort, Tools wie AIDE/fwts	Gleich, zusätzlich einfacher mit UKI + IMA/EVM zu kombinieren

Hinweis

UKI ist der moderne Ansatz für distributionsübergreifende, durchgängige Boot-Integrität. GRUB bleibt Standard für klassische Installationen und Dual-Boot-Szenarien.

Community-Experten / Quellen:

Arch Wiki: Secure Boot – „Microsoft-Keys sind nicht erforderlich, wenn man eigene db/dbx verwendet. Shim ist optional.“
Kernel.org: EFI stub and UKI – Der Linux-Kernel unterstützt Unified Kernel Images (UKI) mit IMA/EVM-Signaturen, unabhängig von Microsoft. „Secure Boot ist vendor-unabhängig, wenn die Keys korrekt verwaltet werden.“

🔒 Secure Boot deaktiviert

📢 Hinweis:
Wenn du nachträglich Secure Boot deaktivierst, startet Linux problemlos, und abgelaufene Microsoft-Zertifikate sind dann irrelevant. Windows hingegen kann auf manchen PCs, besonders bei Windows 11, ohne Secure Boot nicht mehr booten.

🖥️ Installation von Linux

⚙️ Setup:

Installation über UEFI + GPT
BIOS: Secure Boot & Fast Boot deaktiviert

💡 Hinweise:

Linux bootet direkt von der EFI-Partition, Bootloader und Kernel werden ohne Signaturprüfung geladen.
Secure Boot und Microsoft-Zertifikate sind nicht notwendig.
Wichtige Dateien in verschlüsselte Ordner oder Partitionen sichern (z.B. LUKS, CryFS oder gocryptfs).

❗ Vorgehensweise bei Nutzung

🔍 Prüfen, ob Secure Boot aktiviert ist (Manjaro/Arch)

⚙️ Befehl:

sudo pacman -S --needed mokutil
mokutil --sb-state

📋 Mögliche Ausgaben:
✅ SecureBoot enabled -> Secure Boot ist aktiv
❌ SecureBoot disabled -> Secure Boot ist deaktiviert
⚠️ SecureBoot not supported -> Secure Boot wird von deinem UEFI/BIOS nicht unterstützt

📄 Überprüfen der installierten Secure Boot-Zertifikate

⚙️ Befehle:

sudo pacman -S --needed efitools
sudo efi-readvar -v db

📝 Beschreibung:
Die Ausgabe zeigt die Inhalte der UEFI-Variable db (Allowed Signature Database).
Diese enthält alle vertrauenswürdigen Zertifikate, die beim aktivierten Secure Boot zum Starten von Bootloadern und Betriebssystemen erlaubt sind.

📌 Wichtige Inhalte der Ausgabe:

Subject → Wem das Zertifikat gehört (z.B. Microsoft, Dell)
Issuer → Wer das Zertifikat signiert hat
Typ → meist X509 (Standard-Zertifikat)
Signature Size → Größe des Zertifikats
Owner (GUID) → interne Kennung des Eintrags

📋 Beispiel (gekürzt):

Subject:
    O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
Issuer:
    O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010

💡 Interpretation:

Microsoft-Zertifikate → erlauben Windows und signierte Linux-Bootloader (Shim)
Hersteller-Zertifikate (z.B. Dell) → erlauben Firmware-/BIOS-Komponenten
Die Datenbank wird nur ausgewertet, wenn Secure Boot aktiviert ist

💡 Optional (komplette Secure-Boot-Kette anzeigen):

sudo efi-readvar -v KEK
sudo efi-readvar -v PK

PK → Platform Key (Root of Trust)
KEK → darf db und dbx aktualisieren
db → erlaubt signierte Software

📄 Alle Secure Boot Zertifikate mit Ablaufdaten anzeigen

Mit diesem Einzeiler kannst du unter Manjaro/Arch alle Zertifikate aus der Secure-Boot-db auslesen und die Gültigkeit (notBefore / notAfter) direkt anzeigen.

sudo efi-readvar -v db -o /tmp/db.esl && \
sudo sig-list-to-certs /tmp/db.esl /tmp/db && \
for f in /tmp/db-*.der; do
    echo "=== $f ==="
    openssl x509 -in "$f" -inform DER -noout -dates
    echo
done

🔹 Erklärung der Schritte

efi-readvar -v db -o /tmp/db.esl
Exportiert die db-Variable aus UEFI in eine temporäre Datei.
sig-list-to-certs /tmp/db.esl /tmp/db
Extrahiert die einzelnen Zertifikate als .der-Dateien.
for f in /tmp/db-*.der; do ... done
Iteriert über alle extrahierten Zertifikate und zeigt die Gültigkeitsdaten mit OpenSSL an.
openssl x509 -in "$f" -inform DER -noout -dates
Zeigt die Start- und Ablaufzeit des Zertifikats (notBefore / notAfter) an.

⚠️ Hinweise

Die Befehle sind read-only und ändern nichts an Secure-Boot.
Dateien werden temporär unter /tmp abgelegt.
Die Ausgabe hilft, die Gültigkeit aller Secure-Boot-Zertifikate zu prüfen, z.B. für Windows oder Linux Shim.
Nach der Überprüfung kannst du die Dateien löschen:
```
sudo rm /tmp/db.esl /tmp/db-*.der
```

⚠️ Diese Befehle sind read-only und sicher. Änderungen an Secure-Boot-Variablen sollten nur mit Vorsicht erfolgen.

⚙️ 🔄 Firmware-Updates erneuern das Microsoft Secure Boot-Zertifikat automatisch

📢 Hinweis:

Hersteller (HP, Dell, Lenovo, ASUS, etc.) können im Firmware-Update die db-Datenbank aktualisieren, also die Microsoft-Zertifikate erneuern.
Das passiert automatisch beim Update, du musst in der Regel nichts manuell importieren.
Beispiel: Ein Update ersetzt ein Microsoft-Zertifikat, das 2026 abläuft, durch ein neues mit Ablauf 2030.