La date est passée ; la vérification reste importante

Au 24 septembre 2026, cette transition n’est plus un avertissement concernant une date à venir : le certificat Microsoft Corporation UEFI CA 2011 a cessé d’être utilisé pour les nouvelles signatures le 26 juin. Microsoft a transféré la signature des applications UEFI tierces vers les autorités de 2023, notamment Microsoft UEFI CA 2023 ; les Option ROM disposent d’une autorité 2023 distincte. La date précise compte, car certains titres précédents laissaient entendre que Secure Boot lui-même avait une date d’expiration. Ce n’est pas le cas : ce sont des certificats précis, utilisés pour signer certains composants, qui expirent. (Guide Microsoft sur les distributions Linux)

Secure Boot est une fonction du micrologiciel UEFI qui vérifie les signatures des programmes de démarrage avant de les autoriser à s’exécuter. La chaîne peut inclure le gestionnaire de démarrage du système d’exploitation, des chargeurs intermédiaires et des pilotes UEFI, notamment des composants de micrologiciel appelés Option ROM. La base de données de confiance db contient les certificats ou images autorisés ; la base de révocation dbx répertorie les éléments qui ne doivent pas être chargés. L’état d’un PC dépend donc des clés enregistrées dans son micrologiciel et des signatures précises des composants qu’il tente de lancer, pas simplement de l’âge de la machine. (Présentation Microsoft d’OEM Secure Boot)

Expiration et révocation ne sont pas la même chose

La distinction essentielle oppose l’arrêt de l’émission de nouvelles signatures avec un certificat à la révocation de la confiance accordée à ce certificat ou à un programme signé avec celui-ci. L’expiration du certificat de 2011 empêche de l’utiliser pour signer de nouveaux composants via le processus de Microsoft ; à elle seule, elle ne supprime pas la clé de la base db du micrologiciel et n’invalide pas automatiquement tous les fichiers précédemment signés. Microsoft indique qu’un shim Linux déjà signé par l’autorité de 2011 peut continuer à démarrer si le micrologiciel conserve cette autorité et si le shim ou son niveau SBAT n’a pas été révoqué. (Guide Microsoft sur les distributions Linux)

La révocation est une action distincte : les entrées de dbx peuvent bloquer des certificats ou des composants particuliers. Si une image figure à la fois dans la liste de confiance et dans la liste de révocation, la révocation l’emporte. Un ordinateur peut donc encore démarrer aujourd’hui avec un ancien chargeur sans être prêt à recevoir à l’avenir une version corrigée signée uniquement par l’autorité de 2023. Un démarrage réussi ne prouve pas que la chaîne est à jour : il confirme seulement que le micrologiciel accepte le chemin de démarrage utilisé lors de ce démarrage précis. (Présentation Microsoft d’OEM Secure Boot)

Ce qui peut se remarquer sous Windows et sur un PC de bureau classique

Pour Windows, Microsoft indique qu’un appareil dépourvu des nouveaux certificats peut continuer à démarrer et à installer les mises à jour ordinaires. La principale conséquence concerne l’avenir : le PC pourrait ne pas recevoir ou valider de futures protections et mises à jour touchant l’environnement précédant le démarrage, comme le gestionnaire de démarrage et d’autres composants exécutés tôt. Cela ne signifie pas que Windows cessera de fonctionner le lendemain de l’expiration, ni que tous les ordinateurs nécessitent immédiatement une mise à jour du BIOS. La compatibilité dépend du modèle, du micrologiciel OEM et de l’état réel de ses bases de clés. (Conseils Microsoft sur la mise à jour des certificats)

La page Microsoft destinée aux utilisateurs et administrateurs décrit des scénarios plus risqués lorsque le micrologiciel est ancien ou que la mise à jour échoue : erreurs de validation, demandes de récupération BitLocker, blocage au démarrage ou impossibilité de démarrer. Il s’agit de problèmes possibles dans certaines circonstances, et non d’une conséquence inévitable du calendrier. Il est raisonnable de maintenir Windows et le micrologiciel à jour par les canaux officiels du fabricant, sans modifier soi-même les clés UEFI pour tenter d’anticiper. Si l’ordinateur est géré par une organisation, il convient de suivre sa procédure et de ne pas entreprendre de changements manuels. (Conseils Microsoft sur la mise à jour des certificats)

Linux et double démarrage : l’association des signatures et des clés compte

Sous Linux, le composant intermédiaire habituel de nombreuses distributions utilisant Secure Boot est shim : le micrologiciel valide sa signature, puis shim vérifie les éléments suivants de la chaîne, comme GRUB et le noyau. Microsoft décrit deux incompatibilités possibles : un système dont le micrologiciel ne fait confiance qu’à la CA de 2023 n’acceptera pas un shim signé uniquement par la CA de 2011 ; un système qui ne fait confiance qu’à 2011 n’acceptera pas un shim signé uniquement par 2023. Dans les deux cas, installer simplement « la version la plus récente » ne suffit pas : le chargeur installé et les certificats auxquels le micrologiciel fait confiance doivent être compatibles. (Guide Microsoft sur les distributions Linux)

En double démarrage, Windows peut servir de canal de distribution pour certaines mises à jour sur les appareils compatibles, mais cela ne prouve pas que le chargeur Linux ou chaque distribution est prêt. Les responsables doivent publier des composants signés par les nouvelles autorités, vérifier que le micrologiciel ciblé les reconnaît et tenir compte des listes de révocation et de la politique SBAT. Red Hat recommande, par exemple, de mettre à jour la base de confiance du micrologiciel lorsqu’une mise à jour adaptée existe, ainsi que le shim de la distribution ; la marque avertit aussi qu’une révocation pure et simple du certificat de 2011 peut empêcher de démarrer les composants qui en dépendent encore. Ne généralisez pas le calendrier d’une distribution à toutes les autres. (Guide Microsoft sur les distributions Linux)

Vérifier l’état sans modifier les clés à l’aveugle

Sur un PC Windows personnel, vérifiez Windows Update et la section Sécurité de l’appareil > Démarrage sécurisé de l’application Sécurité Windows, si elle est disponible dans votre version. Microsoft documente des notifications et des états concernant la mise à jour des certificats ; sur les appareils gérés, la visibilité et le déploiement peuvent être contrôlés autrement. Pour les administrateurs, la documentation signale des indicateurs tels que la valeur de registre UEFICA2023Status et des événements système, notamment les événements 1801 et 1795. Ces informations aident à distinguer une mise à jour en attente d’une erreur de micrologiciel, mais un utilisateur ne devrait pas interpréter un message isolé sans consulter les consignes correspondant à son édition et à son appareil. (Centre de messages Microsoft Windows)

Dans les distributions Linux, des outils comme mokutil permettent de savoir si Secure Boot est activé et d’examiner les certificats de la base du micrologiciel ; le guide de Red Hat explique aussi comment identifier les signatures de shim. Les résultats doivent être interprétés avec prudence : la présence d’une CA de 2023 ne garantit pas à elle seule que tous les composants sont à jour, et son absence peut compter pour un nouveau chemin de démarrage sans signifier que l’appareil va échouer maintenant. Sur un système doté du chiffrement, du démarrage mesuré ou d’un déverrouillage automatique lié au TPM, la modification des bases UEFI peut changer des mesures comme PCR7 et nécessiter une vérification de la configuration. Faites l’inventaire avant toute modification. (Conseils Red Hat sur les certificats Secure Boot)

Que faire si le fabricant ne propose pas de mise à jour

Commencez par identifier le modèle exact de la carte mère ou du PC de bureau et consultez sa page d’assistance : les mises à jour des bases UEFI dépendent souvent du fabricant du micrologiciel ou de l’OEM. Sous Windows, installez les mises à jour proposées par Windows Update et vérifiez l’état indiqué par le système ; sous Linux, utilisez le mécanisme recommandé par la distribution, comme fwupd si l’appareil et la mise à jour sont compatibles. Pour les appareils gérés, un essai pilote puis un déploiement progressif sont plus prudents qu’une application à tout un parc sans validation, surtout en présence de BitLocker, de double démarrage ou de politiques de clés personnalisées. Microsoft recommande de vérifier d’abord le micrologiciel OEM et de tester des mises à jour représentatives avant d’élargir le déploiement. (Conseils Microsoft sur la mise à jour des certificats)

En l’absence de mise à jour du micrologiciel, aucune réponse universelle ne garantit la compatibilité future. Demandez conseil au fabricant et à la distribution concernée, conservez les informations de récupération BitLocker et les données importantes, et évitez de supprimer l’ancienne CA, d’écrire des variables UEFI à partir d’instructions génériques ou de désactiver Secure Boot par réflexe. Red Hat avertit que supprimer ou révoquer l’autorité de 2011 peut rendre inutilisables les chargeurs ou Option ROM qui en dépendent ; Microsoft décrit également des configurations incompatibles pouvant empêcher le démarrage. La conclusion pratique reste limitée : l’expiration n’éteint pas à elle seule un PC de bureau, mais mettre à jour et vérifier la chaîne de confiance contribue à préserver la capacité de recevoir de futures signatures et protections de démarrage. (Conseils Red Hat sur les certificats Secure Boot)