El 11 de julio de 2026 salió Debian 13.6, la sexta actualización puntual de "trixie". Entre los más de cien parches de seguridad hay un cambio que no es un CVE pero puede pegar más fuerte que cualquiera de ellos: la autoridad certificadora (CA) de Secure Boot de 2013 —la que firma los bootloaders de Linux en la mayoría de las máquinas— expiró. Si administrás un Cloud Server con Secure Boot activo, un reboot mal timeado después de una actualización puede dejarte con una pantalla de firmware y nada más. Vamos a lo concreto: qué pasó, por qué importa y qué hacer hoy.
La expiración de la CA UEFI de Secure Boot de 2013 significa que ese certificado ya no puede firmar binarios nuevos como el shim (el primer eslabón de arranque de Linux bajo Secure Boot). Los sistemas que ya lo tienen inscripto en su firmware siguen booteando; el riesgo aparece cuando llega un shim firmado solo con el certificado nuevo de 2023 y el firmware todavía no confía en él. Debian 13.6 mitiga esto con fwupd 2.0.20 y un shim recompilado.
¿Qué cambió exactamente con la expiración de la CA de 2013?
Caducó el certificado raíz que, durante más de una década, firmó los cargadores de arranque de Linux. Según el anuncio oficial de Debian 13.6, "The 2013 UEFI Secure Boot CA installed by default on most PCs and used to sign bootloaders has now expired" ("la CA de Secure Boot UEFI de 2013 instalada por defecto en la mayoría de las PC y usada para firmar bootloaders ya expiró"). En la taxonomía de Microsoft, el certificado equivalente que firma el shim de Linux es el Microsoft UEFI CA 2011, que según la guía de expiración de certificados de Microsoft caducó el 27 de junio de 2026.
Un punto clave para no entrar en pánico: la expiración no "apaga" las máquinas que ya arrancaban. Un certificado vencido no puede firmar binarios nuevos, pero el firmware sigue confiando en los binarios ya firmados y en la CA ya inscripta. El problema es de continuidad hacia adelante, no de un apagón instantáneo.
¿Por qué esto puede dejar tu Cloud Server sin bootear?
Porque la cadena de arranque de Secure Boot es una cadena de confianza, y basta con que se rompa un eslabón. El escenario de riesgo concreto es: tu firmware confía únicamente en la CA de 2011/2013, recibís por apt un shim nuevo firmado solo con la CA de 2023, reiniciás, y el firmware se niega a validar ese binario. Con Secure Boot activo, eso es un servidor que no bootea.
- La confianza vive en el firmware, no en el disco. Actualizar el paquete
shimconaptno agrega el certificado nuevo a la base de datos UEFI (db/KEK). Ese enrolamiento lo hace el fabricante,fwupdo vos a mano. - El peligro está en el intervalo. Si el
shimdel disco ya está firmado con el certificado de 2023 pero el firmware todavía solo conoce el de 2011, el reboot es el momento en que todo se rompe. - Afecta sobre todo a bare metal y VMs con Secure Boot on. Muchos VPS corren con Secure Boot desactivado o con una cadena de arranque propia y no se ven impactados; conviene verificar el estado real antes de asumir cualquier cosa.
¿Qué trae Debian 13.6 para resolverlo?
Tres piezas coordinadas para que la transición de certificados no te agarre desprevenido. Según el anuncio de Debian 13.6, fwupd se actualizó a la versión 2.0.20, capaz de actualizar la propia CA, la Key Exchange Key (KEK) y la base de revocaciones (DBX); y el shim firmado se recompiló para seguir arrancando con el certificado de 2023.
- fwupd 2.0.20 puede actualizar CA, KEK y DBX. Es el mecanismo recomendado para inscribir el certificado nuevo en el firmware sin meter mano a UEFI a mano, en el hardware que lo soporta vía LVFS.
- shim recompilado para el certificado de 2023. El paquete pasó a
shim 16.1-2~deb13u1, con nueva release upstream y nivel de revocación SBAT2025021800, para asegurar compatibilidad con el Microsoft UEFI CA 2023. - El instalador ahora chequea antes de romper. El instalador de Debian verifica posibles problemas de arranque antes de continuar, para no dejar un sistema recién instalado que no bootea con Secure Boot.
Debian remite a su wiki de cambios de CA de Secure Boot para el paso a paso según tu hardware. En la misma línea, la guía de Red Hat sobre los cambios de 2026 aclara que su nuevo shim viene firmado con los certificados de 2011 y 2023, de modo que arranca en máquinas que tengan inscripto cualquiera de los dos: la misma estrategia de doble firma que hace posible una migración sin cortes.
¿Qué certificados de Microsoft expiran y cuándo?
Son tres certificados de la era 2011, con reemplazos de 2023, y las fechas están escalonadas. Esto importa incluso en un mundo Linux porque el shim se firma contra la cadena de Microsoft.
| Certificado 2011 (expira) | Fecha | Para qué se usa | Reemplazo 2023 |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | Junio 2026 | Gestiona actualizaciones de db/DBX | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | 27 de junio de 2026 | Firma bootloaders de terceros (shim de Linux) | Microsoft UEFI CA 2023 |
| Windows Production PCA 2011 | 19 de octubre de 2026 | Firma el bootloader de Windows | Windows UEFI CA 2023 |
Para un servidor Linux, el que te toca directamente es el Microsoft UEFI CA 2011: es el que firma el shim. Los otros dos importan si compartís hardware con arranque dual o gestionás flotas mixtas.
¿Qué podés hacer hoy en tu servidor?
Antes que nada, averiguá si Secure Boot está siquiera activo: si no lo está, no hay riesgo inmediato de no-booteo por este tema. Si lo está, el orden importa —primero confirmar que el firmware confía en el certificado nuevo, después reiniciar—. Estos comandos son el punto de partida:
- No reinicies a ciegas tras un update de shim con Secure Boot on. Confirmá primero que el certificado de 2023 esté inscripto (por
fwupdo por el update del fabricante) siguiendo la guía enlazada de Debian. Un reboot es reversible en un desktop; en un servidor remoto sin consola fuera de banda, no tanto.
Revisá y aplicá actualizaciones de firmware/certificados con fwupd:
fwupdmgr refresh
fwupdmgr get-updates
fwupdmgr updateEn el hardware soportado, acá es donde se inscriben la CA/KEK/DBX nuevas.
Actualizá el sistema para traer fwupd 2.0.20 y el shim nuevo:
apt update && apt full-upgradeVerificá el estado de Secure Boot:
mokutil --sb-stateSi devuelve "SecureBoot disabled", este cambio no te va a impedir bootear (aunque igual conviene aplicar los updates).
Si venís aplicando actualizaciones automáticas de seguridad sin control de reinicios, este es un caso de manual donde ese control importa: un unattended-upgrade que instala el shim nuevo y un reinicio programado justo después pueden combinarse mal. Vale la pena revisar tu política de reboots esta semana.
Preguntas frecuentes
¿Mi servidor se va a apagar solo cuando expire el certificado?
No. La expiración impide firmar binarios nuevos, pero el firmware sigue confiando en la CA ya inscripta y en los binarios ya firmados. Un sistema que hoy bootea va a seguir booteando; el riesgo aparece recién cuando instalás un shim firmado solo con el certificado de 2023 sin haber actualizado antes el firmware.
¿Tengo que hacer algo si Secure Boot está desactivado?
No para evitar el no-booteo. Con Secure Boot off, el firmware no valida firmas, así que un shim nuevo arranca igual. Aun así conviene aplicar apt full-upgrade para llevar el resto de los parches de seguridad de Debian 13.6 y quedar en condiciones si algún día activás Secure Boot.
¿Por qué Debian dice "CA de 2013" y Microsoft habla de "CA 2011"?
Son nombres distintos para la misma cadena de firma de terceros que valida el shim de Linux. Debian la describe por la época en que se instaló por defecto; Microsoft la identifica por el nombre de su certificado, "Microsoft UEFI CA 2011". Para lo práctico, es el mismo eslabón el que caduca y el que Debian 13.6 viene a reemplazar.
¿Qué es exactamente fwupd y por qué es la pieza clave acá?
fwupd es el demonio de actualización de firmware de Linux. La versión 2.0.20 que trae Debian 13.6 puede escribir la nueva CA, la KEK y la base de revocación DBX en el firmware UEFI, en el hardware compatible. Es lo que permite inscribir el certificado de 2023 sin entrar a la BIOS a hacerlo a mano.
¿Esto afecta también a Ubuntu, RHEL o Fedora?
Sí, es un cambio de todo el ecosistema, no exclusivo de Debian. Red Hat ya publicó nuevos shim para RHEL 8, 9 y 10 firmados con los certificados de 2011 y 2023, y el resto de las distribuciones están haciendo lo propio. Cualquier servidor Linux con Secure Boot activo entra en la misma transición de certificados.
En resumen: Debian 13.6 no es un point release más. Trae la maquinaria (fwupd 2.0.20 + shim recompilado) para cruzar el vencimiento de la CA de Secure Boot sin quedar varado, pero la parte de inscribir el certificado nuevo en el firmware y elegir cuándo reiniciar sigue siendo tuya. Verificá el estado de Secure Boot en tu Cloud Server, actualizá, confirmá el certificado de 2023 y recién ahí reiniciá.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
