{"id":182058,"date":"2026-06-14T14:48:26","date_gmt":"2026-06-14T12:48:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/istekaet-vremya-zhizni-sertifikata-kotorym-zaveren-zagruzchik-dlya-uefi-secure-boot-v-distributivah-linux"},"modified":"2026-06-14T14:48:26","modified_gmt":"2026-06-14T12:48:27","slug":"istekaet-vremya-zhizni-sertifikata-kotorym-zaveren-zagruzchik-dlya-uefi-secure-boot-v-distributivah-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/istekaet-vremya-zhizni-sertifikata-kotorym-zaveren-zagruzchik-dlya-uefi-secure-boot-v-distributivah-linux","title":{"rendered":"Est\u00e1 a punto de expirar el tiempo de vida del certificado que firma el cargador para UEFI Secure Boot en las distribuciones de Linux.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Los desarrolladores de Fedora Linux han aclarado la situaci\u00f3n relacionada con la expiraci\u00f3n a finales de junio del certificado de Microsoft, que se usa para certificar la firma digital de la capa Shim, utilizada para la carga verificada de distribuciones Linux en modo UEFI Secure Boot. La transici\u00f3n al nuevo certificado deber\u00eda pasar desapercibida para los usuarios, ya que, en realidad, la finalizaci\u00f3n de la vida \u00fatil del certificado solo resultar\u00e1 en la imposibilidad de utilizarlo para crear nuevas firmas. Durante la carga del UEFI Secure Boot, no se verifica la validez del certificado y solo importa la revocaci\u00f3n de certificados comprometidos. <\/p>\n
Los sistemas existentes sin la instalaci\u00f3n de la actualizaci\u00f3n shim continuar\u00e1n cargando hasta que la clave p\u00fablica del certificado sea eliminada de la firmware o sea incluido en la lista de certificados revocados de UEFI (DBX). El certificado de Microsoft solo firma la capa de carga shim, en la cual se encuentra la clave p\u00fablica de la distribuci\u00f3n, utilizada para certificar los componentes cargados, como el cargador GRUB2, el n\u00facleo de Linux, los m\u00f3dulos del n\u00facleo y los procesos utilizados durante el arranque, como fwupd. Este enfoque permite a Microsoft certificar solo los cambios en la capa shim y garantizar la verificaci\u00f3n del proceso de carga de la distribuci\u00f3n de forma independiente.<\/p>\n
El certificado de Microsoft para certificar firmware de terceros para UEFI Secure Boot ha estado en vigor desde 2011. En 2023, se gener\u00f3 un nuevo certificado que comenzar\u00e1 a aplicarse para formar firmas a partir de octubre de 2025. En el repositorio de Fedora Rawhide, que es la base para la liberaci\u00f3n de Fedora 45, ya se ha a\u00f1adido la versi\u00f3n actualizada de shim, certificada por varias claves para garantizar la m\u00e1xima compatibilidad con el hardware (puede ser utilizado tanto en firmware antiguas sin la clave p\u00fablica del nuevo certificado, como en firmware sin la clave p\u00fablica del antiguo certificado).<\/p>\n
A pesar de que la expiraci\u00f3n del certificado de Microsoft no deber\u00eda afectar la capacidad de arranque, los desarrolladores de Fedora recomiendan a los usuarios actualizar la base de datos con las claves para Secure Boot cuando se lancen nuevas versiones de firmware para su hardware. Para determinar si el sistema se ha iniciado en modo UEFI Secure Boot se puede usar el comando 'mokutil \u2014sb-state', y para mostrar la lista de claves p\u00fablicas disponibles en el firmware \u2014 'mokutil \u2014db \u2014short'. Para ver las claves que han firmado la capa shim se puede ejecutar el comando 'sudo pesign -S -i \/boot\/efi\/EFI\/fedora\/shimx64.efi', despu\u00e9s de haber instalado el paquete pesign. Para comprobar si hay una actualizaci\u00f3n de firmware y su instalaci\u00f3n, se puede ejecutar el comando 'sudo fwupdmgr update'. <\/p>\n
La pr\u00f3xima versi\u00f3n del intermediario shim solo estar\u00e1 firmada con un nuevo certificado de Microsoft y es necesario actualizar el firmware para preparar sus sistemas para este cambio. La actualizaci\u00f3n de shim se lanzar\u00e1 en caso de que se encuentren vulnerabilidades y errores graves, lo que puede suceder en un mes o en un a\u00f1o. Durante la existencia de shim en el proyecto, se han encontrado vulnerabilidades cr\u00edticas, y el \u00faltimo informe sobre problemas de seguridad en shim fue publicado hace solo unos d\u00edas. <\/p>\n
El informe destaca dos vulnerabilidades recientemente descubiertas, CVE-2026-8863 y \nCVE-2026-10797, que permiten la ejecuci\u00f3n de c\u00f3digo durante una etapa temprana del arranque antes de transferir el control al sistema operativo, evadir la protecci\u00f3n de UEFI Secure Boot y permitir el arranque de componentes del n\u00facleo que no est\u00e1n firmados digitalmente. Los problemas afectan a versiones de shim hasta la versi\u00f3n 0.9 inclusive, compiladas antes de 2016. Sistemas muy antiguos, como \n RedHat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, ROSA Linux R10\/R9 y openSUSE con shim 0.9. Las versiones de shim hasta la 0.9 inclusive se han agregado a la base de firmas digitales revocadas DBX (Base de Datos de Firmas Prohibidas de UEFI) y, en caso de actualizaci\u00f3n de DBX, no se podr\u00e1n usar para arrancar en modo UEFI Secure Boot. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"