Secure Boot: Am 19. Oktober läuft die Windows Production PCA 2011 ab – so prüfen und migrieren Sie Ihre Server

Die beiden Juni-Termine sind vorbei, jetzt folgt der letzte und wichtigste: Am 19. Oktober 2026 endet die Gültigkeit des Zertifikats, mit dem Microsoft seit 2011 den Windows-Bootmanager signiert. Clients mit Windows 11 haben die neuen 2023er-Zertifikate meist schon über Windows Update erhalten – Windows Server dagegen nicht automatisch. Höchste Zeit für eine Bestandsaufnahme.

Hintergrund: Drei Zertifikate, drei Termine

Secure Boot prüft beim Start, ob Firmware-Komponenten, Bootloader und Option-ROMs von einer vertrauenswürdigen Stelle signiert sind. Die Vertrauensanker liegen in den UEFI-Variablen KEK und DB. Die ursprünglichen Microsoft-Zertifikate stammen aus dem Jahr 2011 und erreichen 2026 ihr Laufzeitende:

Die gute Nachricht vorweg: Kein Server bleibt am 20. Oktober schwarz. Bereits installierte Bootloader starten weiter. Wer aber auf den alten Zertifikaten stehen bleibt, kann keine neuen Bootmanager und keine DBX-Sperrlisten-Updates mehr erhalten – und genau über diese Updates schließt Microsoft Lücken wie BlackLotus. Ein Server ohne 2023er-Zertifikate ist damit dauerhaft von boot-relevanten Sicherheitsupdates abgeschnitten.

Schritt 1: Status prüfen

Zunächst klären, ob Secure Boot überhaupt aktiv ist und welche Zertifikate bereits in KEK und DB stehen. Die folgenden Befehle laufen in einer PowerShell mit Administratorrechten:

# Secure Boot aktiv?
Confirm-SecureBootUEFI

# Ist die Windows UEFI CA 2023 bereits in der DB?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

# Ist der neue KEK eingespielt?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'KEK 2K CA 2023'

# Fortschritt des Microsoft-Servicing
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -ErrorAction SilentlyContinue |
    Select-Object UEFICA2023Status, UEFICA2023Error

Steht UEFICA2023Status auf Updated und liefern beide Abfragen True, ist der Server fertig. Zusätzlich lohnt ein Blick ins System-Ereignisprotokoll: Die Quelle TPM-WMI meldet mit Ereignis-ID 1801, dass Zertifikate noch fehlen, und mit 1808 den erfolgreichen Abschluss.

Schritt 2: Vorbereitung – BitLocker und Firmware

Beim Umstieg wird auch der Bootmanager durch eine mit der 2023er-CA signierte Fassung ersetzt. Auf Systemen mit BitLocker und TPM kann das – je nach PCR-Profil – eine Wiederherstellungsabfrage auslösen. Vor dem Rollout gilt daher:

• Für jedes betroffene Volume muss ein Recovery-Key im AD bzw. in Entra ID hinterlegt und abrufbar sein.
• Firmware/BIOS vorher auf den aktuellen Herstellerstand bringen. Einige ältere Mainboards nehmen KEK-Updates nur nach einem Firmware-Update an.
• Für physische Server einen Out-of-Band-Zugang (iLO, iDRAC, IPMI) bereithalten.
• Bei Hyper-V-VMs der Generation 2 zuerst den Host patchen; das KEK-Update in der VM hängt von der Unterstützung durch den Host ab. Vorlagen (Templates) nicht vergessen.

Schritt 3: Rollout anstoßen

Microsoft steuert die Aktualisierung über den Registry-Wert AvailableUpdates. Der Wert 0x5944 fordert alle Schritte an: DB-Einträge, KEK und neuen Bootmanager. Die geplante Aufgabe Secure-Boot-Update arbeitet die Anforderung ab; danach sind ein bis zwei Neustarts nötig.

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

Start-ScheduledTask -TaskName '\Microsoft\Windows\PI\Secure-Boot-Update'

# Neustart, danach Status aus Schritt 1 erneut prüfen
Restart-Computer

Für größere Umgebungen empfiehlt sich die Verteilung des Registry-Werts per GPO-Einstellung (Computerkonfiguration → Einstellungen → Windows-Einstellungen → Registrierung) in Wellen: erst ein Pilotring mit unterschiedlicher Hardware, dann die breite Masse, zuletzt die Domänencontroller.

Fallstricke

Compliance-Bezug

Die Zertifikatsumstellung ist kein Komfortthema. Der BSI IT-Grundschutz fordert in SYS.1.1 (Allgemeiner Server) und OPS.1.1.3 (Patch- und Änderungsmanagement) die geregelte Aktualisierung sicherheitsrelevanter Komponenten. NIS2 verlangt in Art. 21 Abs. 2 lit. e den Umgang mit Schwachstellen bei Wartung und Betrieb. Ein Server, der dauerhaft keine DBX-Updates mehr erhalten kann, ist in einem Audit eine offene Schwachstelle – Ausnahmen also sauber dokumentieren.

Fazit

Bis zum 19. Oktober bleiben gut zwei Wochen. Das reicht, wenn jetzt inventarisiert wird: Secure-Boot-Status erheben, BitLocker-Keys sichern, Firmware nachziehen, dann den Rollout in Wellen per GPO ausrollen. Wer das versäumt, hat am Stichtag keinen Ausfall – aber einen Bestand, der still und dauerhaft aus dem Boot-Patchprozess herausfällt.

Quellen: Microsoft Support – Windows Secure Boot certificate expiration and CA updates;