# Projekt: Audit a remediace Secure Boot certifikátů na Windows Serverech

## Kontext a popis problematiky

### Co se děje

Microsoft vydal v červnu 2025 upozornění (KB5062710), že původní Secure Boot certifikáty z roku 2011 expirují v průběhu roku 2026. Jde o certifikáty uložené v UEFI firmware (KEK a DB databázích), které zajišťují důvěryhodnost boot procesu.

**Expirující certifikáty a termíny:**

| Certifikát | Expirace | Náhrada |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | **24. června 2026** | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | **27. června 2026** | Microsoft UEFI CA 2023 + Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | 19. října 2026 | Windows UEFI CA 2023 |

### Dopad na servery

Servery, které neobdrží nové 2023 certifikáty, budou dál fungovat a bootovat normálně, ale **přestanou být schopné přijímat nové bezpečnostní ochrany boot procesu** — včetně aktualizací Windows Boot Manageru, Secure Boot databází, revokačních seznamů a mitigací nově objevených boot-level zranitelností. Postupem času to omezí ochranu před hrozbami a může ovlivnit scénáře závislé na Secure Boot důvěře, jako je BitLocker hardening nebo third-party bootloadery.

### Specifika prostředí (MSP kontext)

- Windows Server 2016, 2019, 2022, 2025
- Fyzické servery různých výrobců (Dell, HP, Lenovo, Supermicro, ...)
- Virtuální stroje na **Hyper-V** (na Windows Server hostiteli)
- Virtuální stroje na **VMware ESXi**
- Prostředí spravovaná přes AD/GPO, bez Intune
- ~100–150 klientských prostředí různé velikosti

### Klíčové technické detaily

**Registry klíče relevantní pro stav:**
- `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot` — hlavní klíč (SecureBootEnabled, AvailableUpdates, HighConfidenceOptOut)
- `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing` — stav aktualizace (UEFICA2023Status, UEFICA2023Error, WindowsUEFICA2023Capable)
- `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes` — atributy zařízení

**Relevantní Event IDs (System log):**
- **1801** — chybová událost, certifikáty NEBYLY aplikovány
- **1808** — informační událost, certifikáty BYLY úspěšně aplikovány
- **1795** — selhání aktualizace (známý problém zejména u Hyper-V VM)
- **1796**, **1800**, **1802**, **1803** — doplňkové události průběhu

**PowerShell cmdlet pro základní check:**
```powershell
Confirm-SecureBootUEFI
```
Vrací `True` (Secure Boot zapnutý), `False`, nebo exception pokud UEFI Secure Boot není podporován.

**Hyper-V specifikum:** U VM běžících na Hyper-V může selhávat aktualizace certifikátů s Event ID 1795. Tento known issue byl Microsoft řešen (resolved March 30, 2026) — ověřit verzi Hyper-V hostitele a aplikovat příslušné opravy.

**VMware ESXi specifikum:** Záleží, zda VM má Secure Boot vůbec povolený (nastavení VM hardware). U Generation 1 ekvivalentu (BIOS mode) Secure Boot neexistuje.

---

## Cíl projektu

### Fáze 1 — Detekce (inventář)

Vytvořit PowerShell detekční skript, který lze spustit vzdáleně přes `Invoke-Command` nebo lokálně na každém serveru a vrátit strukturovaný přehled stavu.

**Výstup skriptu musí obsahovat:**

1. Základní identifikace serveru (hostname, OS verze, architektura)
2. Typ prostředí (fyzický / Hyper-V VM / VMware VM / jiné)
3. Je Secure Boot podporováno? (UEFI vs. Legacy BIOS)
4. Je Secure Boot povoleno?
5. Aktuální stav certifikátů:
   - Jsou přítomny expirující 2011 certifikáty? (KEK CA 2011, UEFI CA 2011, Windows PCA 2011)
   - Jsou přítomny nové 2023 certifikáty?
   - Stav z registry (`UEFICA2023Status`)
6. Confidence level (z event logu 1801/1808)
7. Poslední relevantní Event ID a čas
8. Hardware info (výrobce, model, firmware verze, datum firmware)
9. Dostupné aktualizace (`AvailableUpdates` registry hodnota)
10. Případné chyby (`UEFICA2023Error`)

**Formát výstupu:** JSON (pro snadné zpracování a agregaci) + human-readable summary

**Požadavky na skript:**
- Běží bez instalace dalších modulů (pure PowerShell 5.1+)
- Tolerantní vůči chybám — pokud Secure Boot není podporován/povolen, nezhavaruje
- Rozlišuje fyzický vs. VM (Hyper-V / VMware) přes WMI
- Exportuje výsledek lokálně i umožní vzdálené volání
- Wrapper skript pro hromadné spuštění přes seznam serverů z CSV/textového souboru

### Fáze 2 — Analýza a kategorizace

Na základě dat z detekce kategorizovat každý server do skupin:

| Kategorie | Popis | Doporučená akce |
|---|---|---|
| **✅ OK** | Má nové 2023 certifikáty, Secure Boot aktivní | Žádná akce |
| **⚠️ Nutná aktualizace** | Má staré 2011 certifikáty, Secure Boot aktivní, firmware OK | Naplánovat rollout |
| **🔧 Čeká na firmware** | Secure Boot aktivní, ale firmware nepodporuje update | Kontaktovat OEM / update firmware |
| **⏸️ Secure Boot vypnuto** | Secure Boot existuje ale není zapnuto | Rozhodnutí o enablementu |
| **❌ Secure Boot nepodporováno** | Legacy BIOS nebo VM bez vTPM | Dokumentovat jako výjimku |
| **🔴 Selhání aktualizace** | Event 1795/chyba v registry | Troubleshooting |

### Fáze 3 — Remediace

Navrhnout a implementovat remediační postup pro prostředí bez Intune:

**Metody rollout (zvážit dle prostředí klienta):**

1. **Registry key metoda** — přímé nastavení klíčů přes PowerShell/GPO (KB5068202)
2. **GPO metoda** — Group Policy Objects pro nastavení (KB5068198)
3. **WinCS CLI** — Windows Configuration System nástroj pro domain-joined stroje (KB5068197)
4. **Ruční / skriptovaný rollout** — pro izolovaná prostředí

**Postup rollout (staging):**
1. Test na 1–2 reprezentativních serverech každého typu (výrobce + firmware verze)
2. Ověření úspěchu přes Event ID 1808 a registry
3. Rozšíření na další skupinu
4. Monitoring (min. 48 hodin po aplikaci, čekat na restart)

**Remediační PowerShell** musí umět:
- Nastavit registry klíče pro zahájení aktualizace
- Spustit/zkontrolovat scheduled task pro Secure Boot update
- Ověřit výsledek po restartu

---

## Technické požadavky na kód

### Detekční skript

```
Soubor: Invoke-SecureBootAudit.ps1
```

**Logika detekce certifikátů** — kontrolovat přítomnost certifikátů přes `Get-SecureBootUEFI`:
- KEK databáze: hledat thumbprinty/subject odpovídající 2011 a 2023 certifikátům
- DB databáze: hledat Windows Production PCA 2011 / UEFI CA 2011 / jejich 2023 náhrady

**Detekce typu prostředí:**
```powershell
# Hyper-V VM
(Get-WmiObject Win32_ComputerSystem).Model -eq "Virtual Machine" -and 
(Get-WmiObject Win32_ComputerSystem).Manufacturer -like "*Microsoft*"

# VMware VM
(Get-WmiObject Win32_ComputerSystem).Manufacturer -like "*VMware*"
```

**Ošetřit výjimky:**
- `Get-SecureBootUEFI` hodí exception pokud Secure Boot není podporováno nebo povoleno — zachytit a zalogovat
- Na Legacy BIOS strojích `Confirm-SecureBootUEFI` vrátí exception nebo False

### Wrapper pro hromadné spuštění

```
Soubor: Start-SecureBootFleetAudit.ps1
```

- Vstup: seznam serverů (parametr nebo CSV soubor s kolonkou `ServerName`)
- Výstup: agregovaný JSON + CSV soubor pro import do Excelu
- Paralelizace: `Invoke-Command` s `-ThrottleLimit` (doporučeno max 20 paralelně)
- Logování: výpis chyb nedostupných serverů do separátního souboru

### Remediační skript

```
Soubor: Set-SecureBootCertificateUpdate.ps1
```

- Parametry: `-ServerName`, `-WhatIf`, `-Force`
- WhatIf mode pro ověření před spuštěním
- Nastavit příslušné registry klíče dle KB5068202
- Spustit nebo počkat na scheduled task
- Zalogovat výsledek

---

## Omezení a rizika

### Hyper-V VM
- Aktualizace Secure Boot certifikátů ve VM závisí na tom, zda **hypervizor poskytuje virtualizovaný UEFI** podporující aktualizace
- Generation 1 VM (BIOS) — Secure Boot nepodporují vůbec
- Generation 2 VM — mají virtualizovaný UEFI, ale aktualizace certifikátů závisí na verzi hypervizoru
- Known issue s Event 1795 byl opraven (březen 2026) — ověřit verzi Windows Server hostitele

### VMware ESXi
- Secure Boot ve VMware VM závisí na konfiguraci VM (EFI firmware + Secure Boot v nastavení VM)
- VMware neposkytuje automatické předání nových certifikátů do VM — aktualizace musí proběhnout přes Windows jako na fyzickém stroji
- Na starších ESXi verzích může být virtualizovaný UEFI omezený

### Fyzické servery
- Starší servery (zejména pre-2018) mohou vyžadovat firmware update od OEM před aplikací nových Secure Boot certifikátů
- Servery end-of-life od výrobce mohou nemít dostupný firmware update — dokumentovat jako výjimku

### Obecná rizika
- Neúspěšná aktualizace certifikátů **NEOHROZÍ boot serveru** — server bude dál fungovat se starými certifikáty
- Aktualizace vyžaduje restart pro aplikaci Boot Manageru (ne jen certifikátů)
- Po aplikaci počítat s min. 48 hodinami a jedním nebo více restarty

---

## Reference dokumentace

- KB5062710 — [Přehled: Windows Secure Boot certificate expiration and CA updates](https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e)
- KB5062713 — [IT Pro guidance](https://support.microsoft.com/en-us/help/5062713)
- KB5068202 — [Registry key updates](https://support.microsoft.com/en-us/help/5068202)
- KB5068198 — [GPO metoda](https://support.microsoft.com/en-us/help/5068198)
- KB5068197 — [WinCS APIs](https://support.microsoft.com/en-us/help/5068197)
- KB5085046 — [Troubleshooting](https://support.microsoft.com/en-us/help/5085046)
- KB5085790 — [Known issues and resolutions](https://support.microsoft.com/en-us/help/5085790)
- KB5086397 — [Azure Local / HyperConverged Infrastructure](https://support.microsoft.com/en-us/help/5086397)
- [Secure Boot DB and DBX variable update events](https://support.microsoft.com/topic/37e47cf8-608b-4a87-8175-bdead630eb69)

---

## Výstupy projektu (deliverables)

1. **`Invoke-SecureBootAudit.ps1`** — detekční skript pro jednotlivý server
2. **`Start-SecureBootFleetAudit.ps1`** — wrapper pro hromadný audit celé sítě
3. **`Set-SecureBootCertificateUpdate.ps1`** — remediační skript s WhatIf podporou
4. **`README.md`** — dokumentace použití všech skriptů
5. **Vzorový výstup** — příklad JSON a CSV výstupu auditu

---

## Priorita a časový rámec

**Urgentní** — první dvě expirace jsou **24. a 27. června 2026** (týden od dnešního data). Audit je nutné provést okamžitě, aby bylo jasné, na kolika serverech je nutná akce.

**Doporučené pořadí práce:**
1. Detekční skript (Fáze 1) — okamžitě
2. Hromadný wrapper + export do CSV — obratem po detekci
3. Analýza výsledků a kategorizace
4. Remediační skript — po otestování na pilotních serverech