Certyfikaty Secure Boot wygasły – co z komputerami firmy?

Czym jest Secure Boot i dlaczego certyfikaty mają znaczenie

Secure Boot to mechanizm firmware UEFI. Pilnuje, żeby podczas startu komputera uruchomił się tylko podpisany, zaufany kod: bootloader Windows, shim dystrybucji Linux czy sterowniki kart rozszerzeń. Działa to podobnie jak certyfikaty SSL na stronach WWW. W pamięci płyty głównej zapisane są klucze i certyfikaty, a firmware porównuje z nimi podpis każdego elementu procesu rozruchu.

Od czasów Windows 8 prawie wszystkie komputery i serwery z certyfikacją Microsoftu mają w firmware ten sam zestaw certyfikatów z 2011 roku:

• Microsoft Corporation KEK CA 2011 – klucz, którym podpisuje się zmiany w bazach zaufanych i zablokowanych podpisów (DB i DBX),
• Microsoft Windows Production PCA 2011 – podpisuje menedżera rozruchu Windows,
• Microsoft UEFI CA 2011 – podpisuje oprogramowanie firm trzecich, w tym shim Linuksa i część firmware kart rozszerzeń (Option ROM).

Certyfikaty z 2011 roku wygasały kolejno od czerwca do października 2026 roku. Microsoft wydał już ich następców z rocznikiem 2023. Żeby jednak trafiły do konkretnego urządzenia, trzeba zaktualizować system i często także firmware.

Co faktycznie się dzieje po wygaśnięciu

Najpierw uspokajamy: komputery nie przestały się uruchamiać. Firmware UEFI nie sprawdza dat ważności certyfikatów przy starcie, więc kod podpisany wcześniej nadal działa. Dlatego temat przeszedł w wielu firmach bez echa.

Skutki są jednak realne i będą się nasilać:

• Brak nowych poprawek rozruchu – Microsoft nie może już podpisywać nowych wersji menedżera rozruchu starym certyfikatem. Urządzenie bez certyfikatu Windows UEFI CA 2023 nie dostanie przyszłych łatek dla tego etapu startu systemu.
• Brak aktualizacji listy DBX – DBX to czarna lista podatnych bootloaderów. Bez nowego klucza KEK nie da się jej aktualizować, więc znane bootkity, na przykład BlackLotus (CVE-2023-24932), mogą działać dalej.
• Problemy z nowymi nośnikami – nowe obrazy instalacyjne Windows i dystrybucji Linux będą podpisywane wyłącznie nowymi certyfikatami. Komputer, który zna tylko certyfikaty z 2011 roku, może odmówić uruchomienia takiego nośnika.
• Karty rozszerzeń – nowe wersje firmware kart graficznych, RAID czy sieciowych podpisane nowym certyfikatem mogą nie zostać załadowane na starszej płycie głównej.

Krótko mówiąc, sprzęt działa, ale z każdym miesiącem coraz bardziej odstaje od reszty ekosystemu bezpieczeństwa.

Których urządzeń w firmie to dotyczy

Problem dotyczy praktycznie każdego urządzenia z UEFI i włączonym Secure Boot, które powstało przed 2024 rokiem. Najwięcej pracy wymagają:

• Starsze laptopy i stacje robocze – zwłaszcza modele, dla których producent nie wydaje już aktualizacji BIOS/UEFI,
• Serwery fizyczne – aktualizacja kluczy KEK wymaga często firmware od producenta (Dell, HPE, Lenovo, Fujitsu), a każdy restart trzeba zaplanować,
• Maszyny wirtualne generacji 2 w Hyper-V oraz maszyny z UEFI w VMware i Proxmox – wirtualne firmware też przechowuje certyfikaty i też wymaga aktualizacji, czasem po stronie samego hypervisora,
• Serwery i komputery z Linuksem – shim podpisany starym certyfikatem UEFI CA 2011 nadal się uruchomi, ale nowsze wersje będą wymagały certyfikatu z 2023 roku,
• Urządzenia specjalistyczne – terminale, komputery przemysłowe i kioski z Windows IoT, o których często nikt nie pamięta.

Uwaga na koszty: dla sprzętu, którego producent porzucił i nie da się go zaktualizować, warto już teraz uwzględnić wymianę w budżecie. Podobnie jak przy końcu wsparcia Windows 10, wcześniejsze planowanie oszczędza nerwów i pieniędzy.

Jak sprawdzić, czy komputery mają nowe certyfikaty

Microsoft od 2025 roku stopniowo rozsyła nowe certyfikaty przez Windows Update. Na wielu nowszych komputerach z aktualnym systemem stało się to automatycznie. Mimo to nie warto zakładać, że wszystko poszło dobrze. Proponujemy taki plan weryfikacji:

1. Inwentaryzacja – sporządź listę wszystkich komputerów, serwerów i maszyn wirtualnych z informacją, czy Secure Boot jest włączony. W Windows sprawdzisz to w narzędziu msinfo32 albo poleceniem PowerShell Confirm-SecureBootUEFI.
2. Sprawdzenie bazy DB – za pomocą PowerShell (Get-SecureBootUEFI db) sprawdź, czy w bazie zaufanych certyfikatów jest już Windows UEFI CA 2023. W środowiskach z Intune lub Configuration Managerem da się to zrobić zbiorczo skryptem albo raportem.
3. Dziennik zdarzeń – Windows zapisuje w dzienniku systemowym zdarzenia o udanej lub nieudanej aktualizacji zmiennych Secure Boot. Błędy w tym miejscu zwykle wskazują na firmware, który trzeba zaktualizować.
4. Strony producentów sprzętu – Dell, HP, Lenovo i producenci serwerów publikują listy modeli z informacją, które wersje BIOS/UEFI zawierają nowe klucze KEK.
5. Hypervisory – sprawdź zalecenia producenta platformy wirtualizacyjnej dotyczące aktualizacji szablonów i istniejących maszyn wirtualnych.

W niewielkim środowisku (kilkanaście komputerów) zajmie to kilka godzin. Przy większej flocie albo mieszance starszego i nowszego sprzętu warto zlecić to serwisowi, który przy okazji zdiagnozuje i zaktualizuje firmware komputerów albo wskaże modele do wymiany.

Pułapki przy aktualizacji – BitLocker i stare nośniki

Aktualizacja certyfikatów i firmware ingeruje w proces rozruchu, więc może mieć efekty uboczne. Najczęstsze z nich to:

• Ekran odzyskiwania BitLocker – zmiana zmiennych UEFI lub aktualizacja BIOS może sprawić, że układ TPM nie odblokuje dysku automatycznie. Zanim zaczniesz, upewnij się, że klucze odzyskiwania są zapisane w Entra ID, Active Directory albo innym bezpiecznym miejscu. Szczegóły opisaliśmy w artykule o szyfrowaniu dysków BitLocker w firmie. Na czas aktualizacji firmware możesz też tymczasowo zawiesić ochronę BitLocker.
• Stare nośniki ratunkowe – po dodaniu starych bootloaderów do DBX nośniki USB i obrazy PXE przygotowane kilka lat temu mogą przestać się uruchamiać. Odśwież nośniki instalacyjne, środowiska WinPE i obrazy narzędzi do backupu bare-metal.
• Dual boot i Linux – na maszynach z Linuksem zaktualizuj najpierw pakiety shim i bootloadera, a dopiero potem DBX. Odwrotna kolejność może zablokować start systemu.
• Kolejność kroków – testuj zmiany najpierw na jednym lub dwóch komputerach z każdej grupy modeli, dopiero później wdrażaj je na całej flocie.

Na serwerach dochodzi jeszcze okno serwisowe i backup przed zmianą. Jeśli Twoje serwery nie mają stałej opieki, rozważ profesjonalne utrzymanie serwerów. Aktualizacje firmware, testy po restarcie i dokumentacja zmian będą wtedy robione regularnie, a nie tylko wtedy, gdy coś się zepsuje.

Wnioski dla małych i średnich firm

Wygaśnięcie certyfikatów Secure Boot to nie awaria, która z dnia na dzień wyłączy firmę. Trudno jednak traktować je jako temat do odłożenia. To cicha zmiana, która z czasem odcina starszy sprzęt od kolejnych zabezpieczeń rozruchu. A ataki na ten etap, czyli bootkity, należą do najtrudniejszych do wykrycia, bo działają, zanim uruchomi się system i program antywirusowy.

Praktyczne podejście dla MŚP:

• dodaj stan certyfikatów Secure Boot do stałej listy kontrolnej, obok aktualizacji systemu i firmware (więcej o tym w artykule o zarządzaniu aktualizacjami w firmie),
• aktualizuj BIOS/UEFI tak samo regularnie jak Windows,
• urządzenia bez wsparcia producenta oznacz jako kandydatów do wymiany w najbliższym cyklu budżetowym,
• nie wyłączaj Secure Boot jako szybkiego obejścia problemów, bo to otwiera drogę bootkitom.

Firmy, które uporządkują ten temat teraz, unikną nerwowej sytuacji, gdy pilna poprawka bezpieczeństwa nie zainstaluje się na połowie komputerów albo reinstalacja serwera utknie na nośniku, którego firmware nie chce uruchomić.