public/SecureBootCA2023
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Zapracovani zmen z 2 GIT projektu

Browse Source
This commit is contained in:
Petr Stepan
2026-06-05 18:44:33 +02:00
parent d6cefff29b
commit fb6bb88823
2 changed files with 583 additions and 850 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Invoke-SecureBootRemediation.ps1
+377 -524
View File
File diff suppressed because it is too large Load Diff
README.md
+140 -260
View File
@@ -1,310 +1,190 @@
# Secure Boot Certificate Remediation
# Secure Boot CA 2023 — kontrola a remediace
Sada PowerShell skriptů pro audit a remediari expirujících Secure Boot certifikátů na Windows Serverech (fyzické servery, Hyper-V VM, VMware VM).
Jediný PowerShell skript **`Invoke-SecureBootRemediation.ps1`** pro audit a řízenou remediaci expirujících Secure Boot certifikátů na Windows Serverech (fyzické stroje, Hyper-V VM, VMware VM).
---
## 1. Co řešíme
### Problém
Microsoft v upozornění [KB5062710](https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e) oznámil, že původní Secure Boot certifikáty z roku **2011** expirují v průběhu roku **2026**. Tyto certifikáty jsou uloženy přímo ve firmware (UEFI KEK a DB databázích) a zajišťují důvěryhodnost celého boot procesu.
Microsoft oznámil prostřednictvím [KB5062710](https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e), že původní Secure Boot certifikáty z roku 2011 expirují v průběhu roku 2026. Tyto certifikáty jsou uloženy přímo ve firmware serveru (UEFI KEK a DB databázích) a zajišťují důvěryhodnost celého boot procesu.
### Expirující certifikáty a termíny
| Certifikát | Umístění | Expirace | Náhrada |
| Certifikát | Umístění | Expirace | Náhrada 2023 |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | KEK | **24. června 2026** | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | DB | **27. června 2026** | Microsoft UEFI CA 2023 + Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | DB | 19. října 2026 | Windows UEFI CA 2023 |
| Microsoft Corporation KEK CA 2011 | KEK | **24. 6. 2026** | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | DB | **27. 6. 2026** | Microsoft UEFI CA 2023 + Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | DB | 19. 10. 2026 | Windows UEFI CA 2023 |
> **Urgentní:** První dvě expirace jsou 24. a 27. června 2026 — audit je nutné provést okamžitě.
**Dopad, pokud se nic neudělá:** server bude dál bootovat, ale přestane přijímat nové ochrany boot procesu — aktualizace Boot Manageru, revokace (DBX) a mitigace nově objevených boot-level zranitelností. Postupně se sníží ochrana a ovlivní to scénáře závislé na Secure Boot důvěře (BitLocker hardening, third-party bootloadery).
### Dopad pokud se nic neudělá
Servery bez nových certifikátů budou **nadále normálně bootovat** — certifikáty sice expirují, ale UEFI firmware je při bootu nevyhodnocuje jako neplatné. Problém nastane postupně:
- Server přestane být schopen přijímat nové aktualizace Secure Boot databází a revokačních seznamů (DBX)
- Nelze aplikovat mitigace nově objevených boot-level zranitelností
- Mohou být ovlivněny scénáře závislé na Secure Boot důvěře: BitLocker hardening, third-party bootloadery, attestation
- Při případném resetu UEFI na factory defaults nebo reinstalaci firmware může boot selhat
### Které servery jsou ohroženy
Ohroženy jsou servery, které splňují **všechny** následující podmínky:
- Mají UEFI firmware (ne Legacy BIOS)
- Mají zapnutý Secure Boot
- Ještě neobdržely nové 2023 certifikáty (typicky přes Windows Update nebo manuální rollout)
Servery s Legacy BIOS nebo vypnutým Secure Boot nejsou přímo ohroženy, ale je vhodné je zdokumentovat.
**Pozor — co je skutečné „hotovo":** nestačí jen mít nové certifikáty v KEK/DB. Aktualizace je dokončená, až když se systém **reálně bootuje z Boot Manageru podepsaného Windows UEFI CA 2023** (signalizuje `WindowsUEFICA2023Capable = 2` / Event 1808). Tento poslední krok se aplikuje **až po restartu**. Skript proto kontroluje i Boot Manager, ne jen certifikáty.
---
## 2. Detekce — jak zjistit aktuální stav
## 2. Jak skript správně použít
### Skripty
### Požadavky
| Skript | Účel |
- **Windows PowerShell 5.1+**, spuštěno jako **Administrator**
- Build Windows z **14. 10. 2025 nebo novější** ([KB5066835](https://support.microsoft.com/en-us/topic/october-14-2025-kb5066835-os-builds-26200-6899-and-26100-6899-1db237d8-9f3b-4218-9515-3e0a32729685)) — bez něj neexistují servicing registry klíče ani úloha. Skript na to upozorní.
- Žádné externí moduly. UEFI databáze čte nativně.
### Skript NIKDY nerestartuje server
Restart je nutný k dokončení aktualizace, ale necháváme ho **na vás** (plánované okno, ohled na BitLocker). Skript jen jasně řekne, kdy je restart potřeba.
### Typický průběh (interaktivně)
```powershell
# 1) Spustit na serveru jako Administrator
.\Invoke-SecureBootRemediation.ps1
```
Skript provede detekci, ukáže **checklist** a u stavů, kde to dává smysl, se **zeptá**, zda remediaci aplikovat. Po souhlasu nastaví registry a spustí servicing úlohu (počká na ni). Pak:
```text
2) Naplánujte RESTART serveru
3) Po restartu spusťte skript znovu
4) Opakujte, dokud checklist nebude celý zelený (HOTOVO)
```
Aktualizace se aplikuje **po částech na více restartů** — hodnota `AvailableUpdates` postupně klesá `0x5944 → 0x5904 → 0x5104 → 0x4104 → 0x4100 → 0x4000 → 0x0`. Cílový stav je `AvailableUpdates=0x0`, `UEFICA2023Status=Updated`, `WindowsUEFICA2023Capable=2`.
### Důležité před restartem
Pokud má server **BitLocker s ochranou vázanou na TPM/PCR7**, změna Boot Manageru může vyvolat recovery prompt. Skript BitLocker stav zobrazí a zvýrazní — **před restartem ověřte recovery key**.
### Parametry
| Parametr | Účel |
|---|---|
| `Invoke-SecureBootAudit.ps1` | Audit jednoho serveru — vrací JSON + human-readable souhrn |
| `Start-SecureBootFleetAudit.ps1` | Hromadný audit celé sítě — vstup CSV, výstup agregovaný CSV/JSON |
| *(bez parametru)* | Interaktivní detekce → dotaz → remediace (bez restartu) |
| `-CheckOnly` | Jen detekce + checklist + **exit kód** (0 = hotovo, 1 = nutná akce, 2 = blokováno). Bez změn a bez dotazu. Vhodné pro RMM/monitoring. |
| `-WhatIf` | Ukáže, co by remediace udělala, bez provedení změn |
| `-AssumeYes` | Neinteraktivně aplikuje remediaci (pokud je smysluplná). Stále bez restartu. |
| `-Force` | Aplikuje i ve stavech, kdy to skript jinak nedoporučuje |
| `-SkipScheduledTask` | Nastaví registry, ale nespustí úlohu (spustí se sama, cca á 12 h) |
| `-SkipBootManagerFileCheck` | Vynechá mount ESP + `certutil`. Dokončení se i tak pozná z `WindowsUEFICA2023Capable=2` / Event 1808 / 1799. |
| `-RegisterResume` | Po remediaci vyžadující restart nastaví `RunOnce`, který po PŘÍŠTÍM (ručním) restartu sám spustí `-CheckOnly`. Nikdy nerestartuje. |
| `-Detailed` | Rozšířený rozpis (certifikáty, události, Boot Manager chain, bit-rozklad `AvailableUpdates`) |
| `-PassThru` | Vrátí výsledný objekt do pipeline |
| `-LogPath <cesta>` | Vlastní cesta k logu (jinak log vzniká vedle skriptu jen při reálné remediaci) |
### Spuštění auditu
**Lokálně na serveru** (spustit jako Administrator):
### Příklady
```powershell
.\Invoke-SecureBootAudit.ps1
# Jen kontrola stavu (pro skript/monitoring), bez zásahu
.\Invoke-SecureBootRemediation.ps1 -CheckOnly
# Náhled co by se stalo, bez změn
.\Invoke-SecureBootRemediation.ps1 -WhatIf
# Neinteraktivní aplikace + auto-kontrola po příštím restartu
.\Invoke-SecureBootRemediation.ps1 -AssumeYes -RegisterResume
# Plný rozpis pro diagnostiku
.\Invoke-SecureBootRemediation.ps1 -CheckOnly -Detailed
```
**Vzdáleně z workstation:**
---
```powershell
Invoke-Command -ComputerName SERVER01 -FilePath .\Invoke-SecureBootAudit.ps1 -ArgumentList $null, $false, $true
```
## 3. Co skript dělá (detailně)
**Hromadně ze seznamu serverů (CSV soubor se sloupcem `ServerName`):**
### Fázový checklist
```powershell
.\Start-SecureBootFleetAudit.ps1 -ServerListPath .\servers.csv -OutputPath .\audit_results\
```
Server je „HOTOVO" teprve když projdou všechny **povinné** fáze. Volitelné fáze jsou jen informativní.
**Hromadně přímo ze seznamu:**
```powershell
.\Start-SecureBootFleetAudit.ps1 -ServerName SERVER01,SERVER02,SERVER03
```
### Výsledné kategorie
Každý server je zařazen do jedné z těchto kategorií:
| Kategorie | Popis | Doporučená akce |
| Fáze | Povinná | Splněno když |
|---|---|---|
| ✅ **OK** | Má nové 2023 certifikáty, Secure Boot aktivní | Žádná akce |
| ✅ **OK_TRANSITION** | Má 2023 i stará 2011 certifikáty (přechodný stav) | Žádná akce, monitorovat |
| ⚠️ **UPDATE_NEEDED** | Má pouze 2011 certifikáty, Secure Boot aktivní | Naplánovat rollout |
| ⏳ **UPDATE_PENDING** | Registry nastaveny, čeká na restart | Restartovat server |
| 🔧 **FIRMWARE_UPDATE_NEEDED** | `WindowsUEFICA2023Capable=0` — firmware nepodporuje nové certifikáty | Update firmware u OEM |
| ⏸️ **SECUREBOOT_DISABLED** | Secure Boot existuje v UEFI, ale není zapnuté | Rozhodnutí o enablementu |
| ❌ **NO_SECUREBOOT** | Legacy BIOS — Secure Boot vůbec neexistuje | Dokumentovat jako výjimku |
| ❌ **NO_SECUREBOOT_VM** | VM bez Secure Boot (Gen1 / bez vTPM / BIOS mode) | Dokumentovat jako výjimku |
| 🔴 **UPDATE_FAILED** | Selhání aktualizace (viz EventID níže) | Troubleshooting |
| Secure Boot zapnutý | ✅ | `Confirm-SecureBootUEFI` = True |
| Servicing task k dispozici | ✅ | existuje `\Microsoft\Windows\PI\Secure-Boot-Update` |
| KEK: Microsoft Corporation KEK 2K CA 2023 | ✅ | cert v KEK databázi |
| DB: Windows UEFI CA 2023 | ✅ | cert v DB databázi |
| Boot Manager aktivní (2023) | ✅ | `WindowsUEFICA2023Capable=2` / Event 1808 / 1799 |
| DB: Microsoft UEFI CA 2023 (3rd-party) | — | volitelné (pro option ROM / non-Windows boot) |
| DB: Option ROM UEFI CA 2023 | — | volitelné |
| DBX: revokace starého boot manageru 2011 | — | volitelné (finální hardening) |
### Registry hodnoty a jejich výklad
V checklistu: `[✓]` splněno (zeleně), `[ ]` zbývá, `[✗]` chyba/blokováno. Zvýrazní se aktuální krok („← vyžaduje RESTART").
Klíč `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing`:
### Detekce — odkud čte
| Hodnota | Typ | Výklad |
- **Prostředí a HW** (WMI/CIM): fyzický / Hyper-V VM / VMware VM, výrobce, model, BIOS verze a datum
- **Secure Boot stav** a **operating mode** (User / Deployed / **Setup** / Audit) ze standardních UEFI proměnných
- **Certifikáty** v KEK / DB / DBX — primárně parsováním `EFI_SIGNATURE_LIST` na X.509 (subject, thumbprint, platnost), s ASCII fallbackem
- **Boot Manager** `bootmgfw.efi` na ESP — read-only mount + `certutil -dump` (staged podpis); aktivní stav z registru/eventů
- **Registry** `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot[\Servicing]`:
`AvailableUpdates`, `MicrosoftUpdateManagedOptIn`, `HighConfidenceOptOut`, `UEFICA2023Status` (REG_SZ: NotStarted/InProgress/**Updated**), `UEFICA2023Error`, `UEFICA2023ErrorEvent`, `WindowsUEFICA2023Capable` (0/1/**2**), `ConfidenceLevel`
- **BitLocker** systémové jednotky: stav ochrany a typ protektoru (zvýraznění TPM/PCR7 rizika)
- **Event Log** (System, zdroj TPM-WMI): 1795, 1796, 1799, 1800, 1801, 1802, 1803, 1808
### Vyhodnocení — kategorie
| Kategorie | Význam | Akce |
|---|---|---|
| `UEFICA2023Status = 0` | NotStarted | Aktualizace ještě nebyla spuštěna |
| `UEFICA2023Status = 1` | InProgress | Aktualizace probíhá |
| `UEFICA2023Status = 2` | Success | Aktualizace proběhla, čeká se na restart |
| `UEFICA2023Status = 3` | Failed | Aktualizace selhala — viz `UEFICA2023Error` |
| `WindowsUEFICA2023Capable = 0` | — | Firmware nepodporuje nové certifikáty (potřeba update OEM firmware) |
| `UEFICA2023Error` | HRESULT kód | Chybový kód při selhání |
| **OK** | kompletní 2023 sada, aktivní Boot Manager, 2011 odstraněny | žádná |
| **OK_TRANSITION** | 2023 i aktivní Boot Manager hotové, 2011 ještě přítomné (normální) | žádná, monitorovat |
| **UPDATE_NEEDED** | nic 2023 nenasazeno | zahájit remediaci |
| **UPDATE_PARTIAL** | část nasazena, chybí KEK/DB | pokračovat v cyklu |
| **UPDATE_PENDING** | KEK i DB hotové, zbývá aktivovat Boot Manager | **RESTART**, pak znovu zkontrolovat |
| **UPDATE_FAILED** | Event 1795 / `UEFICA2023ErrorEvent` / status Failed | firmware/OEM, troubleshooting |
| **FIRMWARE_UPDATE_NEEDED** | ConfidenceLevel „Temporarily Paused" / Event 1802 | update firmwaru u OEM |
| **NOT_SUPPORTED** | ConfidenceLevel „Not Supported" | dokumentovat jako výjimku |
| **SETUP_MODE** | Secure Boot v Setup Mode (chybí enrolled PK) | obnovit klíče v UEFI |
| **TASK_MISSING** | chybí servicing úloha (starý build) | nainstalovat KB5066835+ |
| **SECUREBOOT_DISABLED** | Secure Boot vypnutý | rozhodnout o zapnutí |
| **NO_SECUREBOOT / _VM** | Legacy BIOS / VM bez vTPM | výjimka |
Klíč `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot`:
### Remediace (jen po souhlasu, sekvenčně)
| Hodnota | Výklad |
|---|---|
| `AvailableUpdates` | Bitmaska dostupných aktualizací; 0x5944 = plná sada (nastavíme při remediaci) |
| `HighConfidenceOptOut = 1` | Server se odhlásil z high-confidence update path — **zablokuje aktualizaci** |
1. **Registry** — nastaví `MicrosoftUpdateManagedOptIn=1`, `AvailableUpdates=0x5944`, `HighConfidenceOptOut=0`; zápis se ověří zpětným čtením, než pokračuje dál.
2. **Servicing úloha** — spustí `\Microsoft\Windows\PI\Secure-Boot-Update` a **čeká na změnu** `AvailableUpdates` (nebo na doběh úlohy, timeout 180 s).
3. **Ověření** — znovu proběhne detekce a ukáže aktualizovaný stav fází.
### EventID v System logu
Skript pak vypíše další kroky (restart, BitLocker, opakování) — **bez restartu**.
| EventID | Zdroj | Typ | Výklad |
|---|---|---|---|
| **1808** | Microsoft-Windows-Eventlog | Information | ✅ Certifikáty úspěšně aplikovány — aktualizace proběhla v pořádku |
| **1801** | Microsoft-Windows-Eventlog | Error | ❌ Certifikáty NEBYLY aplikovány — selhání high-confidence update |
| **1795** | Microsoft-Windows-Eventlog | Error | ❌ Selhání aktualizace na Hyper-V VM (viz níže) |
| **1796** | Microsoft-Windows-Eventlog | Information | Průběhová informace |
| **1800** | Microsoft-Windows-Eventlog | Information | Průběhová informace |
| **1802** | Microsoft-Windows-Eventlog | Information | Aktualizace čeká na restart |
| **1803** | Microsoft-Windows-Eventlog | Information | Aktualizace probíhá |
### Stav napříč restarty
Rychlé ověření z PowerShell:
Průběh se ukládá do `%ProgramData%\SecureBootCA2023\state.json` (číslo cyklu, kategorie, hodnota). S `-RegisterResume` se přes `RunOnce` po dalším restartu sama spustí `-CheckOnly` (žádné auto-aplikování, žádný auto-restart).
```powershell
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = @(1795,1801,1808) } -MaxEvents 10 |
Select-Object TimeCreated, Id, Message | Format-List
```
### Výstup
### Specifika prostředí
- Stručný **barevný** souhrn: server, checklist, registry/firmware, verdikt
- Český, faktický, nezahlcuje; důležité informace jsou zvýrazněné
- Volitelný **log** (cesta se vypíše), `-Detailed` rozpis, `-PassThru` objekt
- `-CheckOnly` nastavuje **exit kód** (0/1/2) pro automatizaci
#### Hyper-V VM
### Kódování
- Virtuální stroje **Generation 1** (BIOS mode) nemají Secure Boot — kategorie `NO_SECUREBOOT_VM`, není co řešit.
- Virtuální stroje **Generation 2** mají virtualizovaný UEFI s Secure Boot, ale aktualizace certifikátů závisí na verzi hypervizoru.
- **Známý problém (Event 1795):** Na starších hostitelích selhávala aktualizace certifikátů ve VM s EventID 1795. Microsoft vydal opravu v březnu 2026 (KB5085790). Postup:
1. Ověřit verzi Windows Server na Hyper-V hostiteli
2. Aplikovat příslušné kumulativní aktualizace na hostitele
3. Spustit audit znovu na VM
#### VMware ESXi
- Secure Boot ve VMware VM závisí na konfiguraci VM hardware (EFI firmware + Secure Boot zaškrtnuto v nastavení VM).
- VMware **nepředává** nové certifikáty automaticky — aktualizace musí proběhnout přes Windows stejně jako na fyzickém stroji.
- Kategorie `NO_SECUREBOOT_VM` u VMware VM = VM nemá Secure Boot vůbec povoleno.
#### Fyzické servery s Legacy BIOS
- Kategorie `NO_SECUREBOOT` — Secure Boot není podporováno. Firmware je třeba překonfigurovat (boot mode UEFI) nebo server dokumentovat jako výjimku.
#### Starší firmware
- Servery s firmwarem z doby před cca 2018 mohou vyžadovat update firmware od výrobce (Dell, HP, Lenovo, Supermicro) před tím, než lze nové certifikáty aplikovat.
- Poznávacím znamením je `WindowsUEFICA2023Capable = 0` nebo hodnota `UEFICA2023Error`.
- Servery end-of-life bez dostupného firmware update je nutné dokumentovat jako trvalou výjimku.
Skript je uložen jako **UTF-8 s BOM** a na startu vynutí UTF-8 výstup konzole, aby čeština i symboly (`✓`) fungovaly i ve Windows PowerShell 5.1. Symboly checklistu jsou na jednom místě nahoře ve skriptu (`$SYM_DONE` …), kdyby je bylo potřeba změnit.
---
## 3. Remediace — odstranění problému
## 4. Zdroje
### Skript
### Microsoft — oficiální dokumentace
```
Set-SecureBootCertificateUpdate.ps1
```
Metoda: Registry key dle **KB5068202** — nastaví `AvailableUpdates = 0x5944`, čímž Windows signalizuje, že má aplikovat kompletní sadu nových certifikátů (KEK + UEFI CA + Windows UEFI CA + Boot Manager).
### Doporučený postup rollout (staging)
**Fáze 1 — Pilotní test (1–2 servery každého typu)**
```powershell
# Nejdřív WhatIf — ověřit co se stane bez provedení změn
.\Set-SecureBootCertificateUpdate.ps1 -ServerName PILOT-SERVER01 -WhatIf
# Aplikovat na pilotní server
.\Set-SecureBootCertificateUpdate.ps1 -ServerName PILOT-SERVER01
# Restartovat pilotní server
Restart-Computer -ComputerName PILOT-SERVER01 -Force
```
**Fáze 2 — Ověření pilotu (po restartu)**
```powershell
# Zkontrolovat EventID 1808 (úspěch) nebo 1801 (chyba)
Invoke-Command -ComputerName PILOT-SERVER01 -ScriptBlock {
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=@(1801,1808) } -MaxEvents 5 |
Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List
}
# Spustit plný audit pro ověření kategorie OK
Invoke-Command -ComputerName PILOT-SERVER01 -FilePath .\Invoke-SecureBootAudit.ps1 -ArgumentList $null, $false, $true
```
**Fáze 3 — Rozšíření na další servery**
```powershell
# Hromadně ze CSV (sloupec ServerName)
.\Set-SecureBootCertificateUpdate.ps1 -ServerName (Import-Csv .\servery-wave1.csv).ServerName
# Po restartech ověřit hromadně
.\Start-SecureBootFleetAudit.ps1 -ServerListPath .\servery-wave1.csv -OutputPath .\audit_post\
```
### Co se děje po spuštění skriptu
1. Skript nastaví `AvailableUpdates = 0x5944` v registry a resetuje `HighConfidenceOptOut = 0`
2. Spustí scheduled task `\Microsoft\Windows\PI\Secure-Boot-Update` (pokud existuje; jinak se task spustí sám do 12 hodin)
3. Task zpracuje registry a připraví certifikáty — status přejde z `NotStarted` → `InProgress` → `Success`
4. **Certifikáty se aplikují až při příštím restartu** — Boot Manager zapíše nové certifikáty do UEFI firmware
5. Po restartu se v System logu objeví EventID **1808** (úspěch) nebo **1801** (chyba)
### Dopad na server
| Aspekt | Detail |
| Téma | Odkaz |
|---|---|
| **Dostupnost** | Žádný výpadek při nastavení registry. Restart je standardní plánovaný restart. |
| **Riziko selhání bootu** | **Minimální** — neúspěšná aktualizace certifikátů neohrozí boot. Server nastartuje i se starými certifikáty. |
| **Počet restartů** | Obvykle 1 restart. Ve výjimečných případech může být vyžadován druhý. |
| **Čas po restartu** | Certifikáty jsou aplikovány v rané fázi bootu — uživatelé to nepocítí. |
| **BitLocker** | Pokud je BitLocker aktivní s PCR7 (Secure Boot measurement), ověřit recovery key před restartem. |
| **Monitoring** | Po restartu čekat min. 48 hodin než prohlásíme server za stabilní. |
| Přehled: expirace certifikátů a CA aktualizace (KB5062710) | [support.microsoft.com](https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e) |
| Guidance for IT Professionals and Organizations | [support.microsoft.com](https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f) |
| Registry key updates for Secure Boot (IT-managed) | [support.microsoft.com](https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d) |
| Secure Boot DB and DBX variable update events | [support.microsoft.com](https://support.microsoft.com/en-us/topic/secure-boot-db-and-dbx-variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69) |
| IT Pro guidance (KB5062713) | [support.microsoft.com](https://support.microsoft.com/en-us/help/5062713) |
| Registry key metoda (KB5068202) | [support.microsoft.com](https://support.microsoft.com/en-us/help/5068202) |
| GPO metoda (KB5068198) | [support.microsoft.com](https://support.microsoft.com/en-us/help/5068198) |
| WinCS API (KB5068197) | [support.microsoft.com](https://support.microsoft.com/en-us/help/5068197) |
| Troubleshooting (KB5085046) | [support.microsoft.com](https://support.microsoft.com/en-us/help/5085046) |
| Known issues a resolutions, vč. Hyper-V fix (KB5085790) | [support.microsoft.com](https://support.microsoft.com/en-us/help/5085790) |
| Minimální build 14. 10. 2025 (KB5066835) | [support.microsoft.com](https://support.microsoft.com/en-us/topic/october-14-2025-kb5066835-os-builds-26200-6899-and-26100-6899-1db237d8-9f3b-4218-9515-3e0a32729685) |
| Windows Server Secure Boot playbook (2026) | [techcommunity.microsoft.com](https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/windows-server-secure-boot-playbook-for-certificates-expiring-in-2026/4495789) |
> **Doporučení pro BitLocker:** Před restartem na serverech s BitLockerem ověřit dostupnost recovery key: `manage-bde -protectors -get C:`
### Komunitní projekty (inspirace pro logiku a přehled)
### Ověření úspěchu
**1. Event log — primární ověření:**
```powershell
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=1808 } -MaxEvents 3 |
Select-Object TimeCreated, Message
```
EventID **1808** potvrzuje úspěšnou aplikaci certifikátů.
**2. Audit skript — kompletní ověření:**
```powershell
.\Invoke-SecureBootAudit.ps1
# Očekávaný výstup: kategorie "✅ OK" nebo "✅ OK_TRANSITION"
```
**3. Ruční kontrola přítomnosti certifikátů:**
```powershell
# KEK databáze — hledat 2023 certifikáty
$kek = Get-SecureBootUEFI KEK
# DB databáze
$db = Get-SecureBootUEFI db
```
**4. Registry stav:**
```powershell
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' |
Select-Object UEFICA2023Status, UEFICA2023Error, WindowsUEFICA2023Capable
# UEFICA2023Status = 2 znamená Success
```
### Troubleshooting časté chyby
**Event 1801 — high-confidence update selhal:**
```powershell
# Zkontrolovat UEFICA2023Error
(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing').UEFICA2023Error
# Zkusit znovu s -Force
.\Set-SecureBootCertificateUpdate.ps1 -ServerName <server> -Force
```
**Event 1795 — Hyper-V VM selhání:**
- Zkontrolovat verzi Windows Server hostitele a aplikovat kumulativní update (KB5085790)
- Po aktualizaci hostitele spustit remediaci na VM znovu
**WindowsUEFICA2023Capable = 0 — firmware nepodporuje:**
- Zkontrolovat dostupnost firmware update u výrobce serveru
- Dell: Dell Update Package / iDRAC
- HP: HP Service Pack for ProLiant (SPP)
- Lenovo: Lenovo XClarity
- Supermicro: BIOS update přes IPMI
- Pokud firmware update není dostupný → dokumentovat jako trvalou výjimku
**HighConfidenceOptOut = 1 — server se odhlásil:**
```powershell
# Resetovat OptOut
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' `
-Name HighConfidenceOptOut -Value 0 -Type DWord
# Pak spustit remediaci znovu
```
| Projekt | Odkaz |
|---|---|
| CheckCA2023 (claude-boucher) — GUI monitor, podrobná registry/bit reference | [github.com/claude-boucher/CheckCA2023](https://github.com/claude-boucher/CheckCA2023) |
| SecureBoot-CA2023-Automatic-Update (mathisokle) — automatizace přes restarty | [github.com/mathisokle/SecureBoot-CA2023-Automatic-Update](https://github.com/mathisokle/SecureBoot-CA2023-Automatic-Update) |
---
## Reference
| KB | Popis |
|---|---|
| [KB5062710](https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e) | Přehled: expirace certifikátů a CA aktualizace |
| [KB5062713](https://support.microsoft.com/en-us/help/5062713) | IT Pro guidance |
| [KB5068202](https://support.microsoft.com/en-us/help/5068202) | Metoda registry klíčů (použita v tomto projektu) |
| [KB5068198](https://support.microsoft.com/en-us/help/5068198) | Metoda Group Policy |
| [KB5068197](https://support.microsoft.com/en-us/help/5068197) | Metoda WinCS CLI |
| [KB5085046](https://support.microsoft.com/en-us/help/5085046) | Troubleshooting guide |
| [KB5085790](https://support.microsoft.com/en-us/help/5085790) | Known issues a resolutions (vč. Hyper-V fix) |
*Skript záměrně NErestartuje server. Implementuje metodu registry klíčů (KB5068202); metody GPO / Intune / WinCS nepokrývá.*