Secure Boot 2026: Zertifikatswechsel auf Windows Servern sauber meistern

Die Secure-Boot-Zertifikate von 2011 laufen 2026 aus. Diese Anleitung zeigt, wie Sie Windows Server rechtzeitig, BitLocker-sicher und mit zweifelsfreiem Nachweis auf die 2023er-Zertifikate umstellen – inklusive der beiden PowerShell-Skripte, die wir dafür einsetzen.

Stand: Juni 2026 · von byteland software solutions

Worum es geht

Secure Boot prüft bei jedem Start, ob der Bootcode vertrauenswürdig ist – anhand von Zertifikaten, die fest in der Firmware (UEFI) stecken. Die Zertifikate der 2011er-Generation laufen 2026 aus: die beiden Schlüssel-Zertifikate Microsoft KEK CA 2011 und Microsoft UEFI CA 2011 am 24. bzw. 27. Juni 2026, das Boot-Manager-Zertifikat Windows Production PCA 2011 am 19. Oktober 2026. Ersetzt werden sie durch die 2023er-Generation (KEK 2K CA 2023, Microsoft UEFI CA 2023, Windows UEFI CA 2023); ausgeliefert wird die Servicing-Mechanik über das Update KB5025885.

Wer den Wechsel verschläft, erlebt keinen spektakulären Knall – der Server bootet weiter, denn Secure Boot prüft keine Ablaufdaten wie ein TLS-Zertifikat. Aber er sitzt langfristig in der Sackgasse: keine signierten Boot-Sicherheitsupdates mehr und eine eingefrorene Sperrliste (DBX) gegen Bootkits wie BlackLotus.

Warum Server Handarbeit brauchen

Hier liegt der Haken, an dem sich ganze IT-Abteilungen die Nächte um die Ohren schlagen: Auf Servern erledigt Microsoft den Wechsel nicht von allein. Während Windows-PCs die 2023-Zertifikate über einen gesteuerten Rollout bekommen, verlangt Windows Server die manuelle Aktion – der zuständige Opt-In-Schalter (MicrosoftUpdateManagedOptIn) steht ab Werk auf „aus". Die 2023-Zertifikate liegen zwar per Windows Update auf der Platte, aber sie in die Firmware zu schreiben, passiert nicht von selbst: Gerade ältere Maschinen (z. B. Server 2016) bleiben stur auf NotStarted, bis jemand den Prozess anstößt.

Bei einer Handvoll Servern ist das ein Nachmittag. Bei hunderten Servern heißt es Nachtschicht, kalter Kaffee und die bange Frage, ob es auch wirklich überall sauber durchgelaufen ist. Genau diese Handarbeit – pro Server, mehrfach, mit Reboots dazwischen – nehmen die beiden unten gezeigten Skripte ab.

Was den Wechsel heikel macht

• Mehrstufig, mehrere Neustarts: Der Wechsel läuft in Etappen (erst das DB-Zertifikat, dann der KEK-Schlüssel, dann der Boot-Manager); pro Reboot wird meist nur eine Stufe verarbeitet. Unter zwei echten Neustarts geht es praktisch nie – Fast Startup zählt dabei nicht als Reboot.
• BitLocker will mitreden: Neue Zertifikate ändern den PCR7-Messwert – BitLocker kann dann einmalig nach dem Wiederherstellungsschlüssel fragen. Den vorher griffbereit halten.
• Kryptische Fehler: Hängt der KEK-Schritt mit 0x80070002, sieht das nach Totalschaden aus – ist aber meist nur eine fehlende Datei (Lösung weiter unten).
• Trügerische Erfolgsmeldung: Die üblichen Statuschecks verlassen sich auf ein Registry-Flag, das gern mal flunkert – besonders bei Server 2025, der die 2023-CA schon ab Werk mitbringt.

Die Anleitung, Schritt für Schritt

Vorab: aktuelle Updates einspielen, bei VMs einen Checkpoint setzen, PowerShell als Administrator öffnen, BitLocker-Status klären – und immer erst den Host, dann die VMs.

1. Schritt 0 – Ist Secure Boot überhaupt an? Confirm-SecureBootUEFI. True = los geht’s; False = erst im UEFI aktivieren; „Cmdlet not supported on this platform" = Legacy-BIOS, dann ist das ganze Thema gegenstandslos.
2. Schritt 1 – Update scharfschalten: in der Registry AvailableUpdates = 0x5944 setzen (KEK 2023 + Windows UEFI CA 2023 in der DB + 2023-signierter Boot-Manager). Wer es vorsichtig mag, nimmt 0x40 – nur das DB-Zertifikat, ohne Boot-Manager-Umschaltung.
3. Schritt 2 – Aufgabe wecken: die Windows-Aufgabe Secure-Boot-Update aktivieren (falls sie deaktiviert ist) und sofort starten – statt auf ihren 12-Stunden-Turnus zu warten.
4. Schritt 3 – Reboot-Reigen: neu starten, Aufgabe erneut antreten, noch einmal neu starten. Mindestens zwei Reboots, sonst bleibt eine Stufe liegen.
5. Schritt 4 – Nachweisen: nicht dem Registry-Flag glauben, sondern die echten Firmware-Variablen lesen (siehe „Der Clou").
6. Zum Schluss – die alten Zertifikate sperren (DBX): bewusst ganz am Ende und nur, wenn alles stabil läuft – die Sperrliste kann alte Boot- und Recovery-Medien unbootbar machen.

⚠️ Nutzung auf eigene Gefahr – keine Gewähr, keine Haftung. Alle hier gezeigten Skripte und Befehle haben wir nach bestem Wissen und Gewissen erstellt und in unserer eigenen Umgebung erfolgreich eingesetzt – eine Gewähr für Richtigkeit, Vollständigkeit oder Eignung für einen bestimmten Zweck ist das ausdrücklich nicht. Secure Boot, Firmware und BitLocker sind heikles Terrain: Prüfen Sie jedes Skript, bevor Sie es ausführen, testen Sie zuerst an einem unkritischen System und sorgen Sie für ein Backup bzw. einen Checkpoint. Die Nutzung erfolgt vollständig auf eigenes Risiko; eine Haftung für Schäden aus der Verwendung übernehmen wir nicht – ausgenommen bei Vorsatz und grober Fahrlässigkeit sowie bei Schäden aus der Verletzung von Leben, Körper oder Gesundheit. Was auf Ihren Servern geschieht, liegt in Ihrer Verantwortung.

Skript 1 – Den Wechsel anstoßen (Schritt 0 bis 2)

Setzt das Update-Flag, aktiviert und startet die Servicing-Aufgabe – mit Vorab-Check auf Admin-Rechte und aktives Secure Boot, damit man sich nicht selbst ein Bein stellt:

#Requires -RunAsAdministrator
<#
.SYNOPSIS
    Secure Boot 2023-Zertifikate ausrollen - Schritt 1 + 2.
.DESCRIPTION
    Setzt AvailableUpdates = 0x5944 (KEK CA 2023 + Windows UEFI CA 2023 (DB)
    + 2023-signierter Boot-Manager) und aktiviert/startet die Servicing-Task.
    Mit Vorab-Check: Admin-Rechte + Secure Boot aktiv (Schritt 0).

    NACH diesem Skript: VM neu starten, Task erneut starten, erneut neu starten
    (mind. 2 Reboots). Danach Status mit SecureBoot.ps1 / UEFICA2023Status pruefen.
.NOTES
    Konservative Alternative: -Value 0x40 (nur DB-Zert, ohne Boot-Manager).
    Quelle: Microsoft Secure Boot Playbook 2026 / R. Hicks.
    byteland - erstellt 2026-06-05
#>

$ErrorActionPreference = 'Stop'
$RegPath  = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
$TaskName = '\Microsoft\Windows\PI\Secure-Boot-Update'
$Value    = 0x5944   # konservativ: 0x40 (nur Windows UEFI CA 2023 in DB)

Write-Host "=== Secure Boot 2023 - Schritt 1+2 ===" -ForegroundColor Cyan

# --- Schritt 0: Secure Boot aktiv? ---------------------------------------
try {
    $sb = Confirm-SecureBootUEFI
} catch {
    Write-Host "[ABBRUCH] Secure Boot nicht abfragbar - Maschine vermutlich im Legacy-BIOS-Modus (kein UEFI)." -ForegroundColor Red
    return
}
if (-not $sb) {
    Write-Host "[ABBRUCH] Secure Boot ist DEAKTIVIERT. Erst im UEFI/VM-Einstellungen aktivieren, dann erneut ausfuehren." -ForegroundColor Red
    return
}
Write-Host "[OK] Secure Boot ist aktiv." -ForegroundColor Green

# --- Schritt 1: AvailableUpdates setzen ----------------------------------
try {
    Set-ItemProperty -Path $RegPath -Name 'AvailableUpdates' -Value $Value -Type DWord
    $check = (Get-ItemProperty -Path $RegPath -Name 'AvailableUpdates').AvailableUpdates
    Write-Host ("[OK] AvailableUpdates gesetzt auf 0x{0:X}." -f $check) -ForegroundColor Green
} catch {
    Write-Host "[FEHLER] Konnte AvailableUpdates nicht setzen: $($_.Exception.Message)" -ForegroundColor Red
    return
}

# --- Schritt 2: Task aktivieren + starten --------------------------------
try {
    Enable-ScheduledTask -TaskName $TaskName | Out-Null
    Start-ScheduledTask  -TaskName $TaskName
    Write-Host "[OK] Scheduled Task 'Secure-Boot-Update' aktiviert und gestartet." -ForegroundColor Green
} catch {
    Write-Host "[FEHLER] Task-Aktion fehlgeschlagen: $($_.Exception.Message)" -ForegroundColor Red
    return
}

Write-Host ""
Write-Host ">>> NAECHSTE SCHRITTE (manuell):" -ForegroundColor Yellow
Write-Host "    1. VM jetzt NEU STARTEN." -ForegroundColor Yellow
Write-Host "    2. Nach dem Hochfahren Task erneut starten:" -ForegroundColor Yellow
Write-Host "       Start-ScheduledTask -TaskName '$TaskName'" -ForegroundColor Yellow
Write-Host "    3. ERNEUT neu starten (mind. 2 Reboots gesamt)." -ForegroundColor Yellow
Write-Host "    4. Pruefen: UEFICA2023Status soll 'Updated' sein, Event 1808 erscheint." -ForegroundColor Yellow

Der Clou: Firmware-Wahrheit statt Registry-Flag

Microsofts Standard-Prüfung – auch das offizielle MS-Skript – macht das Flag UEFICA2023Status = Updated zur Pflichtbedingung. Nur: Server, die das 2023-Zertifikat schon ab Werk in der Firmware haben (Server 2025), durchlaufen nie das Registry-Servicing – das Flag entsteht nie, und prompt werden sie fälschlich als „nicht fertig" gemeldet. Wir fragen stattdessen die echten UEFI-Variablen ab, db und KEK – die nackte Grundwahrheit:

# Liegen die 2023-Zertifikate physisch in der Firmware?
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Windows UEFI CA 2023'   # True
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'KEK 2K CA 2023'          # True
# True -> erledigt, voellig unabhaengig von irgendwelchen Registry-Flags

Skript 2 – Zweifelsfrei prüfen (flottentauglich)

Das Prüfskript liest db und KEK direkt aus der Firmware, gleicht sie mit Registry-Status und Event-Log ab und fällt ein eindeutiges Urteil mit Exit-Code (0 = fertig, 1 = in Arbeit, 2 = nicht begonnen, 3 = nicht zutreffend) – ideal, um in einem Rutsch eine ganze Server-Flotte abzuklopfen, statt sich von Hand durch hunderte Kisten zu klicken:

#Requires -RunAsAdministrator
<#
.SYNOPSIS
    Secure Boot 2023 - UNZWEIFELHAFTE Vollstaendigkeitspruefung.
.DESCRIPTION
    Liest die ECHTEN UEFI-Firmware-Variablen (db + KEK) als Grundwahrheit aus
    und kreuzvergleicht mit Registry-Status, AvailableUpdates und Event 1808.
    Gibt ein eindeutiges Gesamturteil + Exit-Code aus.
    Stoesst vorab die Secure-Boot-Update-Task an, um einen laufenden Rollout
    weiterzuschieben - harmlos/No-Op, falls bereits fertig.

    MASSGEBLICH ist die Firmware (db + KEK). UEFICA2023Status und Event 1808
    sind nur ZUSATZBELEGE - ihr Fehlen ist KEIN Mangel (z.B. wenn die 2023-CA
    ab Werk in der Firmware liegt, Server 2025: dann lief nie ein
    Registry-Servicing, also kein Status-Key und kein Event 1808).

    Exit-Codes (fuer Automatisierung / Flotten-Scan):
      0 = VOLLSTAENDIG installiert (db + KEK in Firmware, nichts offen, kein Fehler)
      1 = TEILWEISE / in Arbeit (begonnen, Firmware aber noch nicht komplett)
      2 = NICHT BEGONNEN (Secure Boot an, aber nichts ausgerollt)
      3 = NICHT ZUTREFFEND (Secure Boot aus oder Legacy-BIOS)
.NOTES
    byteland - erstellt 2026-06-05. Quelle: MS Secure Boot Playbook 2026.
    v2 (2026-06-19): Urteil firmware-basiert. UEFICA2023Status + Event 1808
    sind nur noch Zusatzbeleg -> kein Fehlalarm ("IN ARBEIT") mehr bei ab Werk
    versorgten Systemen (db+KEK da, AvailableUpdates=0x0, aber kein Status-Key).
#>

$SBKey  = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
$SvcKey = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing'

function Get-RegVal {
    param([string[]]$Paths,[string]$Name)
    foreach ($p in $Paths) {
        try { return (Get-ItemProperty -Path $p -Name $Name -ErrorAction Stop).$Name } catch {}
    }
    return $null
}
function Test-UefiVarContains {
    param([string]$VarName,[string[]]$Patterns)
    try {
        $bytes = (Get-SecureBootUEFI -Name $VarName -ErrorAction Stop).bytes
        $txt   = [Text.Encoding]::ASCII.GetString($bytes)
        foreach ($pat in $Patterns) { if ($txt -match $pat) { return $true } }
        return $false
    } catch { return $null }   # null = nicht lesbar (z.B. Secure Boot aus)
}
function Line { param($Label,$Ok,$Detail)
    $sym = if ($Ok -eq $true) {'[ OK ]'} elseif ($Ok -eq $false) {'[FEHLT]'} else {'[ ?? ]'}
    $col = if ($Ok -eq $true) {'Green'} elseif ($Ok -eq $false) {'Red'} else {'Yellow'}
    Write-Host ("  {0,-7} {1,-42} {2}" -f $sym,$Label,$Detail) -ForegroundColor $col
}

Write-Host ""
Write-Host "==== Secure Boot 2023 - Vollstaendigkeitspruefung ====" -ForegroundColor Cyan
Write-Host ("  Host: {0}   Zeit: {1}" -f $env:COMPUTERNAME,(Get-Date)) -ForegroundColor Gray
Write-Host ""

# --- Schritt 0: Secure Boot aktiv? ----------------------------------------
$sbActive = $null
try { $sbActive = Confirm-SecureBootUEFI } catch { $sbActive = $null }

if ($sbActive -ne $true) {
    if ($null -eq $sbActive) {
        Line 'Secure Boot' $false 'nicht abfragbar -> Legacy-BIOS (kein UEFI)'
    } else {
        Line 'Secure Boot' $false 'DEAKTIVIERT'
    }
    Write-Host ""
    Write-Host "  >>> URTEIL: NICHT ZUTREFFEND - Secure Boot ist aus/Legacy." -ForegroundColor Yellow
    Write-Host "      Der Zertifikatsablauf 2026 hat hier keine Auswirkung." -ForegroundColor Yellow
    Write-Host ""
    exit 3
}
Line 'Secure Boot aktiv' $true 'True'

# --- Laufenden Rollout anstossen ------------------------------------------
# Start der Servicing-Task ist harmlos: auf fertigen Maschinen sieht sie keine
# offenen Action-Bits und tut nichts; auf laufenden schiebt sie den Rollout an.
try {
    Start-ScheduledTask -TaskName '\Microsoft\Windows\PI\Secure-Boot-Update' -ErrorAction Stop
    Write-Host '  [INFO] Secure-Boot-Update-Task angestossen (No-Op, falls bereits fertig).' -ForegroundColor DarkGray
} catch {
    Write-Host '  [INFO] Secure-Boot-Update-Task nicht startbar - ignoriert (reine Diagnose).' -ForegroundColor DarkGray
}
Write-Host ''

# --- Grundwahrheit: echte Firmware-Variablen ------------------------------
$dbHas2023  = Test-UefiVarContains 'db'  @('Windows UEFI CA 2023')
$dbMsOpt    = Test-UefiVarContains 'db'  @('Microsoft UEFI CA 2023','Option ROM UEFI CA 2023')
$kekHas2023 = Test-UefiVarContains 'KEK' @('KEK 2K CA 2023','KEK CA 2023')

Line 'DB: Windows UEFI CA 2023 (Grundwahrheit)' $dbHas2023 $(if($dbHas2023){'physisch in Firmware-DB'}else{'nicht in DB'})
Line 'KEK: Microsoft KEK 2K CA 2023 (Grundwahrheit)' $kekHas2023 $(if($kekHas2023){'physisch in Firmware-KEK'}else{'nicht in KEK'})

# --- Corroboration: Registry + Events -------------------------------------
$avail   = Get-RegVal @($SBKey,$SvcKey) 'AvailableUpdates'
$status  = Get-RegVal @($SvcKey,$SBKey) 'UEFICA2023Status'
$errVal  = Get-RegVal @($SvcKey,$SBKey) 'UEFICA2023Error'
$availHex = if ($null -ne $avail) { ('0x{0:X}' -f [int]$avail) } else { '(fehlt)' }

# 0x4000 ist ein MODIFIER-Bit (wird laut MS NICHT geloescht). Finaler Wert
# 0x0 ODER 0x4000 = fertig. Offene Arbeit nur, wenn Action-Bits (< 0x4000) gesetzt.
$availClean    = ($null -eq $avail) -or ((([int]$avail) -band 0x3FFF) -eq 0)
$fwComplete    = ($dbHas2023 -eq $true) -and ($kekHas2023 -eq $true)   # FIRMWARE = Grundwahrheit
$statusUpdated = ($status -eq 'Updated')
$noError       = ($null -eq $errVal)

# UEFICA2023Status ist nur ZUSATZBELEG: 'Updated' ODER (Firmware komplett +
# Key fehlt => ab Werk versorgt / kein Servicing noetig) gilt als in Ordnung.
$statusOk = $statusUpdated -or ($fwComplete -and ($null -eq $status))
$statusDetail = if ($statusUpdated) { 'Updated' }
                elseif ($fwComplete -and ($null -eq $status)) { 'kein Servicing-Key - 2023-CA ab Werk in Firmware (db/KEK massgeblich)' }
                elseif ($null -eq $status) { '(Key fehlt)' }
                else { [string]$status }

Line 'AvailableUpdates ohne offene Action-Bits' $availClean $availHex
Line 'UEFICA2023Status (Zusatzbeleg)' $statusOk $statusDetail
Line 'Kein UEFICA2023Error-Key'    $noError $(if($noError){'kein Fehler'}else{"Fehler: $errVal"})

# Event 1808 ist nur ZUSATZBELEG (kann durch Log-Rotation fehlen oder bei
# ab-Werk-Versorgung nie entstanden sein). Massgebend ist die Firmware (db/KEK).
$evt1808 = $null
try { $evt1808 = Get-WinEvent -FilterHashtable @{LogName='System';Id=1808} -MaxEvents 1 -ErrorAction Stop } catch {}
$has1808 = [bool]$evt1808
$sym1808 = if ($has1808) { '[ OK ]' } else { '[INFO]' }
$col1808 = if ($has1808) { 'Green' } else { 'DarkGray' }
$txt1808 = if ($has1808) { 'vorhanden (Zusatzbeleg)' }
           elseif ($fwComplete) { 'kein 1808 - unkritisch (Firmware db/KEK belegt den Abschluss)' }
           else { 'kein 1808' }
Write-Host ("  {0,-7} {1,-42} {2}" -f $sym1808,'Event 1808 (optionaler Zusatzbeleg)',$txt1808) -ForegroundColor $col1808

# --- Gesamturteil ----------------------------------------------------------
# MASSGEBLICH: Firmware (db+KEK) komplett, keine offenen Action-Bits, kein Fehler.
# Status=Updated / Event 1808 sind Belege, aber kein Muss (ab-Werk-Faelle).
Write-Host ""
$fullyDone = $fwComplete -and $availClean -and $noError
$started   = ($dbHas2023 -eq $true) -or ($status -eq 'Updated') -or ($status -eq 'InProgress') `
             -or ($null -ne $avail -and [int]$avail -ne 0)

if ($fullyDone) {
    Write-Host "  >>> URTEIL: VOLLSTAENDIG & UNZWEIFELHAFT INSTALLIERT." -ForegroundColor Green
    Write-Host "      DB + KEK in Firmware, keine Reststeps, kein Fehler." -ForegroundColor Green
    if (-not $statusUpdated) {
        Write-Host "      (UEFICA2023Status/Event 1808 fehlen - unkritisch: ab Werk versorgt; Firmware ist massgeblich.)" -ForegroundColor DarkGray
    }
    $code = 0
} elseif ($started) {
    Write-Host "  >>> URTEIL: TEILWEISE / IN ARBEIT - noch NICHT vollstaendig." -ForegroundColor Yellow
    Write-Host "      DB oder KEK fehlt noch in der Firmware. Reboot(s)/Reststep ausstehend." -ForegroundColor Yellow
    $code = 1
} else {
    Write-Host "  >>> URTEIL: NICHT BEGONNEN - Secure Boot an, aber kein 2023-Zert ausgerollt." -ForegroundColor Red
    Write-Host "      Deploy-Skript (Schritt 1+2) ausfuehren." -ForegroundColor Red
    $code = 2
}
Write-Host ""
Write-Host ("  Exit-Code: {0}" -f $code) -ForegroundColor Gray
Write-Host ""
exit $code

Wenn der KEK-Schritt hängt (0x80070002)

0x80070002 heißt schlicht „Datei nicht gefunden": Dem Update fehlen seine Payload-Dateien unter C:\Windows\System32\SecureBootUpdates\. Mit den Bordmitteln zurückholen und neu antreten:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
# danach Windows-Updates + Neustart, dann den Schritt neu anstossen:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Ergebnis: Die ganze Server-Flotte bleibt dauerhaft update- und startfähig, die Umstellung läuft im Wartungsfenster ohne böse Überraschungen – und das Prüfskript urteilt selbst dort noch richtig, wo Microsofts eigene Standard-Prüfung fälschlich „nicht fertig" meldet, obwohl längst alles erledigt ist.

Häufige Fragen