Initial commit: detekční skript, remediační skript a README

- Invoke-SecureBootAudit.ps1: audit Secure Boot certifikátů (Fáze 1)
  - detekce prostředí (Physical/Hyper-V VM/VMware VM)
  - parsování EFI_SIGNATURE_LIST, detekce 2011/2023 certifikátů
  - registry stav, Event Log analýza, kategorizace, JSON výstup

- Set-SecureBootCertificateUpdate.ps1: remediace dle KB5068202
  - AvailableUpdates = 0x5944
  - scheduled task s wait smyčkou (timeout 120s)
  - WhatIf, Force, VerifyOnly, WinRM

- README.md: popis problému, detekce stavů, remediační postup
This commit is contained in:
Petr Stepan
2026-06-05 14:05:27 +00:00
commit 9a230866a2
5 changed files with 1714 additions and 0 deletions
+310
View File
@@ -0,0 +1,310 @@
# Secure Boot Certificate Remediation
Sada PowerShell skriptů pro audit a remediari expirujících Secure Boot certifikátů na Windows Serverech (fyzické servery, Hyper-V VM, VMware VM).
---
## 1. Co řešíme
### Problém
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 |
|---|---|---|---|
| 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 |
> **Urgentní:** První dvě expirace jsou 24. a 27. června 2026 — audit je nutné provést okamžitě.
### 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.
---
## 2. Detekce — jak zjistit aktuální stav
### Skripty
| Skript | Úč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 |
### Spuštění auditu
**Lokálně na serveru** (spustit jako Administrator):
```powershell
.\Invoke-SecureBootAudit.ps1
```
**Vzdáleně z workstation:**
```powershell
Invoke-Command -ComputerName SERVER01 -FilePath .\Invoke-SecureBootAudit.ps1 -ArgumentList $null, $false, $true
```
**Hromadně ze seznamu serverů (CSV soubor se sloupcem `ServerName`):**
```powershell
.\Start-SecureBootFleetAudit.ps1 -ServerListPath .\servers.csv -OutputPath .\audit_results\
```
**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 |
|---|---|---|
| ✅ **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 |
### Registry hodnoty a jejich výklad
Klíč `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing`:
| Hodnota | Typ | Výklad |
|---|---|---|
| `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í |
Klíč `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot`:
| 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** |
### EventID v System logu
| 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á |
Rychlé ověření z PowerShell:
```powershell
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = @(1795,1801,1808) } -MaxEvents 10 |
Select-Object TimeCreated, Id, Message | Format-List
```
### Specifika prostředí
#### Hyper-V VM
- 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.
---
## 3. Remediace — odstranění problému
### Skript
```
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 (12 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 |
|---|---|
| **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í. |
> **Doporučení pro BitLocker:** Před restartem na serverech s BitLockerem ověřit dostupnost recovery key: `manage-bde -protectors -get C:`
### 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
```
---
## 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) |