Secure Boot Certificate Rollover — évaluation et maintenance

Un script PowerShell autonome qui évalue la posture des certificats Secure Boot d'une machine Windows pour le passage de 2011 à 2023 (CVE-2023-24932 / KB5025885) et, uniquement lorsque vous le lui demandez explicitement, opte pour cette machine au pipeline de maintenance Microsoft.

Publié par Exchange Technology Services pour les clients et partenaires qui gèrent leurs propres endpoints.

La version courte

Les certificats Secure Boot émis par Microsoft en 2011 expirent et sont remplacés par des versions 2023.

Aucune machine ne cesse de démarrer à l'une de ces dates. Selon Microsoft, un appareil qui atteint l'expiration sans les nouveaux certificats « continuera de démarrer et de fonctionner normalement. »

Ce qui est perdu, c'est la capacité de recevoir les mises à jour de sécurité au démarrage — nouvelles révocations Secure Boot, atténuations de contournement BitLocker, correctifs du gestionnaire de démarrage. Il s'agit d'une exposition qui s'accumule, et non d'une panne.

Après le 19 oct. 2026, une machine dont le firmware n'a jamais reçu Windows UEFI CA 2023 cesse également de valider les supports de démarrage Windows nouvellement signés, ce qui peut affecter les supports de récupération, d'installation et PXE.

Le KEK est la clé de voûte. Sans Microsoft Corporation KEK 2K CA 2023 dans le firmware, Windows Update ne peut pas du tout livrer la mise à jour DB. Une machine à qui il manque ne peut pas être corrigée tant que le KEK n'arrive pas via Windows Update ou une mise à jour BIOS du fabricant. C'est le blocage le plus courant en pratique, et le script le signale explicitement plutôt que d'écrire une valeur qui ne ferait rien.

Ce que fait ce script et ce qu'il ne fait pas

Exécution

Windows PowerShell 5.1, en tant qu'administrateur — la lecture des variables UEFI nécessite des privilèges élevés.

1. Débloquez le fichier (Windows bloque les scripts téléchargés) :

Unblock-File .\Invoke-SecureBootCertServicing.ps1

2. Évaluez — sûr, ne fait aucune modification :

powershell.exe -ExecutionPolicy Bypass -File .\Invoke-SecureBootCertServicing.ps1

3. Appliquez, uniquement si l'évaluation indique que la machine est prête :

.\Invoke-SecureBootCertServicing.ps1 -Apply -SuspendBitLocker

Capture de la sortie

Le rapport est écrit avec Write-Host, il s'affiche donc sur la console et est enregistré par Start-Transcript. Une redirection > simple ne le capturera pas, pas plus qu'un pipe vers une autre commande.

Start-Transcript C:\Temp\secureboot.log
.\Invoke-SecureBootCertServicing.ps1
Stop-Transcript

Pour une copie lisible par machine, utile lors de la collecte de résultats sur un parc :

.\Invoke-SecureBootCertServicing.ps1 -JsonPath C:\Temp\secureboot.json

Verdicts

Deux axes, délibérément non fusionnés

Le rapport affiche l'état de maintenance et l'état de migration séparément.

• État de maintenance — ce que le pipeline de Microsoft indique qu'il fait.
• État de migration — ce qui est réellement vrai pour le chemin de démarrage.

Ces deux états divergent réellement sur le terrain. Une machine peut indiquer UEFICA2023Status = Updated alors que les deux binaires du gestionnaire de démarrage sur disque sont toujours signés 2011 — cela se produit lorsque le firmware est livré avec l'AC 2023 pré-enregistrée, si bien que le volet certificat est terminé tandis que le volet gestionnaire de démarrage n'a jamais été exécuté. Fusionner les deux en un seul champ marque cette machine comme terminée alors qu'elle est à moitié migrée.

Pour la même raison, le script ne déduit pas l'état de WindowsUEFICA2023Capable. La documentation Microsoft dit de cette valeur, textuellement : « Pour référence uniquement — n'utilisez pas cette clé pour obtenir l'état des mises à jour Secure Boot. » Elle n'est capturée qu'à titre de diagnostic.

BitLocker

Les étapes de maintenance modifient l'état du firmware, ce qui peut déplacer les PCR TPM auxquels un protecteur BitLocker est scellé, et donc provoquer une demande de clé de récupération au prochain démarrage.

• Le script refuse d'armer un volume protégé sans protecteur de mot de passe de récupération — il n'y aurait aucun moyen de revenir.
• Il ne peut pas vérifier que vous disposez d'une copie de cette clé. Confirmez que votre séquestre est sain avant d'exécuter -Apply à grande échelle.
• -SuspendBitLocker suspend la protection pendant le prochain redémarrage afin que la modification soit rescellée sans demande. BitLocker reprend automatiquement ensuite.
• Le rapport indique votre profil PCR. Un profil basé sur PCR 7 est sûr pour un démarrage mesuré lors d'un ajout de certificat. Un profil incluant PCR 0/2/4 couvre les mesures du firmware et du gestionnaire de démarrage, que ces étapes modifient effectivement — risque plus élevé de demande de clé.

L'état BitLocker est lu de trois manières indépendantes (Get-BitLockerVolume, manage-bde et Win32_EncryptableVolume) puis reconcilié. Si les lecteurs divergent, ou si aucun ne peut lire le volume, le script refuse de modifier le firmware plutôt que de deviner.

Paramètres

Les machines virtuelles sont exclues par défaut : l'AC 2023 atteint la ligne de base du firmware via une mise à jour BIOS, et le firmware d'une VM provient de son hyperviseur — une machine invitée sur un hôte non mis à jour ne peut pas terminer seule la migration.

À quoi s'attendre après l'application

• Cela ne se terminera pas au premier redémarrage. Windows applique la mise à jour du certificat, puis celle du gestionnaire de démarrage, généralement sur plusieurs redémarrages avec une tâche planifiée entre les deux.
• Microsoft contrôle cela par appareil. Définir la valeur met le travail en file d'attente ; le déploiement progressif de Microsoft décide quand chaque machine est éligible. Si rien ne semble se produire, relancez le script et lisez la ligne « Microsoft gate » — elle indique la raison, par exemple « Under Observation - More Data Needed ».
• Relancez à tout moment pour vérifier la progression. Il peut être exécuté plusieurs fois sans danger.

Validation

Testé de bout en bout sur Windows 11 (build 26200, PowerShell 5.1, exécuté en tant que SYSTEM), UEFI avec Secure Boot activé, BitLocker entièrement chiffré avec protecteurs TPM + RecoveryPassword sur un profil PCR 7,11 :

• A correctement identifié une machine à moitié migrée — firmware faisant confiance à Windows UEFI CA 2023 tandis que bootmgfw.efi était toujours signé par Microsoft Windows Production PCA 2011 — et ne l'a pas marquée comme terminée, malgré le fait que cette machine indiquait simultanément UEFICA2023Status = Updated et WindowsUEFICA2023Capable = 2.
• Les trois lecteurs BitLocker concordaient et ont été reconciliés.
• Refus vérifiés : machine virtuelle (code de sortie 2), et bit de révocation 0x80 (code de sortie 1).
• -Apply a écrit 0x5944, confirmé par une lecture indépendante du registre.
• -SuspendBitLocker suivi d'un redémarrage : la machine est revenue sans demande de clé de récupération et BitLocker a repris automatiquement.
• Start-Transcript a capturé le rapport complet ; la sortie JSON ne contenait aucune matière de clé de récupération.

Pas encore observé : une machine terminant la migration complète vers FullyMigrated. La dernière étape est contrôlée par le déploiement progressif par appareil de Microsoft, qui échappe à tout contrôle. Le script affiche la raison indiquée par ce contrôle plutôt que de laisser un no-op inexpliqué.

Licence

MIT — voir LICENSE. Fourni tel quel, sans garantie. Examinez-le avant de l'exécuter dans votre environnement ; c'est un fichier unique et lisible précisément pour cette raison.