Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Guide d'expiration des certificats Microsoft Secure Boot

Étant donné que plusieurs certificats de démarrage sécurisé Microsoft expirent en 2026, ce document explique comment mettre à jour les instances de VM protégées Compute Engine pour qu'elles fassent confiance aux certificats de démarrage sécurisé Microsoft mis à jour pour le démarrage sécurisé UEFI (Unified Extensible Firmware Interface). Les deux certificats les plus critiques qui arrivent à expiration sont la CA UEFI Microsoft Corporation 2011 (expire le 27 juin 2026), qui signe les chargeurs de démarrage tiers tels que Linux Shim, et la PCA Microsoft Windows Production 2011, qui expire le 19 octobre 2026 et signe le chargeur de démarrage Windows.

Le démarrage sécurisé UEFI est une norme de sécurité utilisée par les VM protégées pour s'assurer que seuls les logiciels et micrologiciels de confiance s'exécutent pendant le processus de démarrage de la VM. Pour prendre en charge le démarrage sécurisé sur différents systèmes d'exploitation, Microsoft gère les certificats UEFI, en les stockant dans les variables Key Exchange Key (KEK) et Allowed Signature Database (db) du micrologiciel de l'instance.

Certificats de démarrage sécurisé et dates d'expiration

Nom du certificat	Rôle	Date d'expiration
Microsoft Corporation UEFI CA 2011	Signe les bootloaders tiers, tels que Linux Shim	27 juin 2026
Microsoft Windows Production PCA 2011	Signe le bootloader Windows	19 octobre 2026
Microsoft Corporation KEK CA 2011	Utilisé pour mettre à jour DB et DBX	24 juin 2026

L'expiration de ce certificat ne vous concerne que si votre instance de calcul remplit les deux conditions préalables obligatoires suivantes :

Date de création : vous avez créé l'instance de calcul avant le 7 novembre 2025 (date à laquelle Compute Engine a mis à jour les certificats de démarrage sécurisé par défaut dans le micrologiciel UEFI) et vous ne l'avez pas mise à jour.
État du démarrage sécurisé : vous avez activé le démarrage sécurisé sur l'instance. Google Cloud n'active pas le démarrage sécurisé par défaut lorsque vous créez une instance de VM protégée.

Les instances que vous créez à partir du 7 novembre 2025 incluent déjà les certificats mis à jour dans leurs variables de micrologiciel, à condition qu'elles utilisent une image qui s'appuie sur l'ensemble de certificats par défaut.

Si votre instance ne répond pas aux deux conditions préalables, l'expiration du certificat ne l'affecte pas et aucune action n'est requise de votre part.

Ce document explique comment identifier les instances concernées et effectuer les mises à jour nécessaires.

Google Cloud a terminé de déployer les nouveaux certificats le 7 novembre 2025. Les instances que vous créez à partir de cette date à partir d'images qui s'appuient sur l'ensemble de certificats par défaut incluent les certificats mis à jour dans leurs variables NVRAM/firmware (db et KEK) et ne nécessitent aucune autre action. Toutefois, certaines instances que vous avez créées au cours des semaines précédant cette date peuvent également inclure les nouveaux certificats. Pour vérifier si votre système est à jour, utilisez les commandes de la section Validation de ce document.

Remarque : L'expiration du certificat de démarrage sécurisé n'a pas d'incidence sur les éléments suivants :

Instances sur lesquelles le démarrage sécurisé n'est pas activé. Notez que si vous utilisez des registres de configuration de plate-forme vTPM (en particulier PCR7) pour le scellage secret, toute mise à jour des variables UEFI ou recréation de l'instance modifiera toujours les mesures PCR7, même si le démarrage sécurisé est désactivé. Toutefois, de telles configurations sont très rares.
Instances exécutant Container-Optimized OS (COS).
Cas où vous fournissez votre propre clé de plate-forme Secure Boot (PK) ou clé d'enregistrement de clé (KEK).

Pour les instances de calcul créées avant le 7 novembre 2025 et qui ne disposent pas des certificats mis à jour, suivez le guide de mise à jour du KEK et de la base de données pour mettre à jour les certificats. Si, pour une raison quelconque, vous ne pouvez pas le faire, envisagez de recréer vos instances.

Impact de l'expiration du certificat de démarrage sécurisé sur les VM protégées

Si elle est activée, la VM protégée applique le démarrage sécurisé à l'aide du micrologiciel UEFI, qui conserve un ensemble de certificats approuvés (dans la variable db) pour vérifier les signatures des binaires de la séquence de démarrage. Par exemple, si une mise à jour de l'OS remplace un bootloader par un bootloader signé uniquement par Microsoft UEFI CA 2023, et que le micrologiciel de l'instance de calcul ne fait pas confiance à l'autorité de ce certificat, la validation du démarrage sécurisé échoue et le démarrage sécurisé arrête le processus de démarrage.

Pour en savoir plus sur cette transition, consultez les conseils de Microsoft et d'autres fournisseurs d'OS :

Impact sur le système d'exploitation

Si vous avez activé le démarrage sécurisé sur une instance de VM protégée créée avant le 7 novembre 2025, nous vous recommandons de vous assurer que les certificats de 2023 sont installés. Sinon, l'instance de calcul rencontrera des problèmes de démarrage si vous appliquez une mise à jour contenant un bootloader signé uniquement par le certificat Microsoft UEFI CA 2023 (et non doublement signé avec le certificat de 2011). Si vous ne faites rien, vous risquez de ne pas pouvoir appliquer les futures mises à jour du bootloader ou du noyau contenant des binaires signés uniquement avec le certificat 2023. Notez que, comme les fournisseurs d'OS prévoient de doublement signer les mises à jour du bootloader et du shim avec les certificats de 2011 et de 2023 pour l'avenir prévisible, les échecs de démarrage ou les blocages de mise à jour ne devraient pas se produire immédiatement. Pour les instances de calcul créées avant le 7 novembre 2025 : les clients Windows peuvent voir l'ID d'événement 1801 ("Les clés/CA de démarrage sécurisé doivent être mises à jour") dans le journal des événements système s'ils n'ont pas appliqué les mises à jour des certificats.

Images publiques fournies par Google : mettez à jour les certificats DB et KEK en suivant le guide de mise à jour de KEK et de la base de données. Vous pouvez également recréer les VM de longue durée créées avant le 7 novembre 2025.
Images personnalisées ou importées : la grande majorité des images personnalisées ou importées s'appuient sur des certificats Secure Boot par défaut. Si vous n'avez pas explicitement remplacé les variables de démarrage sécurisé db ou KEK lorsque vous avez créé l'image, celle-ci utilise l'ensemble de clés par défaut et aucune action n'est requise au niveau de l'image. Compute Engine fournit automatiquement les certificats mis à jour lorsque vous créez une instance à partir d'une image qui s'appuie sur ces valeurs par défaut.

Vous n'avez besoin d'effectuer une action que si vous avez défini explicitement des variables Secure Boot db ou KEK personnalisées (par exemple, pour inclure le certificat d'un fournisseur de sécurité tiers en plus des certificats Microsoft par défaut) dans les métadonnées de l'image lors du processus de création de l'image. Étant donné que la spécification d'une variable db ou KEK personnalisée remplace complètement les valeurs par défaut (et que le système ignore les clés publiques par défaut), vos variables personnalisées peuvent ne pas contenir les certificats "Microsoft UEFI CA 2023" ou KEK 2023 mis à jour. Si la configuration de votre image personnalisée exclut ces certificats mis à jour, vous devez recréer ou mettre à jour votre image protégée pour les inclure. Pour obtenir des instructions, consultez Créer des images de VM protégées personnalisées.

Actions recommandées

Si vous avez créé des instances de calcul avant le 7 novembre 2025 avec le démarrage sécurisé activé, consultez les exigences, les limites et les facteurs de complication suivants avant de planifier votre chemin de mise à jour :

Conditions requises avant la mise à jour :
- Vérifiez l'accès aux clés de récupération : si vos instances utilisent le chiffrement complet du disque (y compris BitLocker sur Windows ou LUKS sur Linux), vous devez vous assurer d'avoir accès à vos clés de récupération avant de mettre à jour les certificats ou de recréer les instances. La modification des variables UEFI altère les mesures de démarrage et déclenche des invites de récupération.
- Gérez les secrets vTPM : si vos instances utilisent des registres de configuration de plate-forme vTPM (en particulier PCR7) pour le scellage secret, vous devez desceller ou sauvegarder ces secrets avant la mise à jour pour éviter de perdre définitivement l'accès.
Facteurs et limites de complexité :
- Exigence concernant l'ordre des mises à jour : pour éviter les échecs de validation de l'autorité de certification et les boucles de démarrage du système, vous devez installer les nouveaux certificats db et KEK avant d'appliquer les nouvelles mises à jour du noyau ou du shim.
- Rollbacks du micrologiciel : la restauration d'une instance vers une ancienne image de machine capturée avant le 7 novembre 2025 restaure l'ancien micrologiciel et supprime la confiance pour les certificats de 2023. Si vous effectuez un rollback, vous devez appliquer à nouveau les mises à jour des certificats.

Pour obtenir des informations détaillées sur les délais, les étapes d'audit et les processus de migration, consultez les instructions suivantes.

Impact sur des configurations d'invité spécifiques

Comprenez comment l'expiration du certificat affecte chaque configuration uniquement si votre instance répond aux deux prérequis obligatoires (vous l'avez créée avant le 7 novembre 2025 et le démarrage sécurisé y est activé) :

Scellement secret PCR vTPM :
- Quand cela devient-il un facteur ? Lorsque vous utilisez les registres de configuration de la plate-forme vTPM (en particulier PCR7) pour sceller des secrets, tels que des clés de déchiffrement.
- Impact : la mise à jour des certificats Secure Boot (à l'aide du guide de mise à jour de KEK et db ou en recréant l'instance à partir d'un instantané de disque) modifie les variables UEFI, ce qui change la valeur de mesure PCR7 au prochain démarrage. Cette modification empêche l'OS invité ou les applications de desceller ou de déchiffrer ces secrets, sauf si vous les descellez ou les sauvegardez avant la mise à jour, puis les scellez à nouveau avec la nouvelle valeur PCR7.
- Lorsque vous n'êtes pas concerné : si vous avez créé la VM le 7 novembre 2025 ou après, à partir d'une image reposant sur les certificats par défaut, vous n'avez pas besoin de mettre à jour les certificats. PCR7 reste inchangé et le scellement de secrets se comporte normalement.
Instances de calcul Windows utilisant BitLocker ou le mode sécurisé virtuel (VSM) :
- Quand cela devient un facteur : lorsque vos VM Windows utilisent le chiffrement complet du disque BitLocker ou VSM, qui font tous deux confiance au démarrage sécurisé UEFI et à PCR7 pour sceller leurs clés de chiffrement.
- Impact : la modification des certificats de démarrage sécurisé UEFI ou la recréation de l'instance à partir d'un instantané modifient les mesures de démarrage PCR7. Lors du redémarrage suivant, BitLocker détecte la modification de la configuration, ne parvient pas à libérer automatiquement la clé et démarre sur un écran de récupération BitLocker qui demande la clé de récupération.
- Solution : Vous devez vérifier que vous disposez de vos clés de récupération BitLocker avant de mettre à jour les certificats ou de migrer les instances. Ensuite, suivez les instructions de la section Mettre à jour la base de données et la KEK sur Windows.
- Lorsque vous n'êtes pas concerné : l'expiration du certificat n'a aucune incidence sur les instances Windows sans BitLocker ni VSM activés, ni sur celles sans démarrage sécurisé activé.
VM Linux utilisant le FDE :
- Quand cela devient un facteur : lorsque vos instances Linux utilisent le chiffrement complet du disque (FDE), comme LUKS, où vous scellez les clés de déchiffrement aux PCR vTPM (plus précisément PCR7).
- Impact : la mise à jour des certificats de démarrage sécurisé ou la recréation de la VM modifient PCR7, ce qui empêche le déchiffrement automatique du volume de démarrage. Le système s'arrête pendant le démarrage et vous demande une phrase secrète de déchiffrement.
- Correction : Vérifiez que vous disposez des clés ou des phrases secrètes de récupération avant d'exécuter les mises à jour. Dissociez ou descelez les clés LUKS du module TPM avant la mise à jour, puis associez-les ou scellez-les à nouveau à la nouvelle valeur PCR7 après la mise à jour.
- Lorsque vous n'êtes pas concerné : l'expiration du certificat n'affecte pas les VM Linux qui n'utilisent pas le chiffrement complet du disque ni le déchiffrement LUKS scellé par vTPM, ni celles sur lesquelles le démarrage sécurisé n'est pas activé.
Instances qui effectuent un rollback vers une image système antérieure à novembre 2025 :
- Quand cela devient un facteur : lorsque vous restaurez ou effectuez un rollback d'une VM vers une image de machine capturée avant le 7 novembre 2025, avec le démarrage sécurisé activé.
- Impact : l'instance restaurée rétablit l'ancienne configuration du micrologiciel UEFI et l'ancien magasin de certificats, qui ne contiennent pas les certificats de 2023. L'instance est alors vulnérable aux futurs échecs de démarrage après les mises à jour ultérieures du bootloader, ce qui vous oblige à appliquer à nouveau les mises à jour des certificats.
- Lorsque l'instance n'est pas concernée : le rétablissement d'une image système n'a aucune incidence sur l'instance si vous désactivez le démarrage sécurisé ou si vous avez créé l'image système le 7 novembre 2025 ou après, à partir d'une image reposant sur les certificats par défaut.

Identifier les instances de calcul concernées et planifier la mise à jour

Tout au long de l'année 2026, nous vous recommandons d'identifier les instances de calcul concernées et de suivre les étapes ci-dessous pour vous préparer à la mise à jour :

Identifier les instances : vous pouvez utiliser la commande gcloud compute instances list pour identifier les instances pour lesquelles le démarrage sécurisé est activé et qui ont été créées avant la date limite :

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

Recherchez les variables personnalisées (facultatif) : si vous utilisez des images personnalisées ou importées, vérifiez si elles définissent explicitement des variables de démarrage sécurisé db ou KEK personnalisées (qui remplacent complètement les valeurs par défaut). Si elles s'appuient sur des certificats par défaut, aucune action n'est requise au niveau de l'image :
- Pour vérifier une instance de VM, exécutez la commande suivante :
```
gcloud compute instances describe INSTANCE_NAME \
    --zone=ZONE \
    --format="yaml(shieldedInstanceInitialState)"
```
- Pour vérifier une image disque source, exécutez la commande suivante :
```
gcloud compute images describe IMAGE_NAME \
    --format="yaml(shieldedInstanceInitialState)"
```
Si le résultat est vide ou renvoie null, l'instance ou l'image utilise les certificats par défaut et aucune action n'est requise au niveau de l'image.
Assurez-vous de l'intégrité des données : assurez-vous d'avoir des sauvegardes de données récentes et d'avoir accès aux clés de récupération FDE ou BitLocker avant de procéder à toute modification.
Mettez à jour les certificats : mettez à jour les certificats de la base de données et KEK en suivant le guide de mise à jour de KEK et de la base de données. Vous pouvez également migrer vers une instance de calcul que vous créez le 7 novembre 2025 ou après, qui inclut les certificats de 2023 (à condition que la nouvelle instance utilise une image qui s'appuie sur les certificats par défaut), en suivant les instructions de la section Recréer une instance de calcul à partir d'un instantané de disque.

Recréer une instance de calcul à partir d'un instantané de disque

Lorsque vous prenez un instantané de disque et que vous créez une instance à partir de celui-ci, la nouvelle instance de calcul hérite d'un état de micrologiciel (vTPM/NVRAM) vierge qui fait confiance aux paramètres par défaut mis à jour et efface les anciens certificats.

Avant de recréer une instance de calcul à partir d'un instantané, assurez-vous que l'OS invité a installé toutes les mises à jour nécessaires (par exemple, les articles de la base de connaissances Microsoft pertinents pour Windows ou le dernier shim pour les distributions Linux) pour faire confiance aux certificats de 2023.

Vous pouvez utiliser la séquence de commandes gcloud suivante pour gérer cette migration :

Identifiez le disque de démarrage : déterminez le nom du disque de démarrage associé à votre instance de calcul source :

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

Créez un instantané de disque : prenez un instantané de ce disque de démarrage. Pour une intégrité optimale des données, arrêtez l'instance de calcul avant d'exécuter cette commande :
```
gcloud compute disks snapshot $SOURCE_DISK \
    --snapshot-names="migration-snapshot-$(date +%s)" \
    --zone=ZONE \
    --storage-location=REGION
```
Créez une instance de calcul : provisionnez une nouvelle instance de calcul en utilisant l'instantané comme source de démarrage. Si le démarrage sécurisé est activé sur l'instance source, incluez l'indicateur --shielded-secure-boot pour l'activer sur la nouvelle instance.
```
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
```

Remarque : Les instances provisionnées à l'aide de cette approche reçoivent de nouvelles adresses IP internes et externes, sauf si elles sont attribuées de manière statique et spécifiquement réattribuées. Les métadonnées, les tags et les comptes de service au niveau de l'instance ne sont pas répliqués automatiquement et doivent être configurés de manière explicite lors de la recréation.

Validation

Après avoir mis à jour le micrologiciel et l'OS de vos instances de calcul, vous pouvez vérifier que les certificats de 2023 sont présents. Si les variables KEK et db indiquent que les certificats de 2023 sont présents, votre instance est à jour et aucune autre action n'est requise.

Linux

Vous pouvez vérifier les bases de données de signatures sur Linux en utilisant la commande efi-readvar du package efitools ou (sur les distributions où efitools n'est pas disponible, comme RHEL 8/9) en utilisant mokutil.

Méthode 1 : Utiliser `efi-readvar`

Si efi-readvar n'est pas présent, installez le package efitools. Pour l'installer sur Linux, exécutez la commande correspondant à votre distribution :

Debian/Ubuntu
```
sudo apt update && sudo apt install efitools
```
RHEL/CentOS/Fedora (Fedora uniquement ; efitools n'est pas disponible dans les dépôts RHEL/CentOS)
```
sudo yum install efitools
```
SLES
```
sudo zypper install efitools
```

Recherchez les certificats dans les variables KEK et db :

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

Méthode 2 : Utiliser `mokutil`

Sur les distributions telles que Red Hat Enterprise Linux (RHEL) où efitools n'est pas disponible, utilisez l'utilitaire mokutil, qui est installé par défaut :

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

Windows (PowerShell)

Exécutez les commandes suivantes dans une invite PowerShell administrateur. Chaque commande doit renvoyer 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

Dépannage

Si une instance ne parvient pas à démarrer en raison d'une erreur de démarrage sécurisé après juin 2026, essayez l'une des options suivantes pour la récupérer :

Désactivez temporairement le démarrage sécurisé : cela vous permet de démarrer l'instance pour appliquer les mises à jour.

Remarque : La désactivation du démarrage sécurisé modifie les valeurs PCR, en particulier PCR7, ce qui peut affecter la fonctionnalité de scellage secret ou de chiffrement de disque.

Pour désactiver le démarrage sécurisé, exécutez la commande suivante :
```
gcloud compute instances update INSTANCE_NAME --no-shielded-secure-boot
```
Après avoir appliqué les mises à jour nécessaires au bootloader/shim, réactivez le démarrage sécurisé :
```
gcloud compute instances update INSTANCE_NAME --shielded-secure-boot
```
Restaurer à partir d'une sauvegarde : restaurez l'instance à partir d'une image de machine créée avant le début des problèmes de démarrage.
Recréer l'instance : recréez l'instance et récupérez les données à partir d'un instantané.

Si vous continuez à rencontrer des problèmes ou si vous avez besoin d'aide, contactez Cloud Customer Care.

Questions fréquentes (FAQ)

Cette section répond aux questions fréquentes sur l'expiration du certificat Microsoft Secure Boot.

Quand les certificats de démarrage sécurisé expirent-ils ?

Les certificats de démarrage sécurisé de Microsoft expirent en 2026. Plus spécifiquement :

Les deux certificats les plus critiques qui arrivent en fin de vie sont la CA UEFI Microsoft Corporation 2011 (qui expire en juin 2026), qui signe les chargeurs de démarrage tiers tels que Linux Shim, et la PCA Microsoft Windows Production 2011, qui expire en octobre 2026 et signe le chargeur de démarrage Windows.

Qui est concerné par l'expiration du certificat ?

L'expiration de ce certificat ne vous concerne que si votre instance de calcul remplit les deux conditions préalables obligatoires suivantes :

Vous avez créé l'instance avant le 7 novembre 2025, date à laquelle Compute Engine a mis à jour les certificats de démarrage sécurisé par défaut dans le micrologiciel UEFI, et vous ne l'avez pas mise à jour.
Vous avez activé le démarrage sécurisé sur l'instance.

Les instances que vous créez à partir du 7 novembre 2025 ne sont pas concernées, à condition que vous les créiez à partir d'une image qui repose sur l'ensemble de certificats par défaut.

Si votre instance remplit les deux conditions préalables, l'expiration du certificat affecte les configurations suivantes dans des circonstances spécifiques :

Scellement secret PCR vTPM : si l'instance utilise les registres de configuration de plate-forme (PCR) du module de plate-forme sécurisée virtuelle (vTPM), en particulier PCR7, pour sceller les clés de chiffrement ou les secrets.
Windows BitLocker / VSM : si votre instance Windows utilise le chiffrement de disque BitLocker ou le mode sécurisé virtuel (VSM) avec le démarrage sécurisé.
FDE Linux : si votre instance Linux utilise le FDE que vous scellez aux PCR vTPM (plus précisément PCR7).
Instances de rollback : si vous restaurez ou effectuez un rollback de la VM à une image de machine que vous avez créée avant le 7 novembre 2025.

Pour obtenir une analyse détaillée de l'impact et des étapes de correction pour chacune de ces configurations, consultez Impact sur des configurations invitées spécifiques.

Qui n'est pas concerné par l'expiration du certificat ?

L'expiration du certificat ne vous concerne pas si l'une des conditions suivantes est remplie :

Le démarrage sécurisé est désactivé : si le démarrage sécurisé n'est pas activé sur votre instance de VM protégée, il ne valide ni n'utilise les certificats UEFI qui expirent. Le démarrage sécurisé est désactivé par défaut. Toutefois, notez que si vous utilisez des registres de configuration de plate-forme vTPM (en particulier PCR7) pour le scellement secret, toute mise à jour des variables UEFI ou recréation de l'instance modifiera toujours les mesures PCR7, même si le démarrage sécurisé est désactivé. Toutefois, de telles configurations sont très rares.
Créée le 7 novembre 2025 ou après : vous avez créé l'instance à cette date ou après. Son micrologiciel inclut donc déjà les certificats mis à jour de 2023, à condition que vous l'ayez créée à partir d'une image qui s'appuie sur l'ensemble de certificats par défaut.
Vous exécutez Container-Optimized OS (COS) : ces mises à jour de certificats n'affectent pas les environnements COS.
Variables PK, KEK ou db personnalisées : si vous définissez et gérez explicitement vos propres variables PK, KEK ou db de démarrage sécurisé personnalisé sans vous appuyer sur les certificats UEFI Microsoft par défaut, l'expiration des certificats par défaut ne vous affecte pas. Toutefois, vous êtes responsable de la mise à jour et de la gestion de vos propres certificats.

Que se passera-t-il si je ne fais rien ?

Si vous ne faites rien, votre instance continue de démarrer et de fonctionner normalement avec ses binaires existants. Toutefois, il est possible que vous ne puissiez pas appliquer les futures mises à jour du bootloader ou du noyau contenant des binaires signés uniquement avec le certificat de 2023. Notez que les fournisseurs d'OS doublement signent les mises à jour du bootloader et du shim avec les certificats de 2011 et de 2023. Par conséquent, les échecs de démarrage ou les blocages de mise à jour ne devraient pas se produire immédiatement.

Si je ne mets pas à jour les certificats, les instances Windows pourront-elles démarrer ?

Non. Si vous ne corrigez pas le problème, le système Windows ne sera pas empêché de démarrer. Toutefois, vous pouvez voir l'ID d'événement 1801 ("Les clés/CA de démarrage sécurisé doivent être mises à jour") dans le journal des événements système, et vous ne pourrez pas appliquer les nouvelles mises à jour de sécurité du noyau ou du bootloader contenant des binaires signés uniquement avec le nouveau certificat de 2023.

Quelles conditions spécifiques déclenchent des échecs de démarrage sur Linux ?

Un échec du démarrage peut se produire sur Linux dans des conditions spécifiques :

Le démarrage sécurisé est activé pour l'instance.
La variable UEFI db n'est pas mise à jour pour approuver le certificat "Microsoft UEFI CA 2023".
L'OS met à jour un bootloader (ou shim) qui repose strictement sur ce certificat (et n'est pas doublement signé avec le certificat de 2011).

Si vous n'appliquez pas les mises à jour de certificat ni les mises à jour de shim qui font référence aux nouveaux certificats, votre instance Linux continuera de démarrer correctement.

Comment savoir si mon instance dispose des certificats mis à jour ?

Pour déterminer si votre instance inclut les nouveaux certificats dans son micrologiciel, reportez-vous aux commandes décrites dans la section Validation. Si des certificats sont manquants, vous pouvez les mettre à jour en suivant le guide de mise à jour de la clé de chiffrement de clé et de la base de données, ou recréer l'instance.

Le redémarrage ou le reboot d'une instance concernée permet-il de résoudre le problème ?

Non. Le redémarrage d'une instance de calcul ne met pas à jour ses certificats de démarrage sécurisé. Toutefois, l'instance continue de démarrer et de fonctionner normalement avec ses certificats existants jusqu'à ce qu'une mise à jour du bootloader ou du noyau soit appliquée et contienne des binaires signés uniquement avec le certificat de 2023. Si vous redémarrez l'instance de calcul, elle conserve les anciens certificats si elle a été créée avant le 7 novembre 2025. Les certificats font partie du micrologiciel de l'instance (vTPM/NVRAM). Vous devez donc suivre le guide de mise à jour de la clé KEK et de la base de données ou recréer l'instance pour appliquer les nouveaux certificats.

Comment dois-je me préparer à l'expiration du certificat ?

Pour vous préparer, procédez comme suit :

Identifier : auditez votre utilisation des VM protégées, du démarrage sécurisé, du FDE, de BitLocker ou de tout logiciel qui s'appuie sur les PCR vTPM.
Clés de récupération et sauvegardes : assurez-vous que les clés de récupération (pour FDE/BitLocker) et les dernières sauvegardes de données sont rapidement disponibles.
Gérez les images : identifiez les anciennes images personnalisées et arrêtez de les utiliser, ou assurez-vous qu'elles incluent les nouveaux certificats.
Mettre à jour ou migrer : si vous souhaitez mettre à jour des certificats, consultez le guide de mise à jour des clés de chiffrement de clé et de la base de données. Vous pouvez également recréer les instances de calcul de longue durée que vous avez créées avant le 7 novembre 2025, car les nouvelles instances incluent déjà les certificats nécessaires (à condition de créer la nouvelle instance à partir d'une image qui s'appuie sur les certificats par défaut).

Quelles sont les méthodes recommandées pour recréer ou migrer les instances concernées ?

Les instantanés de disque standards constituent la méthode la plus fiable. Un instantané est une copie au niveau du bloc du disque. Il ne contient aucune variable UEFI ni métadonnée au niveau de l'instance. Pour effectuer une restauration à l'aide d'un instantané, procédez comme suit :

Créez un instantané du disque de démarrage de l'instance.
Créez une instance de calcul et sélectionnez l'instantané comme source du disque de démarrage.

Vous ne devez pas utiliser d'images système, de clonage d'instances ni le service Backup and DR pour cette migration, car ils répliquent le micrologiciel de l'instance et conservent les anciens certificats pour toute instance de calcul source créée avant le 7 novembre 2025.

Que dois-je faire si mon système cesse de démarrer après juin 2026 ?

Si vous pensez que ce problème a entraîné un échec du démarrage, consultez la section Dépannage.

Comment Google Cloud gère-t-il l'expiration des certificats Microsoft Secure Boot ?

Google Cloud inclut automatiquement les nouveaux certificats pour les instances de calcul créées après le 7 novembre 2025. Seuls les clients qui souhaitent continuer à exécuter leurs instances de calcul créées avant le 7 novembre 2025 devront peut-être appliquer une future mise à jour. Toutefois, nous vous recommandons de migrer vers une instance que vous créez le 7 novembre 2025 ou après (en vous appuyant sur les certificats par défaut).

Étapes suivantes

En savoir plus sur les VM protégées
Découvrez comment modifier les options de VM protégée.
En savoir plus sur le démarrage sécurisé

Guide d'expiration des certificats Microsoft Secure Boot Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.