ZAGON DELUJE, ZAŠČITA PA LAHKO OBSTANE

Microsoft Corporation KEK CA 2011 je potekel 24. junija 2026, Microsoft UEFI CA 2011 tri dni pozneje. Certifikat Microsoft Windows Production PCA 2011, s katerim so povezani podpisi zagonskih nalagalnikov Windows, poteče 19. oktobra. Ti trije datumi niso roki za izklop računalnikov, temveč del prehoda na nove podpisne certifikate iz leta 2023. [1]

Microsoft je še v varnostni posodobitvi KB5127648 z dne 13. oktobra navedel, da se uvajanje novih certifikatov nadaljuje. Za samodejno nameščanje uporablja tudi podatke o uspešnosti na primerljivih konfiguracijah strojne opreme. Naprave, ki novih certifikatov še niso prejele, lahko medtem zaženejo Windows in sprejemajo običajne sistemske posodobitve. Omejitev je drugje: brez ustreznega zaupanja ne bodo mogle sprejeti nekaterih novih zaščit zgodnje faze zagona, vključno s prihodnjimi spremembami zagonskega nalagalnika in zbirk preklicev. [2, 3]

Ta razlika je za upravljanje infrastrukture pomembnejša od samega datuma na certifikatu. Dva računalnika z enako različico Windows, uspešno nameščenimi mesečnimi popravki in omogočenim Secure Boot sta lahko v različnih stanjih: prvi že uporablja novo podpisno verigo, drugi pa se še vedno zanaša na stare certifikate. Običajna evidenca popravkov tega ne razkrije.

Zaupanje je zapisano pred operacijskim sistemom

Secure Boot deluje v strojni programski opremi UEFI, še preden nadzor prevzame Windows. Ob zagonu preverja digitalne podpise ustreznih komponent in jih primerja s pravili, shranjenimi v sami platformi. Preverjanje odloča o dovoljenosti komponente po veljavni politiki zaupanja, ne pa o tem, ali je podpisana programska oprema brez ranljivosti. [1, 4]

Ta politika ima več ravni. Ključ platforme PK je osnova za upravljanje zaupanja; ključi KEK dovoljujejo pooblaščene spremembe podatkovnih zbirk podpisov. Zbirka DB vsebuje dovoljene certifikate in podpise, DBX pa tiste, ki jim je zagon prepovedan. Dodati nov certifikat v DB in preklicati starega v DBX sta zato vsebinsko različni operaciji. Prva omogoči sprejemanje novega podpisnika, druga lahko ustavi že dolgo uporabljano komponento. [4]

Tudi trije iztekajoči se Microsoftovi certifikati nimajo enake naloge. Naslednik starega KEK je Microsoft Corporation KEK 2K CA 2023, namenjen nadaljnjemu pooblaščanju sprememb DB in DBX. Microsoft UEFI CA 2011 nadomeščata dva ločena certifikata: Microsoft UEFI CA 2023 za zagonske nalagalnike in aplikacije EFI drugih ponudnikov ter Microsoft Option ROM UEFI CA 2023 za ustrezne razširitvene komponente. Certifikat Microsoft Windows Production PCA 2011 pri podpisovanju upravljalnika zagona Windows nadomešča Windows UEFI CA 2023. [1]

Če je nova različica upravljalnika zagona podpisana z Windows UEFI CA 2023, mora naprava temu certifikatu zaupati, preden lahko varno zažene tako podpisano komponento. Posodobitev datotek Windows in sprememba pravil v UEFI sta dva povezana posega, ne ena sama namestitev v operacijskem sistemu. [1, 6]

Datum izteka ne izbriše starega podpisa

Datum izteka sam po sebi ne odstrani zaupanja: UEFI starega certifikata takrat samodejno ne izbriše iz DB in ga ne doda v DBX. Že podpisan zagonski nalagalnik se lahko še naprej zažene, če je njegov podpisnik še dovoljen in komponente ne blokira drug mehanizem preklica. Microsoft to izrecno pojasnjuje tudi vzdrževalcem distribucij Linux na primeru starejšega podpisanega nalagalnika shim. [4, 5]

Ko proizvajalec izda novo zagonsko komponento, podpisano samo z avtoriteto iz leta 2023, je UEFI, ki zaupa zgolj staremu podpisniku, ne more potrditi. Enako pomemben je KEK: brez ustreznega novega ključa nadaljnje Microsoftove spremembe zbirk zaupanja in preklicev morda ne bodo več izvedljive. Naprava lahko še vedno opravlja vsakodnevne naloge, vendar njen zaščitni mehanizem ne dohaja več naslednjih varnostnih popravkov. [2, 5]

Preklic je drugačen in neposrednejši ukrep. Zaradi ranljivosti CVE-2023-24932, povezane z zagonsko zlonamerno programsko opremo BlackLotus, je Microsoft pripravil postopek za dodajanje certifikata Microsoft Windows Production PCA 2011 v DBX. Ko je tak preklic uporabljen, zagonskih aplikacij s tem podpisom ni več dovoljeno izvajati. To lahko prizadene tudi stare namestitvene in obnovitvene medije, če uporabljajo ustrezno podpisane nalagalnike. Preklic ima svoje predpogoje in faze; ni samodejna posledica oktobrskega izteka certifikata. [7]

Posodobitev mora povezati UEFI in upravljalnik zagona

Microsoft za upravljane naprave dokumentira usklajen postopek. Windows v DB doda Windows UEFI CA 2023 in, kadar so potrebni, nova certifikata za komponente drugih ponudnikov. Nadaljuje s posodobitvijo KEK in z namestitvijo upravljalnika zagona, podpisanega z novo avtoriteto. Posamezni koraki se preverjajo, postopek pa se lahko raztegne čez več zagonov. Bistveni varnostni pogoj je, da UEFI zaupa novemu podpisniku, preden začne uporabljati njegov zagonski nalagalnik. [6]

Uvajanje usklajuje razporejeno opravilo Secure-Boot-Update, ki praviloma preverja stanje vsakih dvanajst ur, ob napaki lahko poskusi znova, določene spremembe pa zahtevajo še ponovni zagon. Zato ima lahko računalnik svežo mesečno posodobitev Windows, prehod Secure Boot pa ostaja nedokončan. Uspešno prenesen paket, uspešno zapisana spremenljivka UEFI in uporaba novega nalagalnika so ločljivi dogodki. [6, 9]

Pri tem ni dovolj poznavanje različice Windows. Za posodobitev KEK je potrebna ustrezna avtorizacija s ključem platforme, ki ga praviloma upravlja proizvajalec naprave. Če zahtevani paket, podpisan s PK, ni na voljo, se lahko ta del postopka ustavi, čeprav so bili drugi elementi zaupanja že dodani. Omejitev je lahko vezana na natančen model, sistemsko ploščo ali različico UEFI. Prav zato Microsoft priporoča preizkušanje na reprezentativnih konfiguracijah pred širšim uvajanjem. [6, 9]

Kaj je mogoče ugotoviti brez ugibanja

Ukaz Confirm-SecureBootUEFI na podprti napravi pokaže, ali je Secure Boot omogočen. Pozitiven rezultat ne potrdi prehoda na certifikate 2023. Bolj uporabna je registrska vrednost UEFICA2023Status pod HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing; vrednost Updated je indikator zaključenega postopka. Ob sumu na zastoj je treba preveriti še UEFICA2023Error, UEFICA2023ErrorEvent in stanje opravila, ki izvaja posodobitve. [6, 9]

Sistemski dnevnik Windows omogoča podrobnejši pregled: dogodek vira TPM-WMI s številko 1799 potrjuje uspešno namestitev upravljalnika zagona, podpisanega z Windows UEFI CA 2023. Dogodek 1808 ima širši pomen: zabeležen je, ko so v UEFI uporabljeni potrebni novi certifikati in je posodobljen tudi upravljalnik zagona. Razlika med obema je pomembna, ker posameznega uspešnega koraka ne smemo zamenjati za zaključeno celoto. [8]

Dogodek 1801 označuje še nedokončan prehod. Številka 1795 pomeni, da je strojna programska oprema pri spremembi varnostne spremenljivke vrnila napako. Dogodek 1802 je povezan z znano omejitvijo, zaradi katere je posodobitev zadržana, 1803 pa opozarja na manjkajoč ustrezen KEK, podpisan s ključem platforme. Starejši dogodek 1801 lahko ostane v dnevniku tudi po poznejšem uspehu. Pri inventarizaciji je zato potrebna časovna povezava dogodkov s trenutnimi registrskimi podatki, ne zgolj njihovo štetje. [8, 9]

S temi podatki je mogoče naprave razvrstiti brez sklepanja iz videza namizja ali datuma zadnje posodobitve Windows. Ena skupina ima prehod potrjen, druga ga še izvaja oziroma čaka na ponovni zagon, tretja pa ima dokumentirano oviro v strojni programski opremi ali manjkajoči avtorizaciji. Pri zadnji skupini je pomembno, ali obstaja podprta posodobitev proizvajalca ali bo naprava potrebovala obravnavo kot izjema. [6, 9]

Ko ponastavitev vrne stare ključe

Obstaja še drugače neprijetna možnost: naprava je prehod uspešno opravila, nato pa po servisnem posegu ne more več zagnati Windows. Microsoft opisuje primer, ko je upravljalnik zagona že podpisan z Windows UEFI CA 2023, nekdo pa v UEFI obnovi stare tovarniške ključe Secure Boot. Če te privzete vrednosti ne vsebujejo novega certifikata, naprava izgubi zaupanje, potrebno za preverjanje trenutno nameščenega nalagalnika. Rezultat je lahko zavrnjen zagon. [9]

Ponastavitev ni nujno problematična, saj proizvajalec z novejšo različico UEFI lahko posodobi tudi tovarniške vrednosti. Odločilno je, ali privzeta zbirka DB po ponastavitvi še vedno dopušča podpis dejansko nameščene komponente. Microsoft za opisani primer ponuja namenski obnovitveni postopek, obenem pa opozarja, da sama obnovitev zagona še ne pomeni, da so vsi certifikati pravilno ponovno nameščeni. [9]

Tudi obnovitveni ključ USB, slika Windows PE ali omrežni zagonski postopek PXE lahko uporablja starejši nalagalnik, ki po določenih preklicih ne bo več sprejet. Oktobrska posodobitev KB5127648 vsebuje še posebno opozorilo za posodabljanje namestitvenih slik z dinamičnimi posodobitvami: medij mora vključevati datoteko boot.stl, skladno z različico in arhitekturo Windows, sicer se z njega morda ne bo mogoče zagnati. Gre za ločena razloga za odpoved medija, ki ju je treba tudi ločeno preizkusiti. [3, 7]

Pri navideznih računalnikih Azure je pomembno razlikovati med referenčno sistemsko sliko (golden image) in virtualno strojno programsko opremo. Slika lahko vsebuje novejši upravljalnik zagona, zbirke Secure Boot pa so shranjene v virtualnem UEFI posameznega računalnika. Posodobitev slike teh vrednosti sama ne prenese na že obstoječe naprave. Microsoft posebej dokumentira tveganje pri ponovni uporabi slik na starejših navideznih računalnikih Azure Trusted Launch oziroma Confidential VM; ugotovitve ni mogoče brez preverjanja prenesti na vsak hipervizor. [10]

Poseg v zagonsko verigo lahko vpliva tudi na meritve, ki jih za zaščito zagona uporablja BitLocker. Microsoft med dokumentiranimi težavami navaja enkratno zahtevo po obnovitvenem ključu in ponavljajoče se zahteve, kadar je pred lokalnim zagonom nastavljen neustrezen poskus PXE. Pred spremembami je zato nujno zagotoviti dostop do obnovitvenih ključev in preveriti vrstni red zagona; takšnih težav ne smemo pripisati že samemu izteku certifikata. [9]

Merilo za zaključek prehoda

Pri upravljanju večjega števila naprav oznaka »posodobljeno« ne zadostuje; evidenca mora poleg modela, različice UEFI in stanja Secure Boot vsebovati še izid prehoda na nove certifikate, dokaz o uporabi ustrezno podpisanega upravljalnika zagona in razlog za morebitno zadržanje. Enako velja za strežnike, virtualne naprave in medije, ki se uporabijo šele ob obnovi. Pri slednjih je pomemben dejansko uspešen preizkus zagona, ne samo obstoj datoteke ISO v arhivu. [6, 9]

Ko je to znano, ima vsaka skupina naprav drugačno naslednje opravilo: pri uspešno posodobljenih se stanje zabeleži, pri nedokončanih preveri potek in pogoje za nadaljevanje, pri blokiranih pa podpora proizvajalca oziroma življenjska doba opreme. Zaključek prehoda torej ni dan izteka starega certifikata ali zelena oznaka pri Windows Update, temveč preverjena usklajenost certifikatov v UEFI, podpisa uporabljenega zagonskega nalagalnika in poti, po kateri bo mogoče sistem zagnati ter obnoviti tudi po naslednji varnostni spremembi.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZIztek certifikatov Secure Boot 2011 ne prekine samodejno zagona; pripravljenost za prihodnje zaščite zahteva preverljivo usklajeno zaupanje UEFI, podpise zagonskega nalagalnika in ustrezno obnovitveno pot.

RAZISKAVE0

DOKUMENTACIJA10

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-10-17

Viri

1. 01PRIMARY DOCUMENTATIONMicrosoft
   Microsoft. Windows Secure Boot certificate expiration and CA updates (KB5062710).Odpri vir ↗
2. 02PRIMARY DOCUMENTATIONMicrosoft
   Microsoft. When Secure Boot certificates expire on Windows devices (KB5079373).Odpri vir ↗
3. 03PRIMARY DOCUMENTATIONMicrosoft
   Microsoft. October 13, 2026—KB5127648.Odpri vir ↗
4. 04STANDARDUEFI Forum
   UEFI Forum. Unified Extensible Firmware Interface Specification, Version 2.11, poglavje 32: Secure Boot and Driver Signing.Odpri vir ↗
5. 05PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn. Secure Boot 2023 Certificate Transition Guidance for Linux Distributions.Odpri vir ↗
6. 06PRIMARY DOCUMENTATIONMicrosoft
   Microsoft. Secure Boot Certificate updates: Guidance for IT professionals and organizations (KB5062713).Odpri vir ↗
7. 07PRIMARY DOCUMENTATIONMicrosoft
   Microsoft. How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 (KB5025885).Odpri vir ↗
8. 08PRIMARY DOCUMENTATIONMicrosoft
   Microsoft. Secure Boot DB and DBX variable update events (KB5016061).Odpri vir ↗
9. 09PRIMARY DOCUMENTATIONMicrosoft
   Microsoft. Secure Boot troubleshooting guide (KB5085046).Odpri vir ↗
10. 10PRIMARY DOCUMENTATIONMicrosoft
    Microsoft. Secure Boot update from 2011 to 2023 certificates: Trusted Launch VMs and Confidential VMs (KB5085395).Odpri vir ↗