Publié – Juillet 2025
Introduction
Depuis plus d’une décennie, Secure Boot est un composant critique de la chaîne de confiance des systèmes UEFI. Il permet d’empêcher l’exécution de code non signé au démarrage. Les distributions Linux y sont compatibles grâce à un mécanisme particulier : un shim signé par Microsoft.
Or, la clé utilisée pour signer ces shims arrive à expiration en 2025. Cette échéance aura des conséquences concrètes sur la capacité des systèmes Linux à démarrer sur des plateformes où Secure Boot est activé. Cet article fait le point sur les implications, les scénarios de blocage possibles, et les stratégies d’anticipation pour les administrateurs systèmes.
Comprendre le rôle de Microsoft dans Secure Boot Linux
Les ordinateurs UEFI avec Secure Boot activé ne chargent que les binaires signés par une autorité reconnue. Par défaut, ces autorités sont définies dans le firmware, et Microsoft est l’un des signataires autorisés.
Les distributions Linux ne sont pas signées directement par Microsoft, mais utilisent un shim (petit chargeur de confiance) pré-signé. Ce shim permet ensuite de charger GRUB, le noyau Linux, et initrd, qui sont signés avec une clé propre à la distribution.
Tant que le shim signé par Microsoft est valide, le système peut démarrer sur un firmware UEFI configuré avec Secure Boot activé.
Ce qui change avec l’expiration de la clé en 2025
La signature utilisée par Microsoft pour les anciens shims arrive à expiration à une date fixe. Une fois expirée, le firmware UEFI peut rejeter la chaîne de démarrage, même si tout le système est fonctionnel.
Concrètement, cela signifie que :
- Les versions de Linux utilisant d’anciens shims ne pourront plus démarrer sur certaines machines avec Secure Boot activé.
- Même une mise à jour Linux complète ne suffira pas si le firmware ne reconnaît pas la nouvelle signature Microsoft (ou ne la contient pas).
- Les utilisateurs pourront être contraints de désactiver Secure Boot, ou d’installer une clé manuellement via MOK (Machine Owner Key).
Scénarios typiques de blocage
- Machines OEM sans mise à jour de firmware UEFI
- Elles ne reconnaîtront pas la nouvelle signature.
- Impossible de démarrer un Linux à jour avec un nouveau shim.
- Infrastructure virtualisée avec UEFI + Secure Boot
- Les hyperviseurs configurés avec des templates anciens peuvent refuser les nouvelles ISO.
- Risque de blocage dans les pipelines CI/CD automatisés.
- Réseaux mixtes (Windows + Linux avec Secure Boot actif)
- Si Secure Boot est imposé pour conformité, l’expiration de la clé provoquera un conflit de politique IT.
Solutions possibles pour les administrateurs Linux
1. Désactivation de Secure Boot
La solution la plus simple dans les environnements contrôlés : désactiver Secure Boot dans le firmware. Cela permet de démarrer n’importe quelle distribution, au prix d’un niveau de sécurité réduit sur le boot.
2. Utilisation de clés personnalisées
Certains administrateurs choisissent d’implémenter leurs propres clés (PK, KEK, db) et de signer le shim eux-mêmes. Cela nécessite de remplacer les clés du firmware UEFI, opération complexe et risquée en cas d’erreur.
3. Réinstaller avec une ISO mise à jour
Les dernières versions de distributions Linux (post-2025) intégreront un shim signé avec la nouvelle clé. Cela implique que le firmware soit capable de vérifier cette nouvelle signature. Ce n’est pas garanti sur les anciens matériels.
4. Supervision proactive du parc machine
Avant l’échéance, il est prudent de :
- Vérifier les versions de firmware UEFI sur tous les hôtes
- Identifier les plateformes sans mise à jour disponible
- Planifier le remplacement ou la reconfiguration des systèmes concernés
Bonnes pratiques d’anticipation
- Lister toutes les machines UEFI avec Secure Boot actif
- Auditer les versions de shim en cours (
mokutil,/boot/efi/EFI) - Évaluer les risques métier si un redémarrage échoue
- Éviter d’automatiser les mises à jour critiques proches de la date d’expiration
- Informer les équipes helpdesk/support pour limiter les blocages utilisateurs
Conclusion
L’expiration de la clé Microsoft utilisée pour le boot sécurisé des systèmes Linux n’est pas un simple détail cryptographique. C’est un évènement qui peut affecter la stabilité et la disponibilité des serveurs et postes de travail Linux dans des environnements où Secure Boot est activé.
Les administrateurs doivent auditer leurs environnements, anticiper les mises à jour firmware, ou envisager la désactivation de Secure Boot si le contrôle matériel est total. Cette transition impose une planification sérieuse, mais offre aussi une opportunité d’améliorer la maîtrise de la chaîne de démarrage Linux.
