Ce document explique comment mettre à jour les instances de VM protégées Compute Engine afin qu'elles approuvent les certificats de démarrage sécurisé Microsoft mis à jour pour le démarrage sécurisé UEFI (Unified Extensible Firmware Interface).
Le démarrage sécurisé UEFI est une norme de sécurité que les VM protégées utilisent pour s'assurer que seuls les logiciels et micrologiciels approuvés 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 suivants.
Expiration des certificats de démarrage sécurisé
| Nom du certificat | Rôle | Date d'expiration |
|---|---|---|
| Microsoft Corporation UEFI CA 2011 | Signe les bootloaders tiers (par exemple, Linux Shim) | 27 juin 2026 |
| Microsoft Windows Production PCA 2011 | Signe le bootloader Windows | 19 octobre 2026 |
| Microsoft Corporation KEK CA 2011 | Permet de mettre à jour les bases de données DB et DBX | 24 juin 2026 |
Pour éviter tout problème de démarrage, si vous utilisez le démarrage sécurisé sur des instances Compute Engine créées avant le 7 novembre 2025, vous devez vous assurer que les certificats mis à jour sont installés sur vos instances. Cette mise à jour est tout aussi essentielle pour les instances de calcul qui utilisent un logiciel de chiffrement complet du disque, y compris BitLocker, ou le scellement de secrets dans les registres de configuration de plate-forme (PCR) vTPM. Ce guide explique comment identifier les instances concernées et effectuer les mises à jour nécessaires.
Les instances de calcul créées à partir du 7 novembre 2025 incluent les certificats mis à jour et ne nécessitent aucune autre action. De plus, l'expiration du certificat de démarrage sécurisé n'affecte pas les éléments suivants :
- Les instances qui n'utilisent pas les registres de configuration de plate-forme (PCR) vTPM pour le scellement de secrets et pour lesquelles le démarrage sécurisé n'est pas activé. Le démarrage sécurisé n'est pas activé par défaut lorsque vous créez une instance de VM protégée.
- Les instances exécutant Container-Optimized OS (COS).
- Les instances pour lesquelles vous fournissez votre propre clé de plate-forme (PK) ou clé d'inscription (KEK) de démarrage sécurisé.
Pour les instances de calcul créées avant le 7 novembre 2025, nous vous recommandons principalement de les migrer vers de nouvelles instances créées à partir de cette date. Pour les instances de calcul que vous ne pouvez pas recréer, Google prévoit de fournir des instructions de mise à jour manuelle dans ce document lorsqu'elles seront disponibles.
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 gère 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 du système d'exploitation remplace un bootloader par un bootloader signé uniquement par Microsoft UEFI CA 2023 et que le micrologiciel de l'instance de calcul n'approuve pas cette autorité de certification, la vérification 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 de systèmes d'exploitation :
- Expiration du certificat de démarrage sécurisé Windows et mises à jour de l'autorité de certification – Support Microsoft
- Modifications du certificat de démarrage sécurisé en 2026 : conseils pour les environnements RHEL – Portail client Red Hat
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, vous devez vous assurer que le système d'exploitation invité approuve le certificat Microsoft UEFI CA 2023. Si vous n'installez pas les nouveaux certificats, l'instance de calcul peut rencontrer des problèmes de démarrage après une mise à jour contenant un bootloader signé uniquement par le certificat 2023. Si vous ne faites rien, vous ne pourrez peut-être pas appliquer de nouvelles mises à jour du bootloader ou du noyau contenant des binaires signés uniquement avec le certificat 2023, ce qui pourrait rendre les systèmes plus vulnérables à certaines attaques. Pour les instances de calcul créées avant le 7 novembre 2025, si vous n'appliquez pas les mises à jour de certificat avant mi-2026, les clients Windows peuvent voir l'ID d'événement 1801 ("Secure Boot CA/keys need to be updated") dans le journal des événements système.
- Images publiques fournies par Google : nous vous recommandons de recréer l'instance de calcul. La recréation de l'instance garantit qu'elle utilise par défaut le micrologiciel, les certificats et la configuration du système d'exploitation les plus récents.
- Mise à jour manuelle : si vous ne pouvez pas recréer l'instance, vous ne pouvez pas mettre à jour le micrologiciel de l'instance avec de nouveaux certificats. Vous devez attendre que Google fournisse les instructions de mise à jour manuelle.
- Images personnalisées ou importées : vous devez vous assurer que vos images approuvent le certificat Microsoft UEFI CA 2023. Pour vous en assurer, recréez vos images personnalisées à l'aide d'une image de base fournie par Google ou déployez manuellement les certificats appropriés.
Actions requises
Si vous disposez d'instances de calcul créées avant le 7 novembre 2025 pour lesquelles le démarrage sécurisé est activé, ou si elles utilisent un logiciel de chiffrement complet du disque (y compris BitLocker sous Windows et d'autres logiciels de chiffrement complet du disque sous Linux), le mode sécurisé virtuel (VSM) sous Windows ou le scellement de secrets dans les registres de configuration de plate-forme (PCR) vTPM, vous devez effectuer les actions décrites dans les sections suivantes. Ces conseils s'appliquent également si vous restaurez une image de machine antérieure au 7 novembre 2025.
Important : Si vous utilisez un logiciel de chiffrement complet du disque, y compris BitLocker, assurez-vous d'avoir accès à vos clés de récupération avant d'apporter des modifications.
Identifier les instances de calcul concernées et planifier la mise à jour
D'ici le 24 juin 2026, nous vous recommandons d'identifier les instances de calcul concernées et de suivre les étapes ci-dessous pour préparer la mise à jour :
Identifier les instances : vous pouvez utiliser la
gcloud compute instances listcommande 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)"Assurer l'intégrité des données : assurez-vous de disposer de sauvegardes de données récentes et d'avoir accès à toutes les clés de récupération de chiffrement complet du disque ou BitLocker avant de procéder à des modifications.
Recommandation : migrez vers une instance de calcul créée à partir du 7 novembre 2025, qui inclut les certificats nécessaires.
Instructions de mise à jour manuelle : Google prévoit de fournir des instructions pour mettre à jour manuellement les certificats sur les instances de longue durée sur cette page une fois les tests terminés et les commandes nécessaires disponibles. Pour le moment, Google ne recommande pas de mettre à niveau manuellement les certificats
dbouKEK. Attendez des instructions supplémentaires.
Validation
Après avoir mis à jour le micrologiciel et le système d'exploitation de vos instances de calcul, vous pouvez vérifier que les certificats 2023 sont présents.
Linux
Si
efi-readvarn'est pas présent, installez le packageefitools. Pour l'installer sur Linux, exécutez la commande correspondant à votre distribution :Debian/Ubuntu
sudo apt update && sudo apt install efitoolsRHEL/CentOS/Fedora
sudo yum install efitoolsSLES
sudo zypper install efitoolsRecherchez les certificats dans les variables
KEKetdb:
sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
sudo efi-readvar -v db | grep "UEFI CA 2023"
Windows (PowerShell)
Exécutez les commandes suivantes dans une invite PowerShell d'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'
Dépannage
Si une instance ne parvient pas à démarrer en raison d'une erreur de démarrage sécurisé après juin 2026, vous pouvez essayer l'une des options suivantes pour la récupérer :
Désactiver 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 le scellement de secrets ou la fonctionnalité de chiffrement du disque.Pour désactiver le démarrage sécurisé, exécutez la commande suivante :
gcloud compute instances update INSTANCE_NAME --no-shielded-secure-bootUne fois l'instance démarrée, appliquez les mises à jour requises du système d'exploitation et des composants de démarrage, puis réactivez le démarrage sécurisé :
gcloud compute instances update INSTANCE_NAME --shielded-secure-bootRestaurer à 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 rencontrez toujours des problèmes ou si vous avez besoin d'aide, contactez Cloud Customer Care.
Questions fréquentes (FAQ)
Cette section fournit des réponses aux questions fréquentes sur l'expiration du certificat de démarrage sécurisé Microsoft.
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 Microsoft Corporation UEFI CA 2011 (expire en juin 2026), qui signe les bootloaders tiers (comme Linux Shim), et Microsoft Windows Production PCA 2011 (expire en octobre 2026), qui signe le bootloader Windows.
L'expiration affecte-t-elle les clients Windows et Linux ?
Oui, l'expiration affecte les clients Windows et Linux.
Qui est concerné par l'expiration du certificat ?
Ce problème ne concerne peut-être que les clients disposant d'instances de calcul de longue durée créées avant le 7 novembre 2025. Les instances concernées incluent les suivantes :
- Les VM Linux et Windows pour lesquelles le démarrage sécurisé est activé.
- Toute instance utilisant les registres de configuration de plate-forme (PCR) vTPM pour le scellement de secrets.
- Les instances de calcul Windows qui utilisent le chiffrement de disque (BitLocker) ou le mode sécurisé virtuel (VSM).
- Les VM Linux qui utilisent le chiffrement complet du disque.
- Les instances qui restaurent une image de machine antérieure à novembre 2025.
Qui n'est pas concerné par l'expiration du certificat ?
Vous n'êtes pas concerné si vous appartenez à l'une des catégories suivantes :
- Vous n'utilisez pas le démarrage sécurisé, le scellement de secrets dans les PCR vTPM ni le chiffrement complet du disque (y compris BitLocker).
- Vous utilisez des instances Linux Container-Optimized OS (COS).
- Vous fournissez votre propre clé de plate-forme (PK) ou clé d'inscription (KEK). Si vous utilisez votre propre PK ou KEK, Compute Engine utilise vos clés personnalisées. L'expiration des certificats par défaut ne vous affecte donc pas. Toutefois, vous êtes responsable de la gestion de vos propres clés et de la mise à jour de vos certificats.
Que se passe-t-il si je ne fais rien ?
Si vous ne faites rien, vous ne pourrez peut-être pas appliquer de nouvelles mises à jour du bootloader ou du noyau contenant des binaires signés uniquement avec le certificat 2023, ce qui pourrait rendre les systèmes plus vulnérables à certaines attaques. Pour les instances de calcul créées avant le 7 novembre 2025, si vous n'appliquez pas les mises à jour de certificat avant mi-2026, les clients Windows peuvent voir l'ID d'événement 1801 ("Secure Boot CA/keys need to be updated") dans le journal des événements système.
Comment 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 chiffrement complet du disque, de BitLocker ou de tout logiciel qui repose sur les PCR vTPM.
- Clés de récupération et sauvegardes : assurez-vous de la disponibilité rapide des clés de récupération (pour le chiffrement complet du disque/BitLocker) et des dernières sauvegardes de données.
- Gérer les images : identifiez les anciennes images personnalisées et cessez de les utiliser ou assurez-vous qu'elles incluent les nouveaux certificats.
- Migrer : envisagez de recréer les instances de calcul de longue durée créées avant le 7 novembre 2025, car les nouvelles instances incluent déjà les certificats nécessaires.
- Remarque : Pour le moment, Google ne recommande pas de mettre à niveau manuellement les certificats. Attendez les futures instructions de Google que nous publierons dans ce document.
Que faire si mon système cesse de démarrer après juin 2026 ?
Si vous pensez que ce problème est à l'origine d'un échec de démarrage, consultez la section Dépannage.
Comment gère-t-il Google Cloud l'expiration des certificats de démarrage sécurisé Microsoft ?
Google Cloud a automatiquement inclus 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 antérieures au 7 novembre 2025 devront peut-être appliquer une future mise à jour manuelle, mais Google recommande de migrer vers une instance créée à partir du 7 novembre 2025.
Étape suivante
- 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é.