Linux Secure Boot: certificados expiran en junio 2026

¿Qué está pasando con los certificados de Secure Boot en Linux?

El 27 de junio de 2026 expiró el certificado Microsoft Corporation UEFI CA 2011, el que firma el cargador de arranque shim que usan prácticamente todas las distribuciones de Linux para arrancar con Secure Boot habilitado. Esto no significa que tu servidor dejó de funcionar de la noche a la mañana, pero sí plantea un problema de infraestructura que debes resolver antes de que afecte tu capacidad de actualizar o desplegar nuevos sistemas.

Si gestionas servidores Linux, workstations de desarrollo o infraestructura cloud con Secure Boot activado, esta expiración impacta directamente tu capacidad de mantener la cadena de confianza del arranque seguro. Ignorarlo puede dejarte vulnerable a ataques de bootkit o impedir futuras actualizaciones de seguridad críticas.

¿Qué certificados expiraron y cuándo exactamente?

Microsoft gestionó una transición gradual desde los certificados de 2011 hacia los de 2023. Las fechas críticas son:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Microsoft Corporation KEK CA 2011: expiró el 24 de junio de 2026
Microsoft Corporation UEFI CA 2011: expiró el 27 de junio de 2026 (el que firma shim en Linux)
Microsoft Windows Production PCA 2011: expira el 19 de octubre de 2026

El certificado UEFI CA 2011 es el crítico para Linux porque firma el shim, el cargador de arranque intermedio que permite a distribuciones como Ubuntu, Fedora, Red Hat Enterprise Linux y SUSE arrancar en sistemas con Secure Boot habilitado. Sin este certificado vigente en la base de datos UEFI del firmware, las nuevas versiones de shim no podrán validarse.

¿Qué distribuciones de Linux se ven afectadas?

Cualquier distribución que dependa del mecanismo de shim firmado por Microsoft para Secure Boot está en la lista. Esto incluye:

Ubuntu y derivados (Debian con shim-signed)
Fedora y Red Hat Enterprise Linux
SUSE Linux Enterprise y openSUSE
Cualquier distro que use la cadena de confianza de Microsoft para Secure Boot

El impacto real depende de dos factores: si el firmware de tu hardware recibió las nuevas claves de 2023 mediante actualización del fabricante, y si tu distribución distribuyó una versión actualizada de shim firmada con la cadena adecuada.

¿Cómo verificar y actualizar tu sistema?

Paso 1: Verifica si tu firmware tiene las claves 2023

Puedes usar herramientas como mokutil, sbkeysync o efitools para inspeccionar las claves instaladas en tu firmware UEFI:

mokutil --list-enrolled

O verifica la versión de shim instalada:

apt-cache show shim-signed | grep Built

Paso 2: Actualiza el firmware UEFI/BIOS

La vía principal es instalar las actualizaciones de firmware del fabricante de tu hardware. Si tu equipo es relativamente moderno (post-2020), es probable que el fabricante haya publicado una actualización que incluye las nuevas claves de 2023.

En Linux, puedes usar fwupd junto con LVFS (Linux Vendor Firmware Service) para verificar si hay actualizaciones disponibles:

fwupdmgr get-updates
fwupdmgr update

Si tu fabricante publica allí la actualización UEFI, aparecerá en el gestor de actualizaciones de tu distribución.

Paso 3: Actualiza el paquete shim de tu distribución

En sistemas basados en Debian/Ubuntu:

sudo apt update
sudo apt -y install --reinstall shim-signed

En Fedora/RHEL, actualiza el paquete shim mediante dnf o yum según corresponda.

¿Qué riesgos hay para hardware antiguo?

Este es el punto crítico para founders que gestionan infraestructura propia o servidores on-premise. El mayor riesgo está en equipos con firmware viejo que no puede recibir las nuevas claves de 2023 porque el fabricante ya no da soporte.

En esos casos:

El sistema sigue arrancando con el shim existente (no hay un "apagón" inmediato)
Pero quedas limitado para futuras rotaciones de claves y revocaciones de seguridad
No podrás aplicar mitigaciones para vulnerabilidades de arranque descubiertas después de la expiración
Las nuevas versiones de shim de tu distribución podrían no ser compatibles

Si gestionas un parque heterogéneo de hardware, haz un inventario urgente de modelos, versiones de firmware y estado de Secure Boot. Los equipos sin soporte de actualización de firmware deberían considerarse para reemplazo o ejecutarse con Secure Boot desactivado (evaluando el riesgo de seguridad).

¿Qué significa esto para tu startup?

Si tu startup opera infraestructura Linux propia, desarrolla hardware con Linux embebido, o ofrece servicios managed donde controlas el stack completo, esto requiere acción inmediata:

Acción 1: Auditoría de infraestructura

Inventario todos los sistemas Linux con Secure Boot habilitado. Verifica:

Modelo de hardware y fabricante
Versión de firmware UEFI/BIOS instalada
Si hay actualizaciones de firmware disponibles en el sitio del fabricante
Versión de shim instalada en cada sistema

Prioriza servidores de producción y sistemas que requieren compliance de seguridad (SOC 2, ISO 27001, etc.).

Acción 2: Plan de actualización escalonado

No actualices todo en producción el mismo día. Sigue este flujo:

Prueba en 2-3 sistemas representativos de cada modelo de hardware
Valida que el arranque funciona correctamente después de actualizar firmware y shim
Verifica que herramientas de despliegue (PXE, imágenes, configuraciones de seguridad de terceros) siguen operando
Despliega gradualmente al resto del parque
Documenta el estado de cada sistema para auditorías futuras

Acción 3: Evalúa tu estrategia de hardware

Si descubres que parte de tu infraestructura no tiene soporte de actualización de firmware, evalúa:

¿Puedes operar esos sistemas con Secure Boot desactivado sin violar requisitos de compliance?
¿El costo de reemplazo es menor que el riesgo operativo de quedar sin capacidad de actualizar la cadena de confianza?
¿Deberías estandarizar en hardware con soporte de firmware a largo plazo para futuros ciclos de actualización?

Estado actual en 2026: ¿qué debes hacer ahora?

A junio de 2026, las fechas críticas de KEK CA 2011 y UEFI CA 2011 ya vencieron. El estado correcto es:

Equipos modernos que recibieron actualizaciones de firmware y OS deben funcionar con normalidad
Hardware antiguo sin soporte de actualización está en zona de riesgo operativo
Nuevos despliegues deben verificar que el firmware tenga las claves 2023 antes de poner en producción

Google Cloud, por ejemplo, incluyó automáticamente los certificados nuevos en todas las instancias creadas después del 7 de noviembre de 2025. Si usas cloud público, verifica con tu proveedor si ya gestionaron esta transición (la mayoría lo hizo).

El impacto no es un fallo inmediato, sino una pérdida progresiva de capacidad de actualización de la cadena de confianza de arranque seguro. Para una startup, esto se traduce en deuda técnica de infraestructura que puede complicar auditorías de seguridad o limitar opciones de hardening futuro.

Conclusión

La expiración de los certificados Secure Boot de Microsoft es un recordatorio de que la infraestructura de bajo nivel también requiere mantenimiento proactivo. No es un problema que puedas ignorar hasta que algo falle: la ventana de acción es ahora, mientras tus sistemas aún arrancan y puedes planificar la actualización sin presión de incidente.

Para founders técnicos: agrega la gestión de firmware UEFI a tu checklist de mantenimiento de infraestructura, junto con parches de seguridad y rotación de credenciales. La seguridad del arranque es la primera línea de defensa contra ataques persistentes, y dejarla vencer por inacción es un riesgo operativo evitable.