La fecha pasó; la comprobación sigue importando

A fecha de 24 de septiembre de 2026, la transición ya no es un aviso sobre una fecha futura: el certificado Microsoft Corporation UEFI CA 2011 dejó de usarse para nuevas firmas el 26 de junio. Microsoft trasladó la firma de aplicaciones UEFI de terceros a las autoridades de 2023, incluida Microsoft UEFI CA 2023; las Option ROM cuentan con una autoridad de 2023 separada. La fecha exacta importa porque algunos titulares previos lo presentaban como si el propio Secure Boot tuviera una fecha de vencimiento. No es así: lo que caduca son certificados concretos usados para firmar determinados componentes. (learn.microsoft.com)

Secure Boot es una función del firmware UEFI que valida las firmas de programas de arranque antes de permitirles ejecutarse. En la cadena pueden intervenir el gestor de arranque del sistema operativo, cargadores intermedios y controladores UEFI, incluidos componentes de firmware conocidos como Option ROM. La base de datos de confianza db contiene certificados o imágenes autorizadas; la base de revocación dbx identifica elementos que no deben cargarse. Por eso el estado de un PC depende de las claves que tenga registradas su firmware y de las firmas concretas de los componentes que intenta iniciar, no simplemente de la edad del equipo. (learn.microsoft.com)

Caducidad no es lo mismo que revocación

La distinción fundamental es entre dejar de emitir firmas nuevas con un certificado y revocar la confianza en ese certificado o en un programa firmado con él. La caducidad del certificado de 2011 impide utilizarlo para firmar nuevos componentes mediante el proceso de Microsoft; por sí sola no borra la clave de la base db del firmware ni invalida automáticamente todos los archivos firmados anteriormente. Microsoft indica que un shim de Linux ya firmado con la autoridad de 2011 puede seguir arrancando si el firmware conserva esa autoridad y el shim o su nivel SBAT no han sido revocados. (learn.microsoft.com)

La revocación es una acción distinta: las entradas de dbx pueden bloquear certificados o componentes específicos. Si una imagen aparece en la lista de confianza y también en la lista de revocación, prevalece la revocación. Así, un equipo puede seguir iniciando hoy un cargador antiguo y, a la vez, no estar preparado para recibir en el futuro una versión corregida que solo tenga firma de 2023. Que arranque no demuestra que la cadena esté actualizada: solo confirma que el firmware acepta el camino de inicio usado en ese arranque. (learn.microsoft.com)

Qué se nota en Windows y en un sobremesa normal

En Windows, Microsoft afirma que un dispositivo sin los nuevos certificados puede seguir arrancando e instalando actualizaciones ordinarias. El perjuicio principal es hacia delante: el PC podría no recibir o validar futuras protecciones y actualizaciones que afecten al entorno previo al inicio, como el gestor de arranque y otros componentes tempranos. Esto no equivale a que Windows deje de funcionar el día siguiente a la caducidad, ni a que todos los equipos necesiten una actualización de BIOS inmediata. La compatibilidad depende del modelo, del firmware OEM y de la situación real de sus bases de claves. (learn.microsoft.com)

La página de Microsoft para usuarios y administradores describe escenarios de mayor riesgo cuando el firmware es antiguo o el proceso de actualización falla: errores de validación, solicitudes de recuperación de BitLocker, bloqueos al iniciar o imposibilidad de arrancar. Son problemas potenciales ligados a circunstancias concretas, no el resultado inevitable de que el calendario marque una fecha. La recomendación razonable es mantener Windows y el firmware al día mediante los canales oficiales del fabricante, y no alterar claves UEFI por cuenta propia para intentar anticiparse. Si el equipo está administrado por una organización, conviene seguir su procedimiento y no iniciar cambios manuales. (learn.microsoft.com)

Linux y arranque dual: importa la pareja de firmas y claves

En Linux, el componente intermedio habitual en muchas distribuciones con Secure Boot es shim: el firmware valida su firma y este verifica los siguientes elementos de la cadena, como GRUB y el kernel. Microsoft documenta dos desajustes posibles: un sistema con firmware que solo confía en la CA de 2023 no aceptará un shim firmado únicamente con la CA de 2011; y un sistema que confía solo en 2011 no aceptará un shim firmado únicamente con 2023. En ambos casos, no basta con instalar “la versión más nueva”: el cargador instalado y los certificados que confía el firmware deben ser compatibles. (learn.microsoft.com)

Para el arranque dual, Windows puede servir como canal de entrega de ciertas actualizaciones en equipos compatibles, pero eso no demuestra que el cargador Linux o cada distribución estén ya listos. Los mantenedores deben publicar componentes firmados con las autoridades nuevas, comprobar que el firmware de destino las reconoce y considerar las listas de revocación y la política SBAT. Red Hat, por ejemplo, recomienda actualizar tanto la base de confianza del firmware cuando exista una actualización apropiada como el shim de la distribución; también advierte que revocar sin más el certificado de 2011 puede impedir que arranquen componentes que todavía dependen de él. No extrapoles el calendario de una distribución a todas las demás. (learn.microsoft.com)

Cómo revisar el estado sin tocar claves a ciegas

En un PC Windows doméstico, revisa Windows Update y la sección Seguridad del dispositivo > Arranque seguro de la aplicación Seguridad de Windows, si está disponible en tu versión. Microsoft documenta avisos y estados para informar de la actualización de certificados; en equipos gestionados, la visibilidad y el despliegue pueden controlarse de otro modo. Para administradores, la documentación señala indicadores como el valor de registro UEFICA2023Status y eventos del sistema, entre ellos los eventos 1801 y 1795. Esos datos ayudan a distinguir una actualización pendiente de un error de firmware, pero un usuario no debería interpretar un único mensaje sin consultar la guía correspondiente a su edición y equipo. (learn.microsoft.com)

En distribuciones Linux, herramientas como mokutil permiten consultar si Secure Boot está habilitado y examinar certificados de la base del firmware; la guía de Red Hat también muestra cómo identificar las firmas de shim. El resultado debe interpretarse con cuidado: que aparezca una CA de 2023 no garantiza por sí solo que todos los componentes estén actualizados, y que no aparezca puede ser relevante para una ruta de arranque nueva sin significar que el equipo vaya a fallar ahora. En un sistema con cifrado, medición de arranque o desbloqueo automático ligado al TPM, cambiar las bases UEFI puede modificar mediciones como PCR7 y exigir revisar la configuración. Haz inventario antes de cambiar nada. (redhat.com)

Qué hacer si el fabricante no ofrece una actualización

Primero identifica el modelo exacto de placa base o sobremesa y consulta su página de soporte: las actualizaciones de las bases UEFI suelen depender del fabricante del firmware o del OEM. En Windows, instala las actualizaciones ofrecidas por Windows Update y revisa el estado que indique el sistema; en Linux, usa el mecanismo recomendado por la distribución, como fwupd cuando el dispositivo y la actualización sean compatibles. En equipos administrados, piloto y despliegue gradual son más prudentes que aplicar el cambio a toda una flota sin validación, especialmente si hay BitLocker, arranque dual o políticas de claves personalizadas. Microsoft recomienda revisar primero el firmware OEM y probar actualizaciones representativas antes de ampliarlas. (learn.microsoft.com)

Si no hay firmware actualizado, no hay una respuesta universal que garantice compatibilidad futura. Solicita orientación al fabricante y a la distribución concreta, conserva copias de recuperación de BitLocker y datos importantes, y evita borrar la CA antigua, escribir variables UEFI con instrucciones genéricas o desactivar Secure Boot como reacción automática. Red Hat advierte que quitar o revocar la autoridad de 2011 puede dejar inoperantes cargadores o Option ROM que dependan de ella; Microsoft también describe configuraciones incompatibles capaces de impedir el arranque. La conclusión práctica es acotada: la caducidad no apaga por sí sola el sobremesa, pero actualizar y verificar la cadena de confianza ayuda a conservar la capacidad de recibir futuras firmas y protecciones de arranque. (redhat.com)