Expiration des certificats Secure Boot : attention en 2026
Les faits
En juin 2026, plusieurs certificats utilisés pour la validation des signatures UEFI Secure Boot arrivent à expiration, ce qui fait peser un risque concret d'échec d'amorçage pour des systèmes qui s'appuient sur ces chaînes de confiance¹. Ce n'est pas une date symbolique : une mise à jour de firmware ou d'OS, ou la présence d'une ancienne chaîne de signatures dans la base DB/DBX du firmware, peut provoquer un rejet immédiat des binaires signés et empêcher le démarrage normal. Selon le CERT-FR, les équipes d'exploitation doivent anticiper et tester avant cette échéance¹.
Qui est concerné
- Les OEM qui publient des firmwares UEFI et gèrent les clés PK/KEK/DB/DBX.
- Les fournisseurs d'images système et les distributions Linux qui s'appuient sur des composants signés tels que shim, grub et le noyau.
- Les organisations exploitant des parcs hétérogènes, des serveurs bare-metal et des clouds privés qui appliquent des contrôles d'intégrité au démarrage.
Risques et conséquences immédiates
Si une chaîne de signature contient un certificat arrivé à échéance, le firmware peut refuser les binaires signés au moment du boot. Conséquences pratiques : des machines peuvent rester bloquées en dehors du réseau, passer en mode non supporté ou nécessiter une intervention physique pour rétablir le démarrage. Pour les environnements critiques, cela se traduit par une montée en charge des procédures de reprise et des coûts d'intervention sur site. Plusieurs facteurs aggravent le risque : parcs matériels hétérogènes, sites isolés sans personnel technique, et procédures de mise à jour non standardisées.
Comment le problème se manifeste techniquement
Le mécanisme Secure Boot repose sur un jeu de variables UEFI et des certificats stockés dans les bases DB (certificats autorisés) et DBX (certificats explicitement refusés). Au démarrage, le firmware vérifie la signature des binaires contre ces certificats. Si un certificat composant la chaîne a dépassé sa date de validité, la vérification peut échouer et le binaire être rejeté. La présence d'un timestamp valide sur la signature peut, selon la façon dont la signature a été produite et comment le firmware interprète les timestamps, permettre de maintenir la validité d'une signature au-delà de l'expiration du certificat, mais ce comportement n'est pas uniforme entre firmwares³.
La chaîne typique pour Linux utilise un shim signé par une autorité reconnue, puis shim vérifie grub et le noyau. Microsoft maintient des programmes de signature qui rendent shim acceptable sur de nombreux firmwares, ce qui explique pourquoi des distributions s'appuient sur ce mécanisme². En pratique, la façon dont chaque firmware applique les règles de vérification peut varier : certains acceptent les signatures horodatées RFC3161, d'autres non, et certains peuvent nécessiter des mises à jour du DB/DBX pour ajouter ou retirer des certificats³.
Contexte et précédents
Secure Boot existe depuis plusieurs années et vise à empêcher l'exécution de code non signé ou modifié avant le chargement du système d'exploitation. La hiérarchie PK/KEK/DB/DBX et l'usage de signatures PKCS#7 sont définis dans les spécifications UEFI³. Dans le passé, des expirations de certificats ou des modifications des DB/DBX ont déjà entraîné des incidents nécessitant des mises à jour firmware, des re-signatures ou des opérations de ré-enrôlement de clés. Ces précédents montrent que la préparation et l'exercice des procédures de reprise réduisent significativement l'impact opérationnel.
Actions observées chez les acteurs
- OEMs : publication de firmwares correctifs mettant à jour la DB/DBX et clarifications sur les procédures de mise à jour.
- Distributions Linux : publication de versions récentes de shim, grub et du noyau, et publication de guides d'utilisation d'outils tels que mokutil pour gérer les clés locales.
- Fournisseurs cloud et constructeurs d'images : validation et mise à jour des templates ISO et des images de déploiement pour s'assurer de la compatibilité avec les firmwares récents.
Ces actions doivent être suivies de tests et d'un calendrier de déploiement clair côté opérations pour éviter des interruptions massives.
Recommandations opérationnelles (priorisées)
- Inventaire et cartographie
- Recense les modèles de firmware, versions et politiques Secure Boot pour chaque équipement. Exporte les variables UEFI quand c'est possible pour analyser DB/DBX.
- Sous Linux, la commande mokutil --sb-state donne l'état de Secure Boot. Sous Windows, Get-SecureBootUEFI dans PowerShell fournit un état équivalent.
- Tests représentatifs
- Monte un laboratoire qui reproduit les familles matérielles principales de ton parc. Simule des mises à jour de firmware et d'OS pour vérifier le comportement à froid et après mise à jour.
- Mises à jour firmware et images signées
- Priorise les firmwares fournis par l'OEM qui corrigent les entrées DB/DBX. Assure-toi d'utiliser les images ISO et paquets signés recommandés par les distributions.
- Procédures d'urgence et fallback
- Documente et valide les procédures pour démarrer en SetupMode, ré-enrôler PK/KEK, ajouter une MOK ou désactiver temporairement Secure Boot si la politique le permet.
- Prépare des plans d'intervention physique pour sites isolés et des images de secours signées et testées.
- Automatisation et intégration CI/CD
- Intègre des vérifications de signatures et d'expiration des certificats dans les pipelines de build et de déploiement. Automatise l'inspection des certificats présents dans efivars et l'alerte en cas d'expiration proche.
- Communication et gouvernance
- Informe les parties prenantes opérationnelles et métiers des risques, des fenêtres de maintenance et des procédures de reprise.
- Établis des règles précises pour la gestion des clés PK/KEK et conserve des sauvegardes des variables critiques.
Commandes et outils pratiques
- mokutil --sb-state pour vérifier l'état de Secure Boot sous Linux.
- efibootmgr -v et consultation de /sys/firmware/efi/efivars pour lister les variables UEFI.
- sudo mokutil --import mypubkey.cer pour installer une clé MOK sur les distributions compatibles.
- sbsign/sbsigntool et pesign pour signer et vérifier des binaires EFI. Ces outils permettent d'automatiser la vérification avant déploiement.
Mesures de mitigation temporaires
- Désactiver Secure Boot uniquement dans un périmètre contrôlé et si la tolérance métier le justifie. Documente la durée et les conditions de cette désactivation.
- Maintenir des images de secours signées et testées pour restaurer rapidement le service.
