2026 : comment mettre à jour les certificats Secure Boot des VM Proxmox ?

Les certificats Secure Boot concernés ont été émis en 2011 et certains arrivent à expiration à partir de juin 2026, selon l’avis de Microsoft sur leur expiration et leur renouvellement. Cela ne signifie pas que vos VM Windows cesseront immédiatement de démarrer : vérifiez chaque système invité et son disque EFI, confirmez que la clé de récupération BitLocker est accessible, puis appliquez la procédure officielle correspondant à votre version de Proxmox, d’abord sur une VM pilote et ensuite par lots, avec contrôle après redémarrage.

À lire si vous administrez Proxmox ou des VM Windows et devez planifier cette modification, notamment dans plusieurs environnements clients. Vous pourrez préparer un essai réversible et consigner les résultats avant d’étendre le changement.

Mise à jour de l’article : 3 novembre 2026. Les éléments de calendrier et d’impact sont vérifiés auprès de Microsoft ; les paramètres de VM doivent être recoupés avec la documentation Proxmox VE.

Expiration des certificats et portée réelle

La date d’expiration ne constitue pas, à elle seule, un ordre d’arrêt pour les VM existantes. Microsoft indique que les appareils n’ayant pas encore reçu les nouveaux certificats peuvent continuer à démarrer et à recevoir les mises à jour Windows habituelles, tout en risquant de ne pas bénéficier des protections ultérieures liées aux composants de démarrage. La différence importante est donc entre la continuité immédiate du démarrage et le maintien de la protection de la chaîne de démarrage à venir.

Une VM Windows qui utilise encore les anciens certificats va-t-elle démarrer après leur expiration ?
L’expiration ne signifie pas qu’elle échouera automatiquement au démarrage. Toutefois, conserver un état qui ne reçoit pas les mises à jour de certificats nécessaires peut limiter les protections futures. Vérifiez l’état réel de la VM et les consignes Microsoft applicables à son édition et à son niveau de mise à jour, plutôt que de déduire son comportement de la seule date d’expiration.

Cette procédure concerne les certificats Secure Boot du système invité Windows. Elle ne décrit pas l’activation du démarrage sécurisé sur le serveur Proxmox lui-même. Confondre ces deux niveaux conduit à intervenir sur le mauvais firmware : la configuration de l’hôte n’établit pas que les certificats de chaque VM ont été mis à jour.

Les discussions publiées sur Reddit le 20 mai 2026 et le 7 avril 2026 illustrent des questions d’utilisateurs sur l’application et la vérification des certificats dans des VM Proxmox. Elles constituent des signaux de besoins et des cas individuels, pas une procédure officielle, une mesure de fréquence des incidents ni une preuve de compatibilité générale.

Préparation de la VM et possibilité de retour

Avant de modifier une VM, consignez son identifiant, son système invité, son état de démarrage sécurisé, la configuration de son disque EFI et l’usage éventuel de BitLocker. Pour le relevé côté hôte, la commande Proxmox en lecture seule qm config <VMID> permet de consulter la configuration de la VM. Remplacez <VMID> par l’identifiant réel, puis archivez la sortie avec le dossier de changement.

Exemple de relevé, à adapter aux champs effectivement renvoyés par votre environnement :

bios: ovmf
efidisk0: <stockage>:<volume>,efitype=<valeur>,pre-enrolled-keys=<valeur>

Cet extrait sert à inventorier les paramètres affichés ; il ne confirme pas, à lui seul, que le magasin de certificats du système invité est à jour. La documentation Proxmox décrit les paramètres de firmware et de disque EFI disponibles, mais leur présence et leur libellé doivent être vérifiés pour la version utilisée. N’appliquez pas une valeur copiée d’un autre environnement sans la confronter au guide correspondant.

Que faut-il préparer avant la mise à jour du disque EFI d’une VM Proxmox ?
Conservez une sauvegarde restaurable ou un point de récupération que vous avez effectivement vérifié, identifiez la fenêtre de maintenance et assurez-vous de pouvoir accéder à la console de la VM en cas d’échec de démarrage. La sauvegarde de la configuration de l’hôte n’est pas un substitut à un moyen de restaurer le disque système invité.

Pour une VM protégée par BitLocker, vérifiez que la clé de récupération est conservée conformément aux règles de votre organisation et qu’une personne autorisée peut la retrouver pendant la fenêtre prévue. Le changement d’état de Secure Boot peut modifier les mesures de démarrage observées par BitLocker et provoquer une demande de récupération au redémarrage. Microsoft décrit les circonstances de cet écran dans sa documentation sur la récupération pré-démarrage BitLocker et recommande de gérer ces scénarios dans le cadre de ses consignes d’exploitation BitLocker.

Le relevé préalable doit aussi noter les dépendances opérationnelles : services démarrés automatiquement, comptes de maintenance, supervision et personne chargée de valider l’application après redémarrage. Sans ces informations, une VM qui démarre mais dont le service attendu ne repart pas peut être considérée à tort comme une mise à jour réussie.

Essai pilote et procédure adaptée à la version

Comment vérifier si les certificats Secure Boot sont à jour dans une VM Windows sous Proxmox ?
Utilisez la méthode de contrôle actuellement recommandée par Microsoft pour le système invité concerné, puis consignez l’état obtenu avant le changement et après celui-ci. Ne confondez pas l’indication générale « Secure Boot activé » avec la confirmation que les nouveaux certificats ont été déployés : ce sont des vérifications distinctes. Microsoft détaille le déploiement dans ses instructions de mise à jour des certificats Secure Boot pour Windows.

Commencez par une VM pilote non critique ou facilement restaurable. Elle doit être assez représentative du parc pour rendre l’essai utile : même famille de système invité, configuration UEFI comparable, disque EFI présent et même usage de BitLocker, si possible. Si les VM diffèrent sur ces points, un pilote ne valide pas automatiquement toutes les autres.

Pendant cet essai :

• comparez la configuration Proxmox relevée avant et après l’opération ;
• suivez la procédure officielle correspondant à la version de Proxmox VE et au système Windows de la VM ;
• notez les éventuels changements de paramètres EFI et l’état observé dans l’invité ;
• redémarrez dans la fenêtre prévue et vérifiez que la VM ainsi que ses services attendus fonctionnent ;
• consignez toute demande de récupération BitLocker et la manière dont elle a été résolue.

La documentation de Proxmox ne doit pas être interprétée comme une procédure Windows universelle de renouvellement des certificats : elle sert notamment à vérifier les paramètres de la VM, tandis que le déploiement côté invité et sa confirmation relèvent des instructions Microsoft. Si l’interface, les options EFI ou les indications de la documentation ne correspondent pas à votre environnement, suspendez l’essai et clarifiez l’écart avant toute extension. Ne reprenez pas une commande trouvée dans une discussion communautaire en supposant qu’elle convient à toutes les versions.

Déploiement par lots et gestion des incidents

Lorsque le pilote a réussi, planifiez les VM selon leur criticité et leur capacité de restauration. Évitez de regrouper dans un même créneau toutes les VM qui partagent une dépendance métier : un problème commun de démarrage ou de récupération pourrait alors affecter plusieurs services à la fois.

Pour chaque lot, indiquez les VM concernées, la fenêtre de maintenance, le responsable de l’opération, la personne habilitée à obtenir les clés BitLocker et les conditions de retour arrière. Un arrêt ou un redémarrage peut être nécessaire selon la procédure et l’état des VM ; ne promettez ni mise à jour en ligne, ni absence de redémarrage, ni comportement identique pour tous les systèmes invités.

Quelles vérifications effectuer après une mise à jour des certificats d’une VM ?
Vérifiez d’abord que la VM démarre sans intervention imprévue, puis confirmez dans Windows que l’état de Secure Boot et le déploiement des certificats correspondent aux critères Microsoft applicables. Enfin, contrôlez BitLocker et les services de l’invité. Une seule indication, côté hôte ou côté invité, ne suffit pas à prouver que toute la chaîne fonctionne correctement.

Si une VM affiche un écran de récupération BitLocker, utilisez la clé selon le processus autorisé par votre organisation ; ne désactivez pas la protection par réflexe pour faire disparaître l’écran. Microsoft documente la procédure de récupération et l’usage de manage-bde dans ses pages consacrées au processus de récupération BitLocker et aux protecteurs gérés avec manage-bde. Traitez la clé comme un secret : évitez de la placer dans des journaux de changement accessibles largement ou de la copier dans un ticket sans contrôle d’accès.

Après chaque lot, consignez trois états distincts : réussite vérifiée, échec nécessitant une investigation, ou intervention en attente. Une VM qui redémarre mais dont l’état des certificats n’a pas été contrôlé ne doit pas être marquée « terminée ». De même, si la clé BitLocker est indisponible, ne relancez pas en série la modification et ne désactivez pas Secure Boot sans avoir identifié une stratégie de récupération sûre.

Matrice de décision avant extension

Cette approche est plus fiable qu’un basculement généralisé fondé sur un seul indicateur. Elle vous permet aussi de distinguer les écarts de configuration des problèmes propres au système invité et de conserver une trace exploitable lors des prochains changements.

Maintien des exceptions et choix de l’environnement

Gardez une liste séparée des VM qui n’ont pas pu être mises à jour, de celles dont le démarrage reste incertain et de celles pour lesquelles la clé de récupération n’est pas disponible. Pour chacune, notez la version Proxmox, le système invité, les paramètres EFI observés, le résultat du contrôle Microsoft et la prochaine action décidée. Reprenez cette liste lorsque les consignes officielles ou les mises à jour du système évoluent ; ne transformez pas une exception en procédure standard avant d’avoir compris sa cause.

Si vous préparez un hôte dédié pour accueillir vos VM Windows et Proxmox, consultez la présentation des systèmes et des configurations disponibles pour vérifier l’environnement proposé. OSFP Cloud indique Proxmox VE parmi les systèmes disponibles sur ses serveurs physiques AMD ; cela concerne le choix de l’environnement d’hébergement, pas la mise à jour des certificats dans l’invité, la récupération BitLocker ni une garantie de démarrage. Pour délimiter ce qui relève de l’infrastructure et ce qui reste à la charge de votre équipe, consultez aussi les limites de service.

Si votre infrastructure actuelle repose sur des VM partagées, elle peut convenir à un parc temporaire ou peu chargé, mais la concurrence de ressources entre clients et les possibilités limitées de personnalisation peuvent compliquer la maîtrise d’un hôte qui doit exécuter plusieurs VM durablement. À l’inverse, une machine physique AMD louée exclusivement vous laisse organiser la virtualisation et les fenêtres de maintenance sur votre propre hôte, sans transformer cette indépendance en prise en charge des certificats ou des clés BitLocker. Pour des VM Windows maintenues sur le long terme et un besoin de ressources réservées, comparer cette option à votre offre actuelle est pertinent ; pour un essai bref ou une charge légère, une VM partagée peut rester le choix le plus proportionné.