Votre PC Linux a un problème de démarrage sécurisé - que faire en premier (et la solution de contournement à éviter)

Le démarrage sécurisé a toujours été un casse-tête pour les utilisateurs de Linux, mais les autorités de certification de Microsoft expirant en 2011 en font un vrai calvaire.

Points clés de Linux-Terminal.com

Linux a un nouveau problème avec le démarrage sécurisé.
Mais ce n’est pas aussi mauvais que certaines personnes le prétendent.
Voici ce que vous pouvez faire pour résoudre le problème.

À la fin des années 2000, le micrologiciel des ordinateurs passait du BIOS hérité à l’interface de micrologiciel extensible unifiée (UEFI). Avec cela est arrivé le démarrage sécurisé (Secure Boot). Ce mécanisme de sécurité soutenu par Microsoft était conçu pour arrêter les bootkits et les logiciels malveillants au niveau du micrologiciel que les mesures de sécurité traditionnelles du système d’exploitation ne pouvaient pas détecter. Le démarrage sécurisé était compliqué, mais il accomplissait sa tâche. Pour les gens essayant d’installer et d’exécuter Linux sur des PC Windows, cette configuration était un vrai casse-tête. Nous y voici, 14 ans après que le démarrage sécurisé soit apparu pour la première fois sur les PC Windows 8, et il a de nouveau le potentiel de donner de vrais maux de tête aux utilisateurs de Linux.

Encore une fois, certains amateurs de Linux paniquent en pensant que « Microsoft exclut Linux ! ». Ce n'est pas ce qui se passe. Comme l'a souligné Microsoft, « les certificats Secure Boot ont toujours eu des dates d'expiration ». Oui, oui, c'est vrai. De plus, comme l'a récemment observé Ed Bott, bien que ce ne soit pas aussi gênant pour les utilisateurs de Windows, certaines personnes peuvent tout de même rencontrer des problèmes avec l'expiration des certificats Secure Boot.

La bonne nouvelle est que cette inquiétude n’est pas un événement catastrophique pour Linux. Vos systèmes existants ne vont pas se réveiller un matin et refuser de démarrer simplement parce qu’une date a changé. Mais c’est tout de même un moment de vérité sur la manière dont le monde Linux a géré le Secure Boot pendant plus d’une décennie, et une opportunité pour les utilisateurs de prendre plus de contrôle, plutôt que d’espérer tranquillement que Microsoft et les fabricants d’équipement d’origine maintiennent le fonctionnement pour toujours.

Examinons ce qui se passe réellement, pourquoi Linux est impliqué, et ce que vous devriez faire avant 2026 et après.

Un vieux compromis arrive à échéance

Pour comprendre pourquoi, il faut revenir à 2011‑2012, lorsque le démarrage sécurisé UEFI est apparu pour la première fois sur les PC grand public. L'objectif de conception semblait raisonnable : empêcher l'exécution de code non fiable avant le système d'exploitation en faisant en sorte que le micrologiciel vérifie les signatures des chargeurs de démarrage, des noyaux et des ROM optionnelles.

En pratique, cependant, Microsoft a effectivement défini les racines de confiance pour presque tous les PC grand public. Plutôt que de créer - ou de faire créer par les utilisateurs - des clés et certificats Secure Boot, la plupart des fabricants de matériel ont livré des machines avec un ensemble de clés et de certificats intégrés dans le micrologiciel. La plupart de ces clés et certificats étaient des « Microsoft 3rd‑party UEFI CA » capables de signer des chargeurs d'amorçage tiers. Les distributions qui voulaient « simplement démarrer » sur ces systèmes sans demander aux utilisateurs de manipuler des interrupteurs obscurs du micrologiciel avaient essentiellement deux options :

Instructions de l'expéditeur pour les utilisateurs afin de désactiver le démarrage sécurisé.
Ou jouer le jeu et obtenir un petit chargeur d'amorçage de première étape (shim) signé par la CA UEFI de Microsoft.

La plupart des grandes distributions Linux ont choisi shim. Matthew Garrett, un programmeur Linux bien connu, a créé l'approche shim, et elle est toujours utilisée aujourd'hui.

Cette approche était un compromis pragmatique : Microsoft vérifie le shim, le shim vérifie le reste de la chaîne de démarrage Linux, et les utilisateurs n'ont pas à modifier manuellement les bases de données de clés UEFI ou à désactiver les fonctionnalités de sécurité.

Ce compromis a très bien fonctionné. Pendant plus d’une décennie, vous pouviez acheter un ordinateur portable au hasard, activer le démarrage sécurisé, et démarrer Fedora, Ubuntu, openSUSE, Debian, RHEL et d’autres, tout cela grâce à la clé Microsoft stockée dans votre micrologiciel et à un binaire shim signé par Microsoft dans votre partition système EFI.

Mais les certificats, contrairement aux compromis, ont des dates d'expiration.

Qu'est-ce qui expire en 2026 ?

La racine du drame actuel est que les certificats de 2011 que Microsoft a utilisés pour signer les composants Secure Boot approchent de la fin de leur période de validité officielle. Plusieurs des certificats Secure Boot de l’époque 2011 de Microsoft atteindront leur fin de vie en 2026, en deux grandes vagues (à la mi‑année et plus tard dans l’année).

Pour résoudre ce problème, Microsoft a créé un nouveau jeu de certificats Secure Boot en 2023 et a commencé à les distribuer aux OEM et aux plateformes. Les mises à jour du micrologiciel sont censées effectuer le travail en silence : ajouter de nouvelles clés, conserver les anciennes pour la compatibilité et s'assurer que les composants de démarrage futurs peuvent être validés.

Pour les environnements Windows uniquement, il s'agit surtout d'une mise à jour automatique. Pour le monde Linux, c'est une autre histoire.

Lorsque les gens entendent « expiration de certificat », ils ont tendance à imaginer quelque chose comme un certificat SSL : une fois que la date « notAfter » est dépassée, les clients refusent de communiquer avec le serveur. Ce modèle mental fait paraître 2026 comme un précipice : le 24 juin arrive, et soudainement votre distribution ne démarre plus.

Le démarrage sécurisé ne fonctionne pas de cette manière. Si votre micrologiciel fait déjà confiance à la CA UEFI Microsoft 2011 aujourd'hui, il continuera presque certainement à lui faire confiance une fois que le calendrier entrera dans la fenêtre d'expiration. Les installations Linux existantes, avec leur shim et leurs chargeurs de démarrage existants, continueront de démarrer comme elles l'ont toujours fait. Rien ne se brisera magiquement à minuit.

Voici le problème

Le problème n'est pas votre chaussure actuelle; c'est votre chaussure future. Si le micrologiciel de votre ancien PC n'obtient jamais les clés 2023, et que le reste du monde commence à supposer que ces clés existent, vous pourriez vous retrouver coincé dans un étrange entre-deux. Bien que votre installation Linux existante puisse toujours démarrer, une nouvelle distribution ou une distribution mise à jour ne le pourra pas.

Espérons que le vendeur de votre PC expédiera le firmware avec les nouvelles clés, que les distributions Linux mettront à jour leurs shims pour être compatibles avec les nouvelles clés, et que tout fonctionnera bien. Nous devrions avoir autant de chance.

Voici quoi faire :

1. Mettez à jour votre micrologiciel

Chaque grand fournisseur a expédié des mises à jour qui, entre autres, ajoutent ou ajustent les clés de démarrage sécurisé en réponse aux certificats 2023 de Microsoft et aux expirations à venir. Vous n'avez pas besoin de connaître les identifiants exacts des clés pour en bénéficier ; vous devez vous assurer que votre système reçoit ces mises à jour.

Sur un ordinateur Linux typique, cette approche signifie vérifier le site de support de votre fournisseur pour les mises à jour du BIOS/UEFI publiées au cours de la dernière année ou des deux dernières années. Sur de nombreux systèmes, vous pouvez utiliser la pile de mise à jour du microprogramme de Linux, fwupd, pour gérer cela depuis votre distribution. Pour effectuer cette étape, exécutez les commandes suivantes en tant qu’utilisateur root :

fwupdmgr actualiser
fwupdmgr obtenir-mises à jour
mise à jour fwupdmgr

Si votre matériel est pris en charge, ces étapes téléchargeront des capsules de microprogramme et des mises à jour UEFI db/dbx qui incluent les nouveaux certificats de démarrage sécurisé Microsoft. Après la mise à jour, vous devrez redémarrer une ou deux fois; le microprogramme se mettra à jour lui-même, et vous aurez terminé.

Sur certains systèmes plus anciens, vous devrez peut-être encore télécharger un .exe ou .iso auprès du fournisseur et suivre leur procédure. Cette démarche est ennuyeuse, mais c’est une corvée unique qui vous garantit des années de fonctionnement plus fluide de Secure Boot.

2. Vérifiez comment votre distribution gère les certificats

La plupart des distributions Linux grand public ont déjà pris en compte l'expiration de 2026 et ont conclu qu'il ne s'agit pas d'une urgence, mais de quelque chose à traiter avec précaution.

De nombreuses distributions alignent leurs constructions de shim et leurs processus de signature pour rester compatibles tout au long de la transition. Si vous utilisez une version récente d’une distribution reconnue et que votre firmware est à jour, il est fort probable que « ça fonctionne simplement » continuera d’être vrai.

Pour vous, le test le plus simple est aussi le plus pratique :

Téléchargez un ISO actuel de votre distribution et écrivez-le sur une clé USB.
Sur une machine avec le démarrage sécurisé activé et le firmware récemment mis à jour, essayez de démarrer avec la clé USB.
Si cela fonctionne correctement, votre combinaison de clés de micrologiciel et de signature de distribution est correcte, et vous êtes prêt à partir.

Faites ce test une fois maintenant, afin de savoir à quoi ressemble la nouvelle norme. Si une image future ne parvient pas à démarrer avec Secure Boot activé, vous pourrez déterminer si la régression se situe dans le firmware (clés non mises à jour), dans l'image de la distribution, ou dans une interaction problématique entre les deux.

Beaucoup des distributions Linux les plus populaires ont déjà résolu le problème du démarrage sécurisé. Red Hat a publié des guides dédiés sur l'expiration du démarrage sécurisé et maintient des piles shim/bootloader RHEL/Fedora qui sont signées et alignées avec le modèle de confiance de Microsoft. La famille Ubuntu de Canonical propose depuis longtemps un support complet du démarrage sécurisé. Les installateurs et noyaux actuels d'Ubuntu sont signés sous l'actuelle CA UEFI tierce de Microsoft.

SUSE et openSUSE sont également prêts à utiliser les nouvelles autorités de certification (CA). L'infrastructure de Secure Boot de Debian est importante parce que son shim est utilisé par de nombreuses distributions et a été développé par une équipe inter‑distribution. Certaines distributions Linux, cependant, comme Arch et ses dérivés, ne facilitent pas la prise en charge de Secure Boot.

La solution de contournement tentante

Si vous traînez assez longtemps sur les forums Linux, vous verrez le même conseil répété chaque fois que le démarrage sécurisé est mentionné : « Si cela vous cause des problèmes, désactivez simplement le démarrage sécurisé. »

Je comprends. Je l'ai fait moi-même. Secure Boot a été un problème depuis qu'il est apparu pour la première fois. Pour de nombreux utilisateurs, la solution la plus simple a été de le désactiver et de faire disparaître le problème.

Le danger survient lorsque le bricolage temporaire devient permanent. Avec le démarrage sécurisé désactivé, vous perdez la défense du démarrage sécurisé contre les rootkits et autres. Alors que les rootkits de type « script‑kiddie » sont moins courants qu'il y a dix ans, les rootkits modernes au niveau utilisateur, noyau et même hyperviseur sont toujours très utilisés par les criminels et les attaquants sophistiqués. Les rootkits restent l'une des catégories de logiciels malveillants les plus redoutables car ils misent sur la furtivité et la persistance.

Le démarrage sécurisé est-il une solution miracle? Non. Remplace-t-il une bonne hygiène système, les correctifs et les sauvegardes? Absolument pas. Mais le démarrage sécurisé est un bouclier significatif, et l'écosystème Linux a travaillé dur pour le rendre en grande partie invisible aux utilisateurs quotidiens. Jeter le démarrage sécurisé simplement parce qu'il est gênant aujourd'hui est une erreur.

Voici, précisément, ce que vous devriez faire concernant les certificats expirants.

Pour vos PC :

Mettre à jour le microprogramme : Avant la mi‑2026, installez les dernières mises à jour du BIOS/UEFI de votre fournisseur. Si fwupd prend en charge votre matériel, utilisez-le. C'est moins pénible que de jongler avec les outils Windows ou les programmes de mise à jour amorçables.
Vérifier que le démarrage sécurisé fonctionne toujours : Assurez-vous que votre distribution actuelle démarre correctement avec le démarrage sécurisé activé. Essayez ensuite une image live actuelle de la même distribution. Si les deux fonctionnent, vous êtes en bonne forme.
Laissez le démarrage sécurisé activé, si vous le pouvez : Considérez-le comme une partie normale de la posture de sécurité de votre système. Si quelque chose échoue, effectuez un dépannage et désactivez-le temporairement si nécessaire, mais ne l'abandonnez pas à la légère.

Pour vos serveurs :

Inventoriez ce que vous avez : Notez quelles machines ont le démarrage sécurisé activé et quel firmware elles utilisent. Vous n'avez pas besoin d'une base de données de gestion de configuration (CMDB) sophistiquée ; une feuille de calcul suffit.
Standardisez sur une version de firmware de référence : Choisissez les versions de firmware actuelles qui incluent les nouvelles clés Secure Boot (les notes de version de votre fournisseur peuvent le mentionner) et déployez-les dans tout votre laboratoire.
Testez les nouvelles images tôt : Avant de mettre à niveau tout votre système vers une nouvelle version majeure de distribution, testez l'installateur et la chaîne de démarrage de cette version sur un système représentatif avec Secure Boot activé, pour éviter les surprises sur un nœud sacrificiel.

Donc, en bref, bien que ce Secure Boot soit un casse-tête, ce n'est pas si grave. Assurez-vous simplement que votre micrologiciel est à jour et que votre distribution Linux est prête à gérer les nouveaux certificats, et tout ira bien.