Certificats Secure Boot expirés : ce qui change sous Windows et Linux

Deux certificats Microsoft utilisés par Secure Boot depuis 2011 ont expiré les 24 et 27 juin 2026. Leur expiration n’a pas invalidé les chaînes de démarrage déjà en place. Le passage aux certificats de 2023 reste néanmoins nécessaire pour continuer à recevoir les mises à jour de sécurité liées à Secure Boot.

Le déploiement de leurs remplaçants est déjà engagé sur les systèmes encore pris en charge. Il reste plus incertain sur les machines anciennes, les firmwares qui ne sont plus mis à jour et certains environnements virtuels.

Quels certificats ont expiré ?

Secure Boot est une fonction du firmware UEFI qui vérifie la signature des logiciels exécutés avant le système d’exploitation. Cette chaîne de confiance repose notamment sur des certificats enregistrés dans le firmware.

Le Microsoft Corporation KEK CA 2011, qui autorisait certaines mises à jour des bases de certificats Secure Boot, a expiré le 24 juin 2026. Le Microsoft Corporation UEFI CA 2011, notamment utilisé pour signer le chargeur shim de nombreuses distributions Linux, a expiré le 27 juin. Le Microsoft Windows Production PCA 2011, utilisé pour le gestionnaire de démarrage de Windows, reste valable jusqu’au 19 octobre 2026. Microsoft récapitule ce calendrier et les certificats de remplacement dans sa documentation sur la transition Secure Boot.

L’expiration n’invalide pas automatiquement les logiciels déjà signés. Les documentations de Microsoft et des distributions Linux concordent : une machine qui démarrait avant ces dates peut continuer à fonctionner avec ses composants actuels. Le risque est progressif : sans les certificats de 2023, elle pourrait ne plus exécuter de futurs gestionnaires de démarrage ni recevoir les prochaines listes de révocation.

Les contrôles utiles sous Windows

Sur un PC encore pris en charge, il faut commencer par installer les mises à jour de Windows et du firmware proposées par le fabricant, puis redémarrer. Microsoft affiche désormais l’état de la mise à jour des certificats dans Sécurité Windows > Sécurité de l’appareil > Démarrage sécurisé.

La simple activation de Secure Boot ne suffit pas à confirmer l’installation des nouveaux certificats. Une coche verte seule non plus : le texte doit indiquer que toutes les mises à jour requises ont été appliquées. La documentation de Sécurité Windows présente aussi les états signalant une opération suspendue ou bloquée par le matériel.

Avant une mise à jour UEFI, il est préférable de conserver la clé de récupération BitLocker et d’utiliser l’outil officiel du constructeur. Une modification des mesures du TPM peut en effet déclencher une demande de récupération.

Les anciens PC cumulent davantage d’incertitudes. Le support des éditions courantes de Windows 10 a pris fin le 14 octobre 2025, mais les éditions LTSC suivent un autre calendrier et les appareils inscrits au programme ESU continuent de recevoir certaines mises à jour. Un PC équipé d’une version de Windows qui n’est plus maintenue et dépourvu de firmware récent pourra continuer à démarrer, tout en restant privé des futures protections de Secure Boot. Microsoft récapitule ces cas sur sa page de fin de support de Windows 10.

Sous Linux, la procédure dépend de la distribution

Le principal enjeu concerne shim, un chargeur intermédiaire signé par Microsoft que de nombreuses distributions utilisent pour lancer leurs propres composants. Plusieurs éditeurs proposent désormais une version signée avec les certificats de 2011 et de 2023 afin de préserver la compatibilité pendant leur période de coexistence.

• Red Hat fournit ce shim multisigné pour les versions prises en charge de RHEL 8, 9 et 10 sur x86_64. Sur aarch64, les versions récentes utilisent uniquement la signature de 2023.
• AlmaLinux suit la même approche sur x86_64. Sa documentation Secure Boot recommande fwupd 2.0.8 ou plus récent pour AlmaLinux 9 et 10. La version fournie avec AlmaLinux 8 est trop ancienne pour mettre à jour ces variables.
• Canonical déploie les nouveaux certificats avec fwupd 2.0 ou plus récent. Sans cette mise à jour, Ubuntu pourrait ne plus accepter certaines versions de shim distribuées à partir du quatrième trimestre 2026.
• Fedora a organisé une campagne de tests du shim multisigné sur différents firmwares afin d’identifier les incompatibilités matérielles avant les échéances de juin.
• Debian fournit déjà un shim multisigné dans testing et unstable. Des versions destinées à Debian 12 et 13 sont également en préparation, selon sa page consacrée à la transition vers les nouveaux certificats Secure Boot.

Les commandes de contrôle, les versions minimales de fwupd et les méthodes d’installation varient selon la distribution, sa version et l’architecture utilisée. Les documentations citées ci-dessus détaillent l’état du déploiement et les consignes propres à chaque environnement.