RHEL et l'expiration du certificat Secure Boot : Ce qui change vraiment en 2026

On va être clairs : si vos serveurs RHEL bootent sans problème en ce moment, ils continueront à démarrer après le 27 juin 2026. L'expiration du certificat ne va pas tout casser à minuit pile. Le vrai impact, c'est sur la signature des nouveaux composants de boot.

Pourquoi ça compte : Secure Boot, c'est le mécanisme de Microsoft qui vérifie que seuls les chargeurs d'amorçage et noyaux signés cryptographiquement peuvent démarrer. Le certificat de 2011 a rendu service pendant des années, mais tout a une durée de vie.

Ce qui est vraiment en jeu

La nuance est essentielle ici :

• Composants déjà approuvés : Ils continuent de tourner. L'expiration ne rend pas invalides rétroactivement les signatures créées avant.
• Nouveaux composants de boot : C'est là que ça change. Tout noyau, shim ou bootloader signé après la date fatidique devra utiliser une nouvelle clé.

Pour la majorité d'entre vous avec des systèmes stables, nada de changement au quotidien. Mais si vous déployez de nouvelles infra, recompilez des systèmes ou mettez à jour des composants de boot dans les mois qui viennent, gardez cette date en tête.

Le facteur Shim

Les choses se corsent légèrement ici. Le shim, cette fine couche entre votre firmware et votre bootloader, entre aussi dans l'équation. Red Hat maintient son propre shim, et le garder à jour fait partie des bonnes pratiques recommandées.

Les mises à jour du shim arrivent généralement via les mises à jour système classiques. Un système RHEL raisonnablement à jour devrait donc être bien positionné. Mais si vous avezreporté ces mises à jour sur un serveur production "stable" que personne ne veut toucher, c'est peut-être le moment de trouver une fenêtre de maintenance.

Ce que vous devriez faire concrètement

Votre checklist pratique :

1. Pas de panique. Vos systèmes en fonctionnement ne vont pas s'arrêter de booter comme ça.
2. Tenez vos systèmes à jour. Au-delà de l'hygiène de sécurité, les systèmes mis à jour auront les bons packages shim et bootloader pour gérer cette transition.
3. Anticipez les nouveaux déploiements. Si vous montez de nouvelles instances RHEL après juin 2026, vérifiez que vos images de base et supports d'installation sont à jour.
4. Testez en staging. Si vous avez des environnements de test non-critiques, vérifiez que vos pipelines de déploiement fonctionnent bien avec les packages actuels.
5. Documentez votre état actuel. Savoir quels systèmes tournent avec quelles versions de shim et bootloader vous donne une base claire.

En résumé

L'expiration d'un certificat de sécurité peut faire flipper — comme ce moment où vous réalisez que votre SSL sur un site production a expiré. Mais ici, les conséquences sont bien plus limitées que ce qu'on pourrait craindre.

L'expiration du certificat Secure Boot 2026, c'est une transition gérée, pas une crise. Microsoft et Red Hat bossent dessus, et l'écosystème Linux a eu des années pour se préparer. Votre rôle est simple : maintenez vos systèmes à jour, restez au courant de ce qui change, et testez vos processus de déploiement.

Considérez ça comme une excuse parfaite pour enfin mettre à jour ce staging environment que vous négligez depuis des mois. Votre futur vous — et votre posture de sécurité — vous en remercieront.

Restez safe.