Guía de vencimiento de los certificados de inicio seguro de Microsoft

Dado que varios certificados de inicio seguro de Microsoft vencen en 2026, este documento proporciona orientación para actualizar las instancias de VM protegida de Compute Engine de modo que confíen en los certificados de inicio seguro de Microsoft actualizados para el inicio seguro de UEFI (interfaz de firmware extensible unificada). Los dos certificados más importantes que están cerca de vencer son el de Microsoft Corporation UEFI CA 2011 (vence el 27 de junio de 2026), que firma los cargadores de arranque de terceros, como Linux Shim, y el de Microsoft Windows Production PCA 2011, que vence el 19 de octubre de 2026 y firma el cargador de arranque de Windows.

El inicio seguro de UEFI es un estándar de seguridad que las VMs protegidas usan para garantizar que solo se ejecute software y firmware confiables durante el proceso de inicio de la VM. Para admitir el inicio seguro en varios sistemas operativos, Microsoft administra los certificados de UEFI y los almacena en las variables de la clave de intercambio de claves (KEK) y la base de datos de firmas permitidas (db) dentro del firmware de la instancia.

Certificados de inicio seguro y fechas de vencimiento

Nombre del certificado Rol Fecha de vencimiento
Microsoft Corporation UEFI CA 2011 Firma bootloaders de terceros, como Linux Shim 27 de junio de 2026
Microsoft Windows Production PCA 2011 Firma el cargador de arranque de Windows 19 de octubre de 2026
Microsoft Corporation KEK CA 2011 Se usa para actualizar la DB y la DBX. 24 de junio de 2026

El vencimiento de este certificado solo te afecta si tu instancia de procesamiento cumple con los siguientes requisitos previos obligatorios:

  1. Fecha de creación: Creaste la instancia de procesamiento antes del 7 de noviembre de 2025 (cuando Compute Engine actualizó los certificados predeterminados de Arranque seguro en el firmware de UEFI) y no la actualizaste.
  2. Estado del inicio seguro: Habilitaste el inicio seguro en la instancia. Google Cloud no habilita el inicio seguro de forma predeterminada cuando creas una instancia de VM protegida.

Las instancias que crees a partir del 7 de noviembre de 2025 ya incluirán los certificados actualizados en sus variables de firmware, siempre que usen una imagen que se base en el conjunto de certificados predeterminado.

Si tu instancia no cumple con ambos requisitos previos, el vencimiento del certificado no la afectará y no deberás realizar ninguna acción.

En este documento, se explica cómo identificar las instancias afectadas y realizar las actualizaciones necesarias.

Google Cloud finalizó el lanzamiento de los nuevos certificados el 7 de noviembre de 2025. Las instancias que crees a partir de esta fecha con imágenes que se basan en el conjunto predeterminado de certificados incluirán los certificados actualizados en sus variables de NVRAM/firmware (db y KEK) y no requerirán ninguna acción adicional. Sin embargo, es posible que algunas instancias que creaste en las semanas anteriores a esta fecha también incluyan los certificados nuevos. Para verificar si tu sistema está actualizado, usa los comandos de la sección Verificación de este documento.

Nota: El vencimiento del certificado de Inicio seguro no afecta lo siguiente:

  • Instancias que no tienen habilitado el inicio seguro Ten en cuenta que, si usas registros de configuración de la plataforma del vTPM (específicamente PCR7) para el sellado de secretos, cualquier actualización de las variables de UEFI o la recreación de la instancia seguirán alterando las mediciones de PCR7 incluso con el arranque seguro inhabilitado, aunque estas configuraciones son muy poco frecuentes.
  • Instancias que ejecutan Container-Optimized OS (COS).
  • Instancias en las que proporcionas tu propia clave de plataforma de arranque seguro (PK) o clave de inscripción de claves (KEK).

En el caso de las instancias de procesamiento creadas antes del 7 de noviembre de 2025 que no tengan los certificados actualizados, sigue la guía de actualización de KEK y de la base de datos para actualizar los certificados. Si, por algún motivo, no puedes hacerlo, considera volver a crear las instancias.

Cómo afecta el vencimiento del certificado de inicio seguro a la VM protegida

Si está habilitada, la VM protegida aplica el inicio seguro con el firmware de UEFI, que mantiene un conjunto de certificados de confianza (en la variable db) para verificar las firmas de los archivos binarios de la secuencia de inicio. Por ejemplo, si una actualización del SO reemplaza un cargador de arranque por uno firmado solo por la CA de UEFI de Microsoft 2023, y el firmware de la instancia de procesamiento no confía en la autoridad de este certificado, falla la verificación del inicio seguro y este detiene el proceso de inicio.

Para obtener más detalles sobre esta transición, consulta la orientación de Microsoft y otros proveedores de SO:

Impacto en el sistema operativo

Si habilitaste el inicio seguro en una instancia de VM protegida creada antes del 7 de noviembre de 2025, te recomendamos que te asegures de que estén instalados los certificados de 2023. De lo contrario, la instancia de procesamiento tendrá problemas de inicio si aplicas una actualización que contenga un cargador de arranque firmado solo por el certificado de CA de UEFI de Microsoft de 2023 (y no firmado de forma dual con el certificado de 2011). Si no tomas ninguna medida, es posible que no puedas aplicar futuras actualizaciones del bootloader o del kernel que contengan archivos binarios firmados solo con el certificado de 2023. Ten en cuenta que, dado que los proveedores de SO planean firmar de forma dual las actualizaciones del cargador de arranque y del shim con los certificados de 2011 y 2023 en el futuro cercano, no se espera que se produzcan fallas de arranque ni bloqueos de actualización de inmediato. En el caso de las instancias de procesamiento creadas antes del 7 de noviembre de 2025, es posible que los clientes de Windows vean el ID de evento 1801 (“Se deben actualizar las claves o la CA de arranque seguro”) en el registro de eventos del sistema si no aplicaron las actualizaciones de certificados.

  • Imágenes públicas proporcionadas por Google: Actualiza los certificados de KEK y de la BD siguiendo la guía de actualización de KEK y de la BD. Como alternativa, considera volver a crear las VMs de ejecución prolongada que se crearon antes del 7 de noviembre de 2025.

  • Imágenes personalizadas o importadas: La gran mayoría de las imágenes personalizadas o importadas dependen de los certificados predeterminados de Arranque seguro. Si no anulaste de forma explícita las variables de arranque seguro db o KEK cuando creaste la imagen, esta usa el conjunto de claves predeterminado y no requiere ninguna acción a nivel de la imagen. Compute Engine proporciona automáticamente los certificados actualizados cuando creas una instancia a partir de cualquier imagen que dependa de estos valores predeterminados.

    Solo debes tomar medidas si definiste de forma explícita variables de arranque seguro db o KEK personalizadas (por ejemplo, para incluir el certificado de un proveedor de seguridad externo junto con los certificados predeterminados de Microsoft) en los metadatos de la imagen durante el proceso de compilación de la imagen. Dado que especificar una variable db o KEK personalizada anula por completo los valores predeterminados (y el sistema ignora las claves públicas predeterminadas), es posible que tus variables personalizadas no tengan los certificados actualizados de "Microsoft UEFI CA 2023" o KEK de 2023. Si la configuración de tu imagen personalizada excluye estos certificados actualizados, debes volver a crear o actualizar tu imagen protegida para incluirlos. Para obtener instrucciones, consulta Crea imágenes personalizadas de VMs protegidas.

Si tienes instancias de procesamiento creadas antes del 7 de noviembre de 2025 con el inicio seguro habilitado, revisa los siguientes requisitos, limitaciones y factores que complican el proceso antes de planificar la ruta de actualización:

  • Requisitos previos a la actualización:
    • Verifica el acceso a la clave de recuperación: Si tus instancias usan FDE (incluido BitLocker en Windows o LUKS en Linux), debes asegurarte de tener acceso a tus claves de recuperación antes de actualizar los certificados o volver a crear las instancias. Si se modifican las variables de la UEFI, se alterarán las mediciones de inicio y se activarán mensajes de recuperación.
    • Administra los secretos del vTPM: Si tus instancias usan registros de configuración de la plataforma del vTPM (específicamente PCR7) para el sellado de secretos, debes desellar o hacer una copia de seguridad de estos secretos antes de realizar la actualización para evitar perder el acceso de forma permanente.
  • Factores y límites que complican la situación:
    • Requisito de orden de actualización: Para evitar errores de verificación de la CA y bucles de inicio del sistema, debes instalar los nuevos certificados db y KEK antes de aplicar nuevas actualizaciones del kernel o de shim.
    • Reversiones de firmware: Si se restablece una instancia a una imagen de máquina heredada capturada antes del 7 de noviembre de 2025, se restablece el firmware anterior y se quita la confianza en los certificados de 2023. Si reviertes la actualización, deberás volver a aplicar las actualizaciones de certificados.

Para obtener un desglose detallado de los cronogramas, los pasos de auditoría y los procesos de migración, revisa las siguientes instrucciones.

Impacto en configuraciones de invitados específicas

Comprende cómo el vencimiento del certificado afecta cada configuración solo si tu instancia cumple con ambos requisitos previos obligatorios (la creaste antes del 7 de noviembre de 2025 y tiene habilitado el Arranque seguro):

  • Sellado de secretos del PCR de vTPM:
    • Cuándo se convierte en un factor: Cuando usas registros de configuración de la plataforma vTPM (específicamente PCR7) para sellar secretos, como claves de desencriptación.
    • Impacto: La actualización de los certificados de inicio seguro (ya sea con la guía de actualización de KEK y db o con la recreación de la instancia a partir de una instantánea de disco) modifica las variables de UEFI, lo que cambia el valor de medición de PCR7 en el próximo inicio. Este cambio evita que el SO invitado o las aplicaciones desprecinten o descifren estos secretos, a menos que primero los desprecintes o hagas una copia de seguridad de ellos antes de la actualización y, luego, los vuelvas a precintar con el nuevo valor de PCR7.
    • Cuando no se ve afectada: Si creaste la VM a partir del 7 de noviembre de 2025 o después de esa fecha, desde una imagen que depende de los certificados predeterminados, no es necesario que actualices los certificados, PCR7 permanece sin cambios y el sellado de secretos se comporta con normalidad.
  • Instancias de procesamiento de Windows que usan BitLocker o el modo seguro virtual (VSM):
    • Cuándo se convierte en un factor: Cuando tus VMs de Windows usan el cifrado de disco completo de BitLocker o VSM, ambos confían en el Inicio seguro de UEFI y en PCR7 para sellar sus claves de encriptación.
    • Impacto: Modificar los certificados de Arranque seguro UEFI (o volver a crear la instancia a partir de una instantánea) cambia las mediciones de arranque de PCR7. En el reinicio posterior, BitLocker detecta el cambio de configuración, no puede liberar la clave automáticamente y se inicia en una pantalla de recuperación de BitLocker que solicita la clave de recuperación.
    • Solución: Debes verificar que tienes disponibles tus claves de recuperación de BitLocker antes de actualizar los certificados o migrar instancias. Luego, sigue las instrucciones en Actualiza la base de datos y la KEK en Windows.
    • Cuando no se ve afectado: El vencimiento del certificado no afecta a las instancias de Windows sin BitLocker o VSM habilitados, ni a las que no tienen habilitado el inicio seguro.
  • VMs de Linux que usan FDE:
    • Cuándo se convierte en un factor: Cuando tus instancias de Linux usan FDE, como LUKS, en el que sellas las claves de desencriptación en los PCR de vTPM (específicamente PCR7).
    • Impacto: La actualización de los certificados de inicio seguro o la recreación de la VM alteran PCR7, lo que impide el desencriptado automático del volumen de inicio. El sistema se detiene durante el arranque y te solicita una frase de contraseña de desencriptación.
    • Solución: Confirma que tienes las frases de contraseña o las claves de recuperación antes de ejecutar las actualizaciones. Desvincula o desella las claves de LUKS del TPM antes de la actualización, y vuelve a vincularlas o sellarlas al nuevo valor de PCR7 después de completar la actualización.
    • Cuando no se ve afectada: El vencimiento del certificado no afecta a las VMs de Linux que no usan FDE ni el descifrado de LUKS sellado con vTPM, o bien a las que no tienen habilitado el inicio seguro.
  • Instancias que revierten a una imagen de máquina anterior a noviembre de 2025:
    • Cuándo se convierte en un factor: Cuando restableces o reviertes una VM a una imagen de máquina capturada antes del 7 de noviembre de 2025 con el arranque seguro habilitado.
    • Impacto: La instancia revertida restablece la configuración del firmware de UEFI anterior y el almacén de certificados que no tiene los certificados de 2023. Esto hace que la instancia sea vulnerable a fallas de inicio futuras después de las actualizaciones posteriores del cargador de arranque, lo que requiere que vuelvas a aplicar las actualizaciones del certificado.
    • Cuando no se ve afectada: Revertir a una imagen de máquina no afecta a la instancia si inhabilitas el arranque seguro o si creaste la imagen de máquina el 7 de noviembre de 2025 o después de esa fecha a partir de una imagen que se basa en los certificados predeterminados.

Identifica las instancias de procesamiento afectadas y planifica la actualización

A lo largo del 2026, te recomendamos que identifiques las instancias de procesamiento afectadas y sigas estos pasos para prepararte para la actualización:

  1. Identifica instancias: Puedes usar el comando gcloud compute instances list para identificar las instancias que tienen habilitado el Arranque seguro y que se crearon antes de la fecha límite:

    gcloud compute instances list \
--filter="creationTimestamp < '2025-11-07' AND shieldedInstanceConfig.enableSecureBoot=true" \
--format="table(name, zone, creationTimestamp, shieldedInstanceConfig.enableSecureBoot:label=SECURE_BOOT)"

  2. Verifica si hay variables personalizadas (opcional): Si usas imágenes personalizadas o importadas, verifica si definen de forma explícita variables personalizadas de db o KEK de inicio seguro (que anulan por completo los valores predeterminados). Si se basan en certificados predeterminados, no requieren ninguna acción a nivel de la imagen:

    • Para verificar una instancia de VM, ejecuta el siguiente comando:

      gcloud compute instances describe INSTANCE_NAME \
    --zone=ZONE \
    --format="yaml(shieldedInstanceInitialState)"

    • Para verificar una imagen de disco de origen, ejecuta el siguiente comando:

      gcloud compute images describe IMAGE_NAME \
    --format="yaml(shieldedInstanceInitialState)"

    Si el resultado está vacío o devuelve null, la instancia o la imagen usan los certificados predeterminados y no requieren ninguna acción a nivel de la imagen.

  3. Garantiza la integridad de los datos: Asegúrate de tener copias de seguridad de datos recientes y acceso a las claves de recuperación de FDE o BitLocker antes de continuar con cualquier cambio.

  4. Actualiza los certificados: Actualiza los certificados de la base de datos y de la KEK siguiendo la guía de actualización de la KEK y la base de datos. Como alternativa, migra a una instancia de procesamiento que crees a partir del 7 de noviembre de 2025, que incluye los certificados de 2023 (siempre que la instancia nueva use una imagen que dependa de los certificados predeterminados), siguiendo las instrucciones en Cómo volver a crear una instancia de procesamiento a partir de una instantánea de disco.

Cómo volver a crear una instancia de procesamiento a partir de una instantánea de disco

Cuando tomas una instantánea de disco y creas una instancia nueva a partir de ella, la nueva instancia de procesamiento hereda un estado de firmware (vTPM/NVRAM) nuevo que confía en los valores predeterminados actualizados y borra los certificados antiguos.

Antes de volver a crear una instancia de procesamiento a partir de una instantánea, asegúrate de que el SO invitado tenga instaladas todas las actualizaciones necesarias (como los KB de Microsoft pertinentes para Windows o el Shim más reciente para las distribuciones de Linux) para confiar en los certificados de 2023.

Puedes usar la siguiente secuencia de comandos de gcloud para administrar esta migración:

  1. Identifica el disco de arranque: Determina el nombre del disco de arranque conectado a tu instancia de procesamiento de origen:

    SOURCE_DISK=$(gcloud compute instances describe SOURCE_INSTANCE_NAME \
    --zone=ZONE \
    --format="value(disks[0].source.basename())")

  2. Crea una instantánea del disco: Toma una instantánea de ese disco de arranque. Para garantizar la integridad de los datos, detén la instancia de procesamiento antes de ejecutar este comando:

    gcloud compute disks snapshot $SOURCE_DISK \
    --snapshot-names="migration-snapshot-$(date +%s)" \
    --zone=ZONE \
    --storage-location=REGION

  3. Crea una instancia de procesamiento nueva: Aprovisiona una instancia de procesamiento nueva con la instantánea como fuente de arranque. Si el inicio seguro está habilitado en la instancia de origen, incluye la marca --shielded-secure-boot para habilitar el inicio seguro en la instancia nueva.

    gcloud compute instances create NEW_INSTANCE_NAME \
    --zone=ZONE \
    --machine-type=MACHINE_TYPE \
    --create-disk=name=NEW_DISK_NAME,source-snapshot=SNAPSHOT_NAME,boot=yes \
    --shielded-secure-boot

Nota: Las instancias aprovisionadas con este enfoque reciben direcciones IP internas y externas nuevas, a menos que se asignen de forma estática y se reasignen específicamente. Los metadatos, las etiquetas y las cuentas de servicio a nivel de la instancia no se replican automáticamente y se deben configurar de forma explícita durante la recreación.

Verificación

Después de actualizar el firmware y el SO de tus instancias de procesamiento, puedes verificar que los certificados de 2023 estén presentes. Si las variables KEK y db muestran que los certificados de 2023 están presentes, tu instancia está actualizada y no es necesario que realices ninguna otra acción.

Linux

Puedes verificar las bases de datos de firmas en Linux con el comando efi-readvar del paquete efitools o, en las distribuciones en las que efitools no está disponible, como RHEL 8/9, con mokutil.

Método 1: Usa efi-readvar

  1. Si efi-readvar no está presente, instala el paquete efitools. Para instalar en Linux, ejecuta el comando correspondiente a tu distribución:

    Debian/Ubuntu

    sudo apt update && sudo apt install efitools

    RHEL/CentOS/Fedora (solo Fedora; efitools no está disponible en los repositorios de RHEL/CentOS)

    sudo yum install efitools

    SLES

    sudo zypper install efitools

  2. Verifica los certificados en las variables KEK y db:

    sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
sudo efi-readvar -v db | grep "UEFI CA 2023"

Método 2: Usa mokutil

En distribuciones como Red Hat Enterprise Linux (RHEL), en las que efitools no está disponible, usa la utilidad mokutil, que se instala de forma predeterminada:

sudo mokutil --kek | grep "KEK 2K CA 2023"
sudo mokutil --db | grep "UEFI CA 2023"

Windows (PowerShell)

Ejecuta lo siguiente en un símbolo del sistema de PowerShell del administrador. Cada comando debería devolver True.

# Check for Microsoft KEK 2K CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

# Check for UEFI CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'UEFI CA 2023'

# Confirm general Secure Boot enrollment state
Confirm-SecureBootUEFI

Soluciona problemas

Si una instancia no se inicia debido a un error de inicio seguro después de junio de 2026, prueba una de las siguientes opciones para recuperarla:

  • Inhabilita temporalmente el inicio seguro: Esto te permite iniciar la instancia para aplicar actualizaciones.

    Nota: Si inhabilitas el inicio seguro, se cambian los valores del PCR, específicamente PCR7, lo que podría afectar el sellado de secretos o la funcionalidad de encriptación de disco.

    Para inhabilitar el arranque seguro, ejecuta el siguiente comando:

    gcloud compute instances update INSTANCE_NAME --no-shielded-secure-boot

    Después de aplicar las actualizaciones necesarias al cargador de arranque o al shim, vuelve a habilitar el inicio seguro:

    gcloud compute instances update INSTANCE_NAME --shielded-secure-boot

  • Restablece desde una copia de seguridad: Restablece la instancia a partir de una imagen de máquina creada antes de que comenzaran los problemas de arranque.

  • Recrear instancia: Recrea la instancia y recupera los datos de una instantánea.

Si sigues teniendo problemas o necesitas ayuda, comunícate con Atención al cliente de Cloud.

Preguntas frecuentes

En esta sección, se proporcionan respuestas a preguntas frecuentes sobre el vencimiento del certificado de arranque seguro de Microsoft.

¿Cuándo vencen los certificados de inicio seguro?

Los certificados de arranque seguro de Microsoft vencerán en 2026. En particular, haz lo siguiente:

  • Los dos certificados más importantes que se acercan al final de su ciclo de vida son el de Microsoft Corporation UEFI CA 2011 (vence en junio de 2026), que firma los cargadores de arranque de terceros, como Linux Shim, y el de Microsoft Windows Production PCA 2011, que vence en octubre de 2026 y firma el cargador de arranque de Windows.

¿A quiénes afecta el vencimiento del certificado?

El vencimiento de este certificado solo te afecta si tu instancia de procesamiento cumple con los siguientes requisitos previos obligatorios:

  1. Creaste la instancia antes del 7 de noviembre de 2025 (cuando Compute Engine actualizó los certificados predeterminados de Arranque seguro en el firmware de UEFI) y no la actualizaste.
  2. Habilitaste el inicio seguro en la instancia.

Las instancias que crees a partir del 7 de noviembre de 2025 no se verán afectadas, siempre y cuando las crees a partir de una imagen que dependa del conjunto de certificados predeterminado.

Si tu instancia cumple con ambos requisitos previos, el vencimiento del certificado afecta las siguientes configuraciones en circunstancias específicas:

  • Sellado secreto del PCR del vTPM: Indica si la instancia usa registros de configuración de la plataforma (PCR) del módulo de plataforma de confianza virtual (vTPM) (específicamente PCR7) para sellar claves de encriptación o secretos.
  • Windows BitLocker / VSM: Si tu instancia de Windows usa encriptación de disco BitLocker o Modo seguro virtual (VSM) con Inicio seguro.
  • FDE de Linux: Si tu instancia de Linux usa FDE que se sella en PCR de vTPM (específicamente PCR7).
  • Instancias de reversión: Si restableces o reviertes la VM a una imagen de máquina que creaste antes del 7 de noviembre de 2025

Para obtener un desglose detallado del impacto y los pasos de corrección para cada una de estas configuraciones, consulta Impacto en configuraciones específicas de invitados.

¿A quiénes no afecta el vencimiento del certificado?

El vencimiento del certificado no te afecta si se cumple alguna de las siguientes condiciones:

  • Inicio seguro inhabilitado: Si el inicio seguro no está habilitado en tu instancia de VM protegida, no valida ni usa los certificados de UEFI que están por vencer. El inicio seguro está inhabilitado de forma predeterminada. Sin embargo, ten en cuenta que, si usas registros de configuración de la plataforma del vTPM (específicamente PCR7) para el sellado de secretos, cualquier actualización de las variables de UEFI o la recreación de la instancia alterarán las mediciones de PCR7 incluso con el arranque seguro inhabilitado, aunque estas configuraciones son muy poco frecuentes.
  • Creada a partir del 7 de noviembre de 2025: Creaste la instancia a partir de esta fecha, por lo que su firmware ya incluye los certificados actualizados de 2023, siempre y cuando la hayas creado a partir de una imagen que se basa en el conjunto de certificados predeterminado.
  • Ejecución de Container-Optimized OS (COS): Estas actualizaciones de certificados no afectan los entornos de COS.
  • Variables personalizadas de PK, KEK o db: Si defines y administras de forma explícita tus propias variables personalizadas de inicio seguro PK, KEK o db sin depender de los certificados predeterminados de UEFI de Microsoft, el vencimiento de los certificados predeterminados no te afectará. Sin embargo, tú eres responsable de actualizar y mantener tus propios certificados.

¿Qué sucede si no realizo ninguna acción?

Si no realizas ninguna acción, la instancia seguirá iniciándose y funcionando con normalidad con sus archivos binarios existentes. Sin embargo, es posible que no puedas aplicar futuras actualizaciones del cargador de arranque o del kernel que contengan archivos binarios firmados solo con el certificado de 2023. Ten en cuenta que, debido a que los proveedores de SO firman de forma dual las actualizaciones del cargador de arranque y del shim con los certificados de 2011 y 2023, no se espera que se produzcan fallas de arranque ni bloqueos de actualización de inmediato.

¿Si no se actualizan los certificados, se evitará que se inicien las instancias de Windows?

No. Si no se corrige el problema, no se impedirá el inicio del sistema Windows. Sin embargo, es posible que veas el ID de evento 1801 ("Se deben actualizar la AC y las claves del arranque seguro") en el registro de eventos del sistema, y no podrás aplicar nuevas actualizaciones de seguridad del kernel o del cargador de arranque que contengan archivos binarios firmados solo con el nuevo certificado de 2023.

¿Qué condiciones específicas provocan fallas de inicio en Linux?

Es posible que se produzca un error de inicio en Linux en las siguientes condiciones específicas:

  • La instancia tiene habilitado el inicio seguro.
  • La variable db de UEFI no se actualiza para confiar en el certificado "Microsoft UEFI CA 2023".
  • El SO actualiza un cargador de arranque (o shim) que depende estrictamente de ese certificado (y no está firmado de forma dual con el certificado de 2011).

Si no aplicas actualizaciones de certificados ni actualizaciones de shim que hagan referencia a los certificados nuevos, tu instancia de Linux seguirá arrancando correctamente.

¿Cómo puedo determinar si mi instancia tiene los certificados actualizados?

Para determinar si tu instancia incluye los nuevos certificados en su firmware, consulta los comandos que se describen en la sección Verificación. Si faltan certificados, puedes actualizarlos siguiendo la guía de actualización de KEK y la base de datos o volver a crear la instancia.

¿El reinicio de una instancia afectada resuelve el problema?

No. Reiniciar una instancia de procesamiento no actualiza sus certificados de arranque seguro, pero la instancia sigue arrancando y funcionando normalmente con sus certificados existentes hasta que se aplique una actualización del cargador de arranque o del kernel que contenga archivos binarios firmados solo con el certificado de 2023. Si reinicias la instancia de procesamiento, esta conservará los certificados anteriores si se creó originalmente antes del 7 de noviembre de 2025. Los certificados forman parte del firmware de la instancia (vTPM/NVRAM). Por lo tanto, debes seguir la guía de actualización de KEK y de la base de datos o volver a crear la instancia para aplicar los certificados nuevos.

¿Cómo debo prepararme para el vencimiento del certificado?

Para prepararte, sigue estos pasos:

  • Identifica: Audita tu uso de VMs protegidas, Inicio seguro, FDE, BitLocker o cualquier software que dependa de los PCR del vTPM.
  • Claves de recuperación y copias de seguridad: Asegúrate de que las claves de recuperación (para FDE/BitLocker) y las copias de seguridad de datos más recientes estén disponibles de inmediato.
  • Administra imágenes: Identifica las imágenes personalizadas heredadas y suspende su uso, o bien asegúrate de que incluyan los certificados nuevos.
  • Actualización o migración: Si deseas actualizar los certificados, consulta la guía de actualización de KEK y de la base de datos. Como alternativa, considera volver a crear las instancias de procesamiento de larga duración que creaste antes del 7 de noviembre de 2025, ya que las instancias nuevas ya incluyen los certificados necesarios (siempre y cuando crees la instancia nueva a partir de una imagen que se base en los certificados predeterminados).

Las instantáneas de disco estándar proporcionan el método más confiable. Una instantánea es una copia a nivel de bloque del disco y no contiene variables de UEFI ni metadatos a nivel de la instancia. Para restablecer la base de datos con una instantánea, haz lo siguiente:

  1. Crea una instantánea del disco de arranque de la instancia.
  2. Crea una instancia de procesamiento nueva y selecciona la instantánea como origen del disco de arranque.

No debes usar imágenes de máquinas, clonación de instancias ni el servicio Backup and DR para esta migración, ya que replican el firmware de la instancia y conservan los certificados antiguos para cualquier instancia de procesamiento de origen creada antes del 7 de noviembre de 2025.

¿Qué debo hacer si mi sistema deja de iniciarse después de junio de 2026?

Si crees que este problema provocó una falla en el inicio, consulta Solución de problemas.

¿Cómo se Google Cloud maneja el vencimiento de los certificados de inicio seguro de Microsoft?

Google Cloud incluyó automáticamente los certificados nuevos para las instancias de procesamiento creadas después del 7 de noviembre de 2025. Solo los clientes que quieran mantener en funcionamiento sus instancias de procesamiento creadas antes del 7 de noviembre de 2025 deberán aplicar una actualización futura, pero recomendamos migrar a una instancia que crees a partir del 7 de noviembre de 2025 (con certificados predeterminados).

¿Qué sigue?