Le Secure Boot Linux repose sur une chaîne de confiance fragile. En 2026, un maillon de cette chaîne change, et les administrateurs système ont intérêt à comprendre ce qui se passe avant que ça ne devienne un problème.
Secure Boot Linux et l’expiration du certificat Microsoft 2011
Le certificat en question porte le nom de « Microsoft Windows UEFI Driver Publisher ». Il a été émis en 2011 et Microsoft l’utilise depuis pour signer le composant appelé shim, qui est le point d’entrée du démarrage sécurisé sur la majorité des distributions Linux.
Ce certificat expire le 27 juin 2026. Passé cette date, Microsoft ne l’utilisera plus pour signer de nouveaux composants. La nouvelle clé de référence s’appelle UEFI CA 2023.
Comment fonctionne la transition
Depuis octobre 2025, Microsoft signe le shim avec les deux clés simultanément : l’ancienne (2011) et la nouvelle (UEFI CA 2023). Cette période de double-signature offre une fenêtre de transition que les distributions peuvent utiliser pour livrer des mises à jour.
Après juin 2026, seule la clé 2023 sera utilisée pour les nouvelles signatures. Les shims déjà signés avec la clé 2011 restent techniquement valides pour les systèmes qui les ont déjà installés. Un poste Linux qui démarre aujourd’hui continuera à démarrer après cette date, sans action immédiate.
Le risque n’est donc pas une coupure brutale le 27 juin au matin. C’est un risque différé, conditionnel, qui concerne des scénarios précis.
Qui est réellement exposé
La situation est maîtrisée pour les environnements maintenus. Elle devient problématique dans des cas bien identifiés :
- Les instances cloud créées avant une certaine date (Google Cloud documente le seuil du 7 novembre 2025 pour Compute Engine)
- Les systèmes embarqués ou OEM avec Secure Boot activé mais sans processus de mise à jour simple
- Les parcs de machines qui n’ont pas appliqué les mises à jour de shim depuis plusieurs mois
- Les environnements figés volontairement, comme certaines infrastructures industrielles ou legacy
Pour ces environnements, l’absence du nouveau shim signé avec la clé 2023 peut poser problème si le firmware UEFI est mis à jour ou si la machine est réinstallée.
La réponse de Red Hat : rapide et opérationnelle
Red Hat est la source la plus claire sur ce sujet. L’entreprise a publié dès le 10 juin 2026 une version mise à jour du shim pour RHEL 8, 9 et 10 en architecture x86_64, signée avec les deux certificats.
Un article dédié sur le portail client et un billet de blog explicatif accompagnent cette mise à jour. Pour un administrateur qui gère un parc RHEL ou CentOS Stream, la marche à suivre est documentée et le correctif est disponible.
Les autres distributions majeures comme Ubuntu, Debian, Fedora ou SUSE n’ont pas de documentation publique équivalente recensée dans les sources disponibles. Leur calendrier de mise à jour reste à vérifier directement auprès de leurs canaux officiels.
Ce que ça change pour les autres clouds
Google Cloud a documenté l’impact de façon précise et factuelle. Les instances Compute Engine créées avant le 7 novembre 2025 sont potentiellement concernées, Google ayant mis à jour ses certificats par défaut à cette date.
Pour AWS et Azure, les sources disponibles ne donnent pas d’informations équivalentes. Si vous gérez des instances sur ces plateformes avec Secure Boot activé, il vaut mieux contacter le support ou surveiller leurs bulletins de sécurité.
Quelle action mener maintenant
Le travail d’un responsable infrastructure sur ce sujet se résume à trois étapes concrètes.
D’abord, identifier les systèmes concernés : lesquels ont Secure Boot activé, quel shim est installé, et quelle clé a été utilisée pour le signer. Sur RHEL, la commande mokutil --sb-state combinée à une vérification du paquet shim installé donne déjà une première visibilité.
Ensuite, prioriser les environnements à risque : instances cloud anciennes, systèmes sans mise à jour automatique, machines en production depuis plusieurs années sans intervention.
Enfin, planifier la mise à jour du shim avant fin juin 2026. Pour RHEL, le correctif est disponible. Pour les autres distributions, l’action prioritaire est de surveiller les bulletins officiels.
Ce qu’il faut retenir
- Le certificat Microsoft utilisé pour signer le shim Linux expire le 27 juin 2026. Les systèmes déjà en fonctionnement ne tombent pas en panne à cette date.
- La transition vers la clé UEFI CA 2023 est gérée par une période de double-signature depuis octobre 2025.
- Red Hat a livré le correctif pour RHEL 8, 9 et 10. Les autres distributions n’ont pas encore de documentation publique équivalente recensée.
- Le risque réel vise les environnements figés : instances cloud anciennes, systèmes embarqués, parcs non maintenus.
- L’action prioritaire est d’inventorier les systèmes Secure Boot concernés et de planifier leur mise à jour avant la bascule exclusive vers la clé 2023.
Si vous gérez des environnements Linux avec Secure Boot et que vous voulez en discuter, n’hésitez pas à me contacter ou à suivre le blog pour les prochaines analyses.
Sources
- https://www.redhat.com/en/blog/expiration-secure-boot-signing-certificates-2026
- https://access.redhat.com/articles/7128933
- https://docs.cloud.google.com/compute/docs/security/ms-secure-boot-certificates-expiration
- https://www.linuxteck.com/secure-boot-linux-key-expires/
- https://news.ycombinator.com/item?id=48633941
- https://www.reddit.com/r/hackernews/comments/1ud2u99/linux_and_secure_boot_certificate_expiration_2025/