Secure Boot caducó en junio y no se cayó nada. Ese es el problema

El 24 de junio y el 27 de junio caducaron dos certificados que llevaban desde 2011 sosteniendo el arranque seguro de prácticamente todos los PC y servidores x86 del mundo. No pasó absolutamente nada. Ni un equipo sin arrancar, ni un ticket, ni una llamada. Por eso, mes y medio después, casi nadie lo ha mirado. Y la parte incómoda es que no pasara nada era exactamente lo previsto: el fallo de este cambio no se manifiesta apagando máquinas, sino dejando de proteger las que siguen encendidas.

Escribimos esto desde el lado del que mantiene parques ajenos. Tenemos equipos Windows de clientes, servidores Linux propios y máquinas virtuales sobre Proxmox VE con almacenamiento Ceph, y las tres cosas comen del mismo árbol de confianza. Y la pregunta no es teórica: un portátil recién entregado puede llegar sin el certificado nuevo, porque eso lo decide el firmware que le puso el fabricante, no la fecha de la factura. Este artículo es lo que hemos ordenado para responderla en un parque entero, con los comandos exactos y con la parte que casi ninguna cobertura menciona: las plantillas de máquina virtual.

Tres certificados, tres fechas, tres cosas distintas

Lo primero que conviene deshacer es el titular. No caduca «el Secure Boot»: caducan tres certificados concretos, cada uno con su fecha y su función, y confundirlos es la razón por la que mucha gente ha archivado el asunto como resuelto. Según la propia documentación de Microsoft:

• Microsoft Corporation KEK CA 2011 — caducó el 24 de junio de 2026. Es el que firma las actualizaciones de las bases de datos DB y DBX. Lo sustituye Microsoft Corporation KEK 2K CA 2023.
• Microsoft UEFI CA 2011 — caducó el 27 de junio de 2026. Firma cargadores de arranque de terceros y ROM opcionales; es decir, el arranque de Linux y el firmware de muchas tarjetas. Lo sustituyen Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023.
• Microsoft Windows Production PCA 2011 — caduca el 19 de octubre de 2026. Es el que firma el cargador de arranque de Windows. Lo sustituye Windows UEFI CA 2023. Esta fecha todavía no ha llegado: quedan setenta y dos días desde que publicamos esto.

El modelo mental correcto cabe en una frase: un certificado caducado no invalida lo que ya firmó. Todo lo que estaba firmado sigue validando y sigue arrancando. Lo que termina es la capacidad de firmar cosas nuevas. Si esa distinción se te queda clara, el resto del artículo es aritmética.

Lo que no pasa, y por qué es peor

Microsoft lo dice sin rodeos, y hay que citarlo entero porque es la mitad tranquilizadora: si tu dispositivo llega a la fecha de caducidad sin los certificados nuevos, «seguirá iniciándose y funcionando con normalidad», y las actualizaciones de Windows se seguirán instalando. Nadie se queda sin arrancar. Quien te venda el pánico contrario te está vendiendo otra cosa.

La otra mitad es la que importa, y es de la misma página: esos dispositivos «ya no podrán recibir nuevas protecciones de seguridad para el proceso de arranque temprano, incluidas actualizaciones del Administrador de arranque de Windows, de las bases de datos de Secure Boot, de las listas de revocación o mitigaciones para vulnerabilidades de nivel de arranque recién descubiertas». Traducido a lo que significa en un parque: el día que aparezca el próximo bootkit y Microsoft publique una revocación en el DBX, esas máquinas no la van a recibir. No porque fallen, sino porque ya no hay quien firme el envío para ellas.

Aquí va nuestra opinión, y es incómoda para el gremio: una caducidad que no rompe nada es operativamente peor que una que rompe algo. Si el 24 de junio no hubiera arrancado un tercio de los portátiles, el jueves 25 estaría resuelto en toda España. Como no se cayó nada, no hay ticket que abra el trabajo, no hay usuario que se queje y —esto es lo que de verdad cuesta admitir— no hay plantilla de monitorización estándar que vigile si el DB de una máquina contiene una cadena concreta. Nosotros monitorizamos bastante y con criterio, y esto no estaba. Es una comprobación que ahora tiene sentido meter en la plantilla.

Es el mismo patrón del que escribíamos esta misma semana a cuenta de dos fallos del kernel: el aviso te dice que el problema existe, no si tu máquina concreta ya lo tiene resuelto. La diferencia es que allí bastaba con uname -r. Aquí hay que ir a preguntarle al firmware.

Dos minutos en un Windows

En PowerShell con privilegios de administrador. Se lee la variable UEFI y se busca el nombre del certificado dentro. Devuelve True o False, sin ambigüedad:

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ínea confirma que Secure Boot está activado; si devuelve False, las cuatro siguientes sobran y tienes otra conversación pendiente. Las otras cuatro son las que cuentan: los cuatro True son el aprobado. Un False en el KEK marca el futuro, no el presente: Microsoft aplica los certificados del DB antes que el KEK, y quien los autoriza es el KEK de 2011 que la máquina ya tiene, así que ese equipo todavía puede recibir la actualización. Lo que no podrá recibir son las siguientes: el KEK 2K CA 2023 lo tiene que autorizar la Platform Key del fabricante, y ahí ya no decide Microsoft sino tu proveedor de hardware.

Para verlo a escala, en lugar de máquina a máquina, el estado vive en el registro, en la subclave HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing: el valor UEFICA2023Status pasa de NotStarted a InProgress y termina en Updated, y si algo falla queda el código en UEFICA2023Error. Ojo con la ruta, porque no es la misma que la del apartado siguiente: los interruptores cuelgan de SecureBoot y el estado, de SecureBoot\Servicing. Eso es un inventario, y un inventario se puede recoger desde la herramienta de gestión que ya tengas sin pisar ningún equipo.

El interruptor del parque gestionado (y cómo no usarlo)

En equipos gestionados por IT, el despliegue no va solo: hay que pedirlo. Microsoft documenta dos valores en HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot. AvailableUpdates a 0x5944 le dice a Windows que ejecute la actualización de claves y, además, que ponga el gestor de arranque firmado con el Windows UEFI CA 2023. MicrosoftUpdateManagedOptIn a 1 delega el despliegue en Microsoft; y no basta con el valor, porque Microsoft exige además permitir el envío de datos de diagnóstico requeridos: en un parque con la telemetría bloqueada por directiva, el interruptor no hace nada. La tarea programada \Microsoft\Windows\PI\Secure-Boot-Update se ejecuta cada doce horas y va limpiando los bits de 0x5944 según los completa; iniciar el despliegue no provoca reinicio, aunque puede hacer falta uno para terminar.

Y ahora el consejo que va contra la tentación: ese valor no se empuja a un parque entero de golpe. Estás escribiendo en variables UEFI de máquinas de varios fabricantes, algunas con firmware de hace años. El orden que seguimos es aburrido y funciona: primero medir, después firmware del fabricante en los modelos que lo pidan, después un anillo piloto por modelo de hardware —no por departamento, que aquí lo que varía es la placa— y solo entonces el resto. Un despliegue silencioso que no rompió nada en junio no merece que tú lo conviertas en ruidoso en agosto.

Tus servidores Linux comen del mismo certificado

Este es el punto que se cae de casi todas las coberturas, porque se han escrito desde el escritorio. El shim —el pequeño cargador que permite arrancar Linux con Secure Boot activado— lo firma Microsoft con el Microsoft UEFI CA 2011, el que caducó el 27 de junio. Una máquina con Secure Boot desactivado ni se entera. Lo que se complica es desplegar shims nuevos firmados solo con la clave de 2011 en máquinas que no puedan recibir actualizaciones de la base de datos UEFI.

Las distribuciones se adelantaron. Red Hat publicó shims firmados con las dos claves, la de 2011 y la de 2023, de modo que arrancan tanto si la máquina tiene enrolada una como la otra: shim-x64 16.1-4 en RHEL 10, 16.1-7 en RHEL 9 y 16.1-2 en RHEL 8. Para comprobar dónde estás, tres órdenes:

mokutil --sb-state                          # ¿está activado Secure Boot?
mokutil --db | grep -A13 "\[key"            # qué certificados hay en la base de datos
pesign -S -i /boot/efi/EFI/redhat/shimx64.efi   # con qué claves está firmado tu shim

Y una advertencia que suscribimos palabra por palabra: Red Hat pide explícitamente no forzar la instalación de actualizaciones del db y seguir siempre la guía del fabricante. En equipos HP y Fujitsu hace falta la actualización completa de firmware antes de tocar la base de datos por separado; el camino soportado suele ser fwupdmgr update, no una escritura a mano. Meter certificados a mano en una variable UEFI es exactamente el tipo de atajo que sale bien noventa y nueve veces.

La que nadie mira: tus máquinas virtuales

Una máquina virtual con arranque UEFI también tiene su DB y su KEK. No están en una placa: están en un fichero, el disco EFI, que se creó a partir de una plantilla del hipervisor. Y ahí aparece la diferencia de fondo con el hardware físico: una placa vieja se queda atrás una vez; una plantilla vieja se queda atrás cada vez que clonas. La propia guía de Red Hat lo dice en una línea que casi nadie ha citado: hay que actualizar el paquete edk2-ovmf en los hipervisores para que las máquinas virtuales nuevas hereden los certificados actualizados.

En Proxmox VE, que es lo que operamos a diario, la plantilla de variables EFI por defecto incluye los certificados de 2023 a partir de pve-edk2-firmware 4.2025.05-1. Los discos EFI creados antes de eso llevan solo los de 2011, y no se actualizan solos. Proxmox VE 9.2, publicado el 21 de mayo de 2026, añadió una comprobación en cada arranque de una máquina virtual con claves preenroladas, y el aviso es literal: WARN: EFI disk without 'ms-cert=2023k' option, suggesting that not all UEFI 2023 certificates from Microsoft are enrolled yet. Para arreglar una máquina existente, con la máquina apagada:

qm enroll-efi-keys <vmid>

La documentación de Proxmox describe la orden como «enrolar certificados actualizados importantes al disco EFI con claves preenroladas —actualmente, los certificados UEFI 2023 de Microsoft—» y advierte de que debe ejecutarse con la máquina apagada. Aquí viene la parte que solo se aprende con una cicatriz, y no es nuestra sino de Proxmox: en noviembre de 2025 intentaron enrolar el certificado nuevo automáticamente en el siguiente arranque de las máquinas Windows afectadas (qemu-server 9.0.28). Tuvieron que dar marcha atrás porque el cambio mandaba a las máquinas virtuales con Windows 11 a la pantalla de recuperación de BitLocker. Desde entonces la operación es manual y explícita.

De modo que el orden en un entorno virtualizado es este, y no otro: ten la clave de recuperación de BitLocker a mano antes de ejecutar nada, desactiva temporalmente los protectores con manage-bde -protectors -disable C: —se vuelven a activar solos en el siguiente reinicio— y solo entonces enrola. Y arregla la plantilla primero. Si empiezas por las máquinas existentes mientras tu plantilla dorada sigue pariendo discos EFI de 2011, estás achicando agua con la manguera abierta. Nosotros mantenemos plantillas de aprovisionamiento Windows y Linux para clientes, y es el sitio por el que hay que empezar.

Cuándo esto no es tu problema

Dos casos, y los decimos porque la honestidad ahorra trabajo. El primero: si tienes Secure Boot desactivado, nada de esto te afecta. No es una buena noticia —significa que llevas años sin la protección de la que va este artículo— pero no tienes ninguna urgencia esta semana. El segundo es más incómodo: hay máquinas que no van a recibir esto nunca. Microsoft indica que algunos sistemas necesitan actualizaciones de firmware del fabricante, y si ese fabricante nunca publica una versión con los certificados de 2023 para un modelo de 2016, no hay parcheo que lo arregle. Eso deja de ser una conversación de mantenimiento y pasa a ser una de renovación, con su presupuesto y su calendario.

Es el mismo agujero del que hablábamos al escribir sobre los BMC y las IPMI expuestas: el firmware es la capa que nadie tiene inventariada, nadie tiene monitorizada y nadie tiene en el contrato. Y esa capa acaba de estrenar una fecha de caducidad. Si además tienes Windows 10 en el parque, no es la única cuenta atrás abierta este otoño: el peaje del ESU también vence en octubre, y conviene que las dos decisiones las tome la misma persona el mismo día, porque la respuesta puede ser la misma máquina.

Lo que haríamos esta semana

• Medir, no suponer. Las cuatro líneas de PowerShell sobre una muestra de cada modelo de hardware, y el UEFICA2023Status recogido desde la herramienta de gestión para el resto. Sin ese número no hay conversación posible con el cliente.
• Firmware del fabricante antes que nada en los modelos que lo pidan, siguiendo su guía y sin forzar escrituras a mano en las variables UEFI.
• Anillo piloto por modelo de placa, no por departamento. Y leer el estado después, que para eso está.
• Plantillas de máquina virtual primero, VMs existentes después, con la clave de recuperación de BitLocker delante y los protectores desactivados durante la operación.

Nada de esto es difícil. Es, otra vez, trabajo que no se ve: inventario, ventana y alguien que lea la documentación del fabricante hasta el final. Es exactamente lo que hacemos cuando nos encargamos del puesto de trabajo de una empresa y de la operación del día a día, y es el tipo de tarea que solo aparece en la factura del mes que no pasó nada. Si quieres que te digamos cuántos equipos de tu parque tienen ya los certificados de 2023 —y cuántos no van a tenerlos nunca—, escríbenos.

Y la pregunta con la que cerramos, que es la misma que nos hicimos nosotros: si mañana se publica una revocación urgente para un bootkit, ¿cuántas de tus máquinas podrían recibirla? No cuántas están parcheadas. Cuántas pueden estarlo.