El Secure Boot va caducar al juny i no va caure res. Aquest és el problema

El 24 de juny i el 27 de juny van caducar dos certificats que des del 2011 sostenien l'arrencada segura de pràcticament tots els PC i servidors x86 del món. No va passar absolutament res. Ni un equip sense arrencar, ni un tiquet, ni una trucada. Per això, un mes i mig després, gairebé ningú no ho ha mirat. I la part incòmoda és que no passés res era exactament el previst: la fallada d'aquest canvi no es manifesta apagant màquines, sinó deixant de protegir les que continuen enceses.

Escrivim això des del costat de qui manté parcs aliens. Tenim equips Windows de clients, servidors Linux propis i màquines virtuals sobre Proxmox VE amb emmagatzematge Ceph, i les tres coses mengen del mateix arbre de confiança. I la pregunta no és teòrica: un portàtil acabat de lliurar pot arribar sense el certificat nou, perquè això ho decideix el firmware que li va posar el fabricant, no la data de la factura. Aquest article és el que hem ordenat per respondre-la en un parc sencer, amb les ordres exactes i amb la part que gairebé cap cobertura no esmenta: les plantilles de màquina virtual.

Tres certificats, tres dates, tres coses diferents

El primer que convé desfer és el titular. No caduca «el Secure Boot»: caduquen tres certificats concrets, cadascun amb la seva data i la seva funció, i confondre'ls és la raó per la qual molta gent ha arxivat l'assumpte com a resolt. Segons la mateixa documentació de Microsoft:

• Microsoft Corporation KEK CA 2011 — va caducar el 24 de juny del 2026. És el que signa les actualitzacions de les bases de dades DB i DBX. El substitueix Microsoft Corporation KEK 2K CA 2023.
• Microsoft UEFI CA 2011 — va caducar el 27 de juny del 2026. Signa carregadors d'arrencada de tercers i ROM opcionals; és a dir, l'arrencada de Linux i el firmware de moltes targetes. El substitueixen Microsoft UEFI CA 2023 i Microsoft Option ROM UEFI CA 2023.
• Microsoft Windows Production PCA 2011 — caduca el 19 d'octubre del 2026. És el que signa el carregador d'arrencada de Windows. El substitueix Windows UEFI CA 2023. Aquesta data encara no ha arribat: queden setanta-dos dies des que publiquem això.

El model mental correcte cap en una frase: un certificat caducat no invalida el que ja va signar. Tot el que estava signat continua validant i continua arrencant. El que s'acaba és la capacitat de signar coses noves. Si aquesta distinció et queda clara, la resta de l'article és aritmètica.

El que no passa, i per què és pitjor

Microsoft ho diu sense embuts, i cal citar-ho sencer perquè és la meitat tranquil·litzadora: si el teu dispositiu arriba a la data de caducitat sense els certificats nous, «continuarà iniciant-se i funcionant amb normalitat», i les actualitzacions de Windows es continuaran instal·lant. Ningú no es queda sense arrencar. Qui et vengui el pànic contrari t'està venent una altra cosa.

L'altra meitat és la que importa, i és de la mateixa pàgina: aquests dispositius «ja no podran rebre noves proteccions de seguretat per al procés d'arrencada primerenca, incloses actualitzacions de l'Administrador d'arrencada de Windows, de les bases de dades de Secure Boot, de les llistes de revocació o mitigacions per a vulnerabilitats de nivell d'arrencada acabades de descobrir». Traduït al que significa en un parc: el dia que aparegui el pròxim bootkit i Microsoft publiqui una revocació al DBX, aquestes màquines no la rebran. No perquè fallin, sinó perquè ja no hi ha qui signi l'enviament per a elles.

Aquí va la nostra opinió, i és incòmoda per al gremi: una caducitat que no trenca res és operativament pitjor que una que trenca alguna cosa. Si el 24 de juny no hagués arrencat un terç dels portàtils, el dijous 25 estaria resolt a tot Espanya. Com que no va caure res, no hi ha tiquet que obri la feina, no hi ha usuari que es queixi i —això és el que de debò costa admetre— no hi ha plantilla de monitoratge estàndard que vigili si el DB d'una màquina conté una cadena concreta. Nosaltres monitoritzem força i amb criteri, i això no hi era. És una comprovació que ara té sentit ficar a la plantilla.

És el mateix patró del qual escrivíem aquesta mateixa setmana arran de dues fallades del kernel: l'avís et diu que el problema existeix, no si la teva màquina concreta ja el té resolt. La diferència és que allà n'hi havia prou amb uname -r. Aquí cal anar a preguntar-ho al firmware.

Dos minuts en un Windows

A PowerShell amb privilegis d'administrador. Es llegeix la variable UEFI i s'hi busca el nom del certificat. Retorna True o False, sense ambigüitat:

Confirm-SecureBootUEFI

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Microsoft UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Microsoft Option ROM UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

La primera línia confirma que el Secure Boot està activat; si retorna False, les quatre següents sobren i tens una altra conversa pendent. Les altres quatre són les que compten: els quatre True són l'aprovat. Un False al KEK marca el futur, no el present: Microsoft aplica els certificats del DB abans que el KEK, i qui els autoritza és el KEK del 2011 que la màquina ja té, de manera que aquest equip encara pot rebre l'actualització. El que no podrà rebre són les següents: el KEK 2K CA 2023 l'ha d'autoritzar la Platform Key del fabricant, i aquí ja no decideix Microsoft sinó el teu proveïdor de maquinari.

Per veure-ho a escala, en comptes de màquina a màquina, l'estat viu al registre, a la subclau HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing: el valor UEFICA2023Status passa de NotStarted a InProgress i acaba a Updated, i si alguna cosa falla queda el codi a UEFICA2023Error. Compte amb la ruta, perquè no és la mateixa que la de l'apartat següent: els interruptors pengen de SecureBoot i l'estat, de SecureBoot\Servicing. Això és un inventari, i un inventari es pot recollir des de l'eina de gestió que ja tinguis sense trepitjar cap equip.

L'interruptor del parc gestionat (i com no fer-lo servir)

En equips gestionats per IT, el desplegament no va sol: cal demanar-lo. Microsoft documenta dos valors a HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot. AvailableUpdates a 0x5944 diu a Windows que executi l'actualització de claus i, a més, que posi el gestor d'arrencada signat amb el Windows UEFI CA 2023. MicrosoftUpdateManagedOptIn a 1 delega el desplegament a Microsoft; i no n'hi ha prou amb el valor, perquè Microsoft exigeix a més permetre l'enviament de dades de diagnòstic requerides: en un parc amb la telemetria bloquejada per directiva, l'interruptor no fa res. La tasca programada \Microsoft\Windows\PI\Secure-Boot-Update s'executa cada dotze hores i va netejant els bits de 0x5944 a mesura que els completa; iniciar el desplegament no provoca cap reinici, encara que pot caldre'n un per acabar.

I ara el consell que va contra la temptació: aquest valor no s'empeny a un parc sencer de cop. Estàs escrivint en variables UEFI de màquines de diversos fabricants, algunes amb firmware de fa anys. L'ordre que seguim és avorrit i funciona: primer mesurar, després firmware del fabricant als models que ho demanin, després un anell pilot per model de maquinari —no per departament, que aquí el que varia és la placa— i només llavors la resta. Un desplegament silenciós que no va trencar res al juny no es mereix que tu el converteixis en sorollós a l'agost.

Els teus servidors Linux mengen del mateix certificat

Aquest és el punt que cau de gairebé totes les cobertures, perquè s'han escrit des de l'escriptori. El shim —el petit carregador que permet arrencar Linux amb el Secure Boot activat— el signa Microsoft amb el Microsoft UEFI CA 2011, el que va caducar el 27 de juny. Una màquina amb el Secure Boot desactivat ni se n'assabenta. El que es complica és desplegar shims nous signats només amb la clau del 2011 en màquines que no puguin rebre actualitzacions de la base de dades UEFI.

Les distribucions es van avançar. Red Hat va publicar shims signats amb les dues claus, la del 2011 i la del 2023, de manera que arrenquen tant si la màquina té enrolada l'una com l'altra: shim-x64 16.1-4 a RHEL 10, 16.1-7 a RHEL 9 i 16.1-2 a RHEL 8. Per comprovar on ets, tres ordres:

mokutil --sb-state                          # el Secure Boot està activat?
mokutil --db | grep -A13 "\[key"            # quins certificats hi ha a la base de dades
pesign -S -i /boot/efi/EFI/redhat/shimx64.efi   # amb quines claus està signat el teu shim

I un advertiment que subscrivim paraula per paraula: Red Hat demana explícitament no forçar la instal·lació d'actualitzacions del db i seguir sempre la guia del fabricant. En equips HP i Fujitsu cal l'actualització completa de firmware abans de tocar la base de dades per separat; el camí suportat acostuma a ser fwupdmgr update, no una escriptura a mà. Ficar certificats a mà en una variable UEFI és exactament el tipus de drecera que surt bé noranta-nou vegades.

La que ningú no mira: les teves màquines virtuals

Una màquina virtual amb arrencada UEFI també té el seu DB i el seu KEK. No són en una placa: són en un fitxer, el disc EFI, que es va crear a partir d'una plantilla de l'hipervisor. I aquí apareix la diferència de fons amb el maquinari físic: una placa vella es queda enrere una vegada; una plantilla vella es queda enrere cada vegada que clones. La mateixa guia de Red Hat ho diu en una línia que gairebé ningú no ha citat: cal actualitzar el paquet edk2-ovmf als hipervisors perquè les màquines virtuals noves heretin els certificats actualitzats.

A Proxmox VE, que és el que operem cada dia, la plantilla de variables EFI per defecte inclou els certificats del 2023 a partir de pve-edk2-firmware 4.2025.05-1. Els discos EFI creats abans d'això porten només els del 2011, i no s'actualitzen sols. Proxmox VE 9.2, publicat el 21 de maig del 2026, va afegir una comprovació a cada arrencada d'una màquina virtual amb claus preenrolades, i l'avís és literal: WARN: EFI disk without 'ms-cert=2023k' option, suggesting that not all UEFI 2023 certificates from Microsoft are enrolled yet. Per arreglar una màquina existent, amb la màquina apagada:

qm enroll-efi-keys <vmid>

La documentació de Proxmox descriu l'ordre com «enrolar certificats actualitzats importants al disc EFI amb claus preenrolades —actualment, els certificats UEFI 2023 de Microsoft—» i adverteix que s'ha d'executar amb la màquina apagada. Aquí ve la part que només s'aprèn amb una cicatriu, i no és nostra sinó de Proxmox: el novembre del 2025 van intentar enrolar el certificat nou automàticament a la següent arrencada de les màquines Windows afectades (qemu-server 9.0.28). Van haver de fer marxa enrere perquè el canvi enviava les màquines virtuals amb Windows 11 a la pantalla de recuperació del BitLocker. Des de llavors l'operació és manual i explícita.

De manera que l'ordre en un entorn virtualitzat és aquest, i no un altre: tingues la clau de recuperació del BitLocker a mà abans d'executar res, desactiva temporalment els protectors amb manage-bde -protectors -disable C: —es tornen a activar sols al següent reinici— i només llavors enrola. I arregla la plantilla primer. Si comences per les màquines existents mentre la teva plantilla daurada continua parint discos EFI del 2011, estàs traient aigua amb la mànega oberta. Nosaltres mantenim plantilles d'aprovisionament Windows i Linux per a clients, i és el lloc per on cal començar.

Quan això no és el teu problema

Dos casos, i els diem perquè l'honestedat estalvia feina. El primer: si tens el Secure Boot desactivat, res d'això no t'afecta. No és una bona notícia —vol dir que fa anys que no tens la protecció de què va aquest article— però no tens cap urgència aquesta setmana. El segon és més incòmode: hi ha màquines que no rebran això mai. Microsoft indica que alguns sistemes necessiten actualitzacions de firmware del fabricant, i si aquest fabricant no publica mai una versió amb els certificats del 2023 per a un model del 2016, no hi ha pedaç que ho arregli. Això deixa de ser una conversa de manteniment i passa a ser-ne una de renovació, amb el seu pressupost i el seu calendari.

És el mateix forat del qual parlàvem en escriure sobre els BMC i les IPMI exposades: el firmware és la capa que ningú no té inventariada, ningú no té monitoritzada i ningú no té al contracte. I aquesta capa acaba d'estrenar una data de caducitat. Si a més tens Windows 10 al parc, no és l'únic compte enrere obert aquesta tardor: el peatge de l'ESU també venç a l'octubre, i convé que les dues decisions les prengui la mateixa persona el mateix dia, perquè la resposta pot ser la mateixa màquina.

El que faríem aquesta setmana

• Mesurar, no suposar. Les quatre línies de PowerShell sobre una mostra de cada model de maquinari, i el UEFICA2023Status recollit des de l'eina de gestió per a la resta. Sense aquesta xifra no hi ha conversa possible amb el client.
• Firmware del fabricant abans que res als models que ho demanin, seguint la seva guia i sense forçar escriptures a mà a les variables UEFI.
• Anell pilot per model de placa, no per departament. I llegir l'estat després, que per això hi és.
• Plantilles de màquina virtual primer, VM existents després, amb la clau de recuperació del BitLocker al davant i els protectors desactivats durant l'operació.

Res d'això no és difícil. És, un altre cop, feina que no es veu: inventari, finestra i algú que llegeixi la documentació del fabricant fins al final. És exactament el que fem quan ens encarreguem del lloc de treball d'una empresa i de l'operació del dia a dia, i és el tipus de tasca que només apareix a la factura del mes que no va passar res. Si vols que et diguem quants equips del teu parc ja tenen els certificats del 2023 —i quants no els tindran mai—, escriu-nos.

I la pregunta amb què tanquem, que és la mateixa que ens vam fer nosaltres: si demà es publica una revocació urgent per a un bootkit, quantes de les teves màquines la podrien rebre? No quantes estan actualitzades. Quantes poden estar-ho.