Secure Boot · Windows · Linux · VMs

Secure‑Boot-Zertifikate 2026: Was dahintersteckt und wo es Probleme gibt

Das Thema Secure Boot sorgt 2026 für Schlagzeilen: Microsoft erneuert die Zertifikate, die seit Jahren für den sicheren Start von Windows und auch für viele Linux-Systeme verwendet werden. Man liest schnell von „ablaufenden Zertifikaten“ und Boot-Problemen. Ganz so dramatisch ist es nicht, für Admins, Selbsthoster und ältere Hardware aber trotzdem relevant. Der nächste Stichtag ist der 19. Oktober 2026.

SECURE BOOT 2026
● Nächster Stichtag 19.10.
KEK CA
24.06.
UEFI CA
27.06.
Win PCA
19.10.
Ablauf ≠ Sperre ✓ PCs booten weiter
Windows ✓ per Windows Update
Debian ✓ shim ab 13.6
Proxmox ✓ pro EFI-Disk

Zertifikate von 2011 → 2023

✓ Nächster Stichtag: 19.10.2026
✓ Ablauf ist keine Sperre
✓ Betrifft Windows und Linux
✓ Auch VMs betroffen
✓ Kein Grund zur Panik
Grafik: Schild mit Schloss vor einem Server, alter Schlüssel wird durch neuen ersetzt – Secure-Boot-Zertifikate 2026

GRUNDLAGEN

Was macht Secure Boot überhaupt?

Secure Boot ist Teil der UEFI-Firmware und soll verhindern, dass beim Start des Rechners manipulierte oder nicht vertrauenswürdige Software ausgeführt wird. Vereinfacht gesagt prüft die Firmware die digitale Signatur der Boot-Komponenten. Dafür gibt es die Datenbank db, die Sperrliste dbx und die KEK (Key Exchange Keys). In diesen Strukturen liegen die Zertifikate und Schlüssel, denen die Firmware beim Start vertraut.

Das passiert alles, bevor Windows oder Linux überhaupt startet. Genau deshalb ist es etwas anderes als das TLS-Zertifikat einer Website: Läuft das eines Webservers ab, bekommt man eine Warnung. Bei Secure Boot geht es um die Vertrauenskette, die schon beim Einschalten gebraucht wird.

DIE ZERTIFIKATE

Warum laufen die alten Zertifikate jetzt ab?

Die betroffenen Microsoft-Zertifikate stammen größtenteils aus dem Jahr 2011. Nach rund 15 Jahren erreichen sie ihr vorgesehenes Ablaufdatum, und Microsoft ersetzt sie durch neue aus dem Jahr 2023.

1

KEK CA 2011 · 24.06.2026

Signiert die Updates für db und dbx. Nachfolger: Microsoft Corporation KEK 2K CA 2023.

2

UEFI CA 2011 · 27.06.2026

Signiert Bootloader von Drittanbietern (zum Beispiel den Linux-shim) und Options-ROMs. Nachfolger: Microsoft UEFI CA 2023 und Microsoft Option ROM UEFI CA 2023.

3

Windows Production PCA 2011 · 19.10.2026

Signiert den Windows Boot Manager. Nachfolger: Windows UEFI CA 2023. Das ist der nächste Stichtag.

Die Erneuerung läuft bereits. Microsoft verteilt die neuen Zertifikate über Windows Update und weitet die Verteilung schrittweise aus. Seit dem Update KB5074109 vom 13. Januar 2026 enthalten die Qualitätsupdates Daten, mit denen Windows erkennt, welche Geräte die Zertifikate automatisch bekommen.

KEINE PANIK

Muss man Angst haben, dass Windows nicht mehr startet?

Nein, jedenfalls nicht pauschal. Das ist einer der Punkte, die bei diesem Thema gern dramatischer dargestellt werden, als sie sind. Microsoft schreibt ausdrücklich, dass Geräte mit den alten Zertifikaten weiter starten und weiterhin normale Windows-Updates erhalten. Die Firmware prüft beim Start die Signatur, nicht das Ablaufdatum.

Das Problem ist ein anderes: Solche Geräte können langfristig keine neuen Schutzmechanismen für die frühe Bootphase mehr bekommen, etwa neue Versionen des Boot Managers, Secure-Boot-Datenbanken, Sperrlisten und Schutz gegen neu entdeckte Boot-Level-Angriffe.

Zertifikat abgelaufen ≠ Rechner sofort tot

Es bedeutet vielmehr: Zertifikat nicht aktualisiert → die Secure-Boot-Vertrauenskette ist langfristig nicht mehr auf dem aktuellen Stand. Und das sollte man bei Geräten, die noch einige Jahre laufen sollen, nicht ignorieren.

PROBLEMFÄLLE

Wo tatsächlich Probleme auftreten können

Problematisch wird es vor allem dort, wo die Aktualisierung nicht sauber durchläuft. In solchen Fällen können Secure-Boot-Fehler, BitLocker-Recovery-Abfragen oder sogar Startprobleme auftreten.

◐

Alte Firmware

Veraltete UEFI- oder BIOS-Firmware, bei der sich das Zertifikatsupdate nicht anwenden lässt. Zuerst die Updates des Herstellers prüfen.

▤

BitLocker

Änderungen an den Secure-Boot-Daten können eine Abfrage des BitLocker-Wiederherstellungsschlüssels auslösen. Die Schlüssel vorher sichern.

✎

Eigene Konfiguration

Spezielle Bootloader und individuell angepasste Secure-Boot-Konfigurationen, bei denen mehr als der Windows-Start an den Einträgen hängt.

↻

Ältere Hardware

Geräte, die kaum noch Firmware-Updates bekommen, gehören auf die Liste der Risiken.

↗

Windows Server

Auf Servern sollte man das Thema nicht nebenbei laufen lassen. Microsoft hat dafür ein eigenes Playbook veröffentlicht.

✓

Windows 10

Für Privatgeräte gibt es ESU bis zum 12. Oktober 2027. Berichten zufolge bekommen Windows-10-Geräte ohne ESU die neuen Zertifikate nicht.

Das ist aus meiner Sicht auch der wichtigste Punkt für Unternehmen: Nicht auf allen Geräten blind irgendwelche Firmware- und Secure-Boot-Änderungen ausrollen. Microsoft empfiehlt in verwalteten Umgebungen, Firmware und Zertifikatsstatus vorher zu prüfen und Updates zunächst mit einer Pilotgruppe zu testen.

LINUX

Und was ist mit Linux?

Hier wird es für Server-Admins und Selbsthoster besonders interessant. Viele Distributionen starten bei aktiviertem Secure Boot mit dem sogenannten shim, der von Microsoft signiert und von der Firmware akzeptiert wird. Deshalb betrifft die Erneuerung nicht nur Windows.

1

Ablauf ≠ Sperre

Ein bereits signierter Bootloader startet weiter. Neu ist, dass Microsoft mit den 2011er-CAs nichts Neues mehr signieren kann. Künftige shim-Versionen tragen nur noch die 2023er-Signatur, und Systeme ohne die 2023er-Zertifikate in der Firmware starten sie nicht.

2

Debian

Debian 13.6 (11. Juli 2026) bringt einen shim mit alter und neuer Signatur und fwupd 2.0.20, das CA, KEK und DBX in der Firmware aktualisieren kann. Debian rät, die Updates des Geräteherstellers einzuspielen.

3

Red Hat und Derivate

Auf x86_64 sind die aktuellen shim-Versionen mit 2011 und 2023 signiert, auf aarch64 nur mit 2023.

4

Neue Hardware

Manche Geräte ab etwa 2024 haben nur die Windows UEFI CA 2023, aber nicht die Microsoft UEFI CA 2011. Dort wird der Debian-shim nicht akzeptiert. Prüfen mit mokutil --db: Steht dort „Windows UEFI CA 2023“, aber nicht „Microsoft Corporation UEFI CA 2011“, ist man betroffen.

5

Debian 12?

Wer noch Debian 12 einsetzt und ohnehin umsteigen will, findet die Anleitung im Beitrag Debian 12 auf 13 upgraden.

6

Befehle

Die Prüfbefehle für Windows und Linux stehen in der Checkliste weiter unten.

VIRTUALISIERUNG

Auch virtuelle Maschinen sind betroffen

Bei virtuellen Maschinen kommt meist OVMF/edk2 als UEFI-Firmware zum Einsatz. Die darin enthaltene Zertifikatssammlung ist die Ausgangsbasis für Secure Boot bei neuen VMs. Ein Hypervisor sollte deshalb bei einem normalen System-Update mit auf die Checkliste.

◐

Proxmox: der Marker

Steht in der VM-Konfiguration der EFI-Disk ms-cert=2023k, sind die neuen Zertifikate eingetragen. Hat eine EFI-Disk nur die 2011er-Zertifikate, werden Bootloader mit 2023er-Signatur abgelehnt. Proxmox warnt im Task-Log, wenn der Marker fehlt.

▤

Neue VMs

Ab pve-edk2-firmware 4.2025.05-1 enthalten neu angelegte EFI-Disks beide Zertifikatssätze.

↻

Bestehende VMs

Bei älteren EFI-Disks in der Hardware-Ansicht „Disk Action → Enroll Updated Certificates“ wählen (ab Proxmox 9.2 in der Oberfläche) oder den Befehl unten bei ausgeschalteter VM nutzen.

Proxmox: Zertifikate nachtragen

Aus der Proxmox-Dokumentation. Die VM-ID anpassen, die VM muss ausgeschaltet sein:

qm enroll-efi-keys 101

Bei Windows mit BitLocker vorher in der PowerShell der VM den Schutz aussetzen (für jedes BitLocker-Laufwerk) und danach wieder einschalten:

manage-bde -protectors -disable C:
manage-bde -protectors -enable C:

CHECKLISTE

Was sollte man jetzt prüfen?

Bei einem normalen, aktuellen Windows-11-PC ist Windows Update der wichtigste Schritt. Für Administratoren würde ich etwas genauer hinschauen.

1

Windows

  • Aktuelle Windows-Version und Updates
  • Secure Boot aktiviert?
  • Zertifikate schon auf 2023?
  • Ereignisprotokoll prüfen (siehe unten)
  • Firmware- und BIOS-Updates des Herstellers
  • BitLocker im Einsatz? Schlüssel sichern
2

Linux

  • Ist Secure Boot aktiv?
  • Welche Zertifikate stehen in der db?
  • Welche shim-Version ist installiert?
  • Gibt es ein Distributions-Update mit der neuen Signatur?
  • fwupd und Hersteller-Updates einspielen
3

Virtualisierung

  • OVMF/edk2 auf dem Hypervisor aktuell halten
  • Bestehende VM-Templates prüfen
  • Neue Templates kontrollieren
  • Secure-Boot-Konfigurationen dokumentieren
  • Bei verschlüsselten Systemen TPM- und PCR-Abhängigkeiten bedenken

Windows: Ereignisse und Status

Ereignis 1801 (Quelle TPM-WMI) heißt: Die neuen Zertifikate sind bei Windows angekommen, aber noch nicht in der Firmware angewendet. Ereignis 1808 heißt: Die Firmware hat sie. Der Registry-Schlüssel UEFICA2023Error sollte nicht existieren, es sei denn, bei der Verteilung ist ein Fehler aufgetreten. In der PowerShell als Administrator:

Confirm-SecureBootUEFI
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" -Name "UEFICA2023Status"

Linux: Status prüfen

Ob Secure Boot aktiv ist und welche Zertifikate in der UEFI-db stehen:

mokutil --sb-state
mokutil --db

MEIN FAZIT

Real, aber kein „Am Stichtag geht nichts mehr“

Das Thema ist real, aber es ist kein klassischer Fehler, bei dem am Stichtag Millionen Rechner nicht mehr starten. Microsoft ersetzt eine rund 15 Jahre alte Vertrauenskette durch neue Zertifikate. Die ersten sind bereits im Juni 2026 abgelaufen, am 19. Oktober 2026 folgt mit der Windows Production PCA 2011 der nächste wichtige Stichtag. Die Umstellung läuft aber schon und wird weiter über Windows Update ausgerollt.

Für normale Windows-Nutzer lautet meine Empfehlung schlicht: Updates installieren und die Firmware nicht jahrelang auf einem alten Stand lassen. Für Admins ist es etwas interessanter. Ältere Hardware, Linux mit Secure Boot, eigene Bootloader, BitLocker, TPM-Abhängigkeiten und virtuelle Maschinen sollte man einmal bewusst prüfen.

Die eigentliche Erkenntnis für mich: Secure Boot funktioniert normalerweise einfach, und man denkt kaum darüber nach. Wenn sich nach 15 Jahren die Root-of-Trust-Struktur ändert, merkt man plötzlich, wie viele Komponenten beim Start eines Systems voneinander abhängen. Server und Hypervisoren würde ich deshalb nicht erst prüfen, wenn der erste Bootloader nicht mehr akzeptiert wird.

FAQ

Häufige Fragen zu Secure Boot 2026

Doch, er startet weiter. Die Firmware prüft beim Start die Signatur, nicht das Ablaufdatum. Ohne die neuen Zertifikate bekommt das Gerät aber langfristig keine neuen Boot-Sicherheitsupdates mehr.

Die Microsoft Corporation KEK CA 2011 lief am 24. Juni 2026 ab, die Microsoft UEFI CA 2011 am 27. Juni 2026 und die Microsoft Windows Production PCA 2011 läuft am 19. Oktober 2026 ab.

Meist nicht. Windows Update verteilt die neuen Zertifikate schrittweise. Wichtig sind aktuelle Windows-Updates, ein aktuelles BIOS oder UEFI und aktiviertes Secure Boot. Auf Servern und in verwalteten Umgebungen sollte man den Status prüfen.

Ereignis 1801 (Quelle TPM-WMI) zeigt, dass die neuen Zertifikate bei Windows angekommen, aber noch nicht in der Firmware angewendet sind. Ereignis 1808 zeigt, dass die Firmware die neuen Zertifikate hat.

Ja. Der Linux-shim wird von Microsoft signiert. Bereits signierte Bootloader starten weiter, künftige shim-Versionen tragen aber nur noch die 2023er-Signatur. Debian liefert seit 13.6 einen shim mit beiden Signaturen, Red Hat und Derivate auf x86_64 ebenfalls.

Prüfen, ob bei der EFI-Disk der VM der Marker ms-cert=2023k gesetzt ist. Falls nicht, in der Oberfläche „Enroll Updated Certificates“ wählen oder bei ausgeschalteter VM qm enroll-efi-keys mit der VM-ID ausführen. Bei Windows mit BitLocker vorher den Schutz aussetzen.

Ja, in manchen Konfigurationen. Änderungen an den Secure-Boot-Daten können eine Abfrage des Wiederherstellungsschlüssels auslösen. Die Schlüssel sollte man vorher sichern.

Server und VMs prüfen lassen?

Ob Secure-Boot-Status, Proxmox-VMs oder Windows-Server: Nutzen Sie unsere IT-Leistungen.