Secure Boot, la funcionalidad de arranque seguro introducida por Microsoft en 2011, siempre ha sido una fuente de fricción para los usuarios de Linux. Diseñada para impedir la ejecución de firmware no firmado, la característica protege a los equipos contra rootkits y malware de bajo nivel, pero a costa de obligar a los sistemas operativos alternativos a firmar sus cargadores de arranque con claves reconocidas por la UEFI del hardware.
Hasta hace poco, la mayoría de las distribuciones Linux había encontrado una vía aceptable: usar el programa shim, un pequeño cargador firmado por Microsoft que a su vez confía en las claves de la propia distribución. Sin embargo, la reciente expiración de los certificados de autoridad de 2011 emitidos por Microsoft ha puesto en jaque este delicado equilibrio. Cuando los certificados caducan, la cadena de confianza se rompe y los equipos con Secure Boot activado pueden rechazar el shim, impidiendo que Linux arranque.
¿Por qué importa ahora?
La expiración de los certificados no es un simple detalle técnico; afecta directamente a la experiencia del usuario y a la adopción de Linux en entornos empresariales y de consumo. Muchas marcas de portátiles y de sobremesa configuran Secure Boot de fábrica y no ofrecen una opción clara para desactivarlo sin perder garantías o soporte. Además, los administradores de TI que gestionan flotas de equipos deben enfrentarse a la necesidad de actualizar firmware, re‑firmar imágenes o, en el peor de los casos, reinstalar el sistema operativo.
Para los profesionales tech hispanohablantes, el problema se traduce en una pérdida de tiempo y recursos. Cada máquina que falla al arrancar requiere diagnóstico, pruebas de compatibilidad y, a menudo, la generación de nuevas claves de firma. En entornos donde la disponibilidad es crítica, como servidores de desarrollo o estaciones de trabajo de IA, cualquier interrupción se vuelve costosa.
Primeros pasos recomendados
Verificar la versión del firmware UEFI: Accede al BIOS/UEFI y comprueba si existe una actualización disponible. Los fabricantes suelen lanzar parches que actualizan la lista de certificados de confianza o añaden la opción de desactivar Secure Boot de forma más accesible.
Desactivar temporalmente Secure Boot: Si la política de la empresa lo permite, desactivar Secure Boot permite arrancar Linux sin problemas. Esta es la solución más rápida, aunque no la más segura a largo plazo.
Re‑firmar el shim con un certificado vigente: Algunas distribuciones, como Fedora y openSUSE, ya han publicado versiones de shim firmadas con certificados actualizados. Actualizar a la última versión del kernel y del paquete shim suele resolver el conflicto.
Utilizar una clave propia (Machine Owner Key – MOK): Herramientas como
mokutilpermiten crear y registrar una clave propia en la base de datos de la UEFI. Al firmar el cargador de arranque con esta clave, se mantiene la protección de Secure Boot sin depender de los certificados de Microsoft.
La solución provisional que evita el problema
Una alternativa que ha ganado popularidad es el uso de systemd-boot en lugar del tradicional GRUB. Systemd-boot es más ligero y, cuando se combina con una clave MOK, puede cargar el kernel directamente sin pasar por shim. El proceso consiste en:
- Generar una clave RSA y un certificado autofirmado.
- Inscribir la clave en la base de datos de la UEFI mediante
mokutil --import. - Configurar systemd-boot para que apunte al kernel firmado.
Esta metodología elimina la dependencia de los certificados de Microsoft y, por tanto, el problema de expiración. Además, reduce la complejidad del proceso de arranque, lo que se traduce en tiempos de arranque ligeramente más rápidos.
¿Qué esperar a futuro?
Microsoft ha anunciado que renovará sus autoridades de certificación y que ofrecerá un programa de registro de claves para distribuidores de Linux. Mientras tanto, la comunidad de código abierto está trabajando en un estándar de firma independiente que no requiera la intervención de Microsoft. La inclusión de claves de hardware TPM para validar la cadena de confianza podría ser la solución definitiva.
En cualquier caso, los profesionales deben mantenerse alerta: las actualizaciones de firmware y de los paquetes de arranque son ahora una parte esencial del mantenimiento de sistemas Linux con Secure Boot. Ignorar el problema puede resultar en interrupciones inesperadas, mientras que aplicar las soluciones descritas garantiza una experiencia de usuario fluida y segura.
Conclusión
El vencimiento de los certificados de 2011 ha convertido a Secure Boot en un obstáculo real para los usuarios de Linux. Sin embargo, con una combinación de actualizaciones de firmware, uso de claves propias y la migración a systemd-boot, es posible sortear el inconveniente sin sacrificar la seguridad. Los profesionales tech deben incorporar estas prácticas en sus rutinas de gestión de sistemas para evitar sorpresas desagradables y mantener la confianza en sus entornos Linux.
