Secure Boot, la tecnología de arranque seguro introducida por Microsoft en 2012, siempre ha sido una piedra angular de la seguridad del firmware UEFI. Sin embargo, para los usuarios de Linux, ha significado una serie de obstáculos que van desde la necesidad de firmar kernels hasta la búsqueda de claves de arranque compatibles. La situación ha alcanzado un punto crítico con el próximo vencimiento de los certificados de autoridad de 2011 emitidos por Microsoft, un hecho que amenaza con bloquear la mayoría de las distribuciones Linux en equipos modernos que activan Secure Boot por defecto.

¿Qué es Secure Boot y por qué afecta a Linux?

Secure Boot verifica la firma digital de cada componente que se carga durante el proceso de arranque. Sólo el firmware UEFI confía en firmas que provienen de una lista de autoridades de certificación (CA) preinstaladas. En los sistemas Windows, esa lista incluye los certificados de Microsoft, garantizando que sólo software firmado por la compañía pueda ejecutarse. Linux, por su naturaleza abierta, no posee una firma oficial de Microsoft; en su lugar, las distribuciones deben registrar sus propias claves o utilizar la "MokList" (Machine Owner Key) para que el firmware acepte su kernel.

Durante años, la comunidad ha encontrado formas de sortear este obstáculo: herramientas como shim, un pequeño cargador firmado por Microsoft, y paquetes de clave de firma (MOK) que el usuario enrola manualmente. Estas soluciones, aunque funcionales, añaden pasos extra al proceso de instalación y a las actualizaciones de kernel, generando confusión y, en algunos casos, fallos de arranque.

El calendario de vencimiento y sus consecuencias

Los certificados de autoridad de Microsoft emitidos en 2011 están programados para expirar a finales de este año. Una vez que eso ocurra, cualquier firmware que siga la especificación UEFI‑2.3.1 rechazará automáticamente las firmas que dependan de esos certificados. El impacto será inmediato:

  • Distribuciones que dependen de shim firmado con esos certificados dejarán de arrancar.
  • Los módulos de terceros, como controladores de GPU o tarjetas de red, que se firman con claves antiguas, serán bloqueados.
  • Los usuarios que actualicen su BIOS/UEFI después del vencimiento verán su sistema inutilizable si no han migrado a una nueva cadena de confianza.

Para muchos profesionales tech que utilizan Linux en entornos de desarrollo, servidores on‑premise o laptops de trabajo, la perspectiva de quedarse sin poder iniciar el sistema es inaceptable.

¿Por qué Microsoft no ha actualizado sus certificados?

Microsoft ha adoptado una postura de "cambio de ciclo": en vez de renovar los certificados antiguos, promueve la migración a la nueva infraestructura de firmas basada en la raíz de confianza "Microsoft UEFI CA 2022". Sin embargo, la documentación oficial es escasa y la mayoría de los fabricantes de hardware no han actualizado sus listas de CA en los firmwares de sus dispositivos. Esta falta de coordinación deja a los usuarios de Linux en la zona de incertidumbre.

La solución: migrar a la nueva cadena de confianza con shim 2.4 y MokManager

Afortunadamente, la comunidad de Linux ya ha preparado una solución que funciona como "analgésico" para este dolor de cabeza. La versión 2.4 de shim, lanzada a principios de 2024, incluye firmas basadas en la nueva CA de Microsoft y permite una transición sin perder compatibilidad con versiones anteriores. Los pasos recomendados son los siguientes:

  1. Actualizar el paquete shim a la versión 2.4 o superior desde los repositorios oficiales de tu distribución (por ejemplo, apt-get install shim-signed en Debian/Ubuntu o dnf install shim en Fedora).
  2. Ejecutar MokManager para enrolar tu propia clave de firma (MOK). El proceso se inicia al reiniciar y pulsar la tecla adecuada (normalmente Esc o F2) para entrar al menú de gestión de claves.
  3. Refirmar los kernels y módulos con la nueva clave usando sbsign o las herramientas provistas por la distribución. La mayoría de las distro modernas ya automatizan este proceso con scripts de post‑instalación.
  4. Verificar la lista de CA en el firmware UEFI. En algunos equipos es necesario habilitar la opción "Additional UEFI Firmware Keys" o similar para aceptar claves externas.

Una vez completados estos pasos, el sistema continuará arrancando con Secure Boot habilitado, pero ya no dependerá de los certificados caducados de 2011.

Impacto para los profesionales y empresas

Para los equipos de TI, la recomendación es actuar con anticipación. Programar una ventana de mantenimiento para actualizar shim y reenrolar claves evitará interrupciones inesperadas. Además, la práctica de firmar los kernels internos forma parte de una estrategia de "Zero Trust" que refuerza la seguridad del ciclo de vida del software.

Empresas que despliegan Linux en hardware heterogéneo deben:

  • Inventariar los modelos de equipos y su versión de firmware UEFI para identificar aquellos que aún no incluyen la nueva CA.
  • Automatizar la actualización de shim y la re‑firma de imágenes mediante herramientas de gestión de configuración como Ansible o SaltStack.
  • Comunicar a los usuarios finales la necesidad de reiniciar y enrolar nuevas claves, evitando sorpresas durante el arranque.

Conclusión

El vencimiento de los certificados de Microsoft de 2011 representa un punto de inflexión para la relación entre Secure Boot y Linux. Aunque la medida persigue mejorar la seguridad del firmware, sin una migración proactiva los usuarios pueden quedar atrapados con sistemas inoperables. La comunidad ha respondido con shim 2.4 y un proceso de enrolamiento de claves que, bien ejecutado, elimina el obstáculo sin sacrificar la protección que ofrece Secure Boot. La clave está en planificar la actualización antes de que los certificados caduquen y en incorporar la firma de componentes en la rutina de mantenimiento de cualquier infraestructura Linux.

No dejes que una cuestión de certificados ponga en jaque tu productividad: actúa ahora y mantén tu Linux seguro y funcional.