Auteur Sujet: Expiration des clés Secure Boot de 2011: Les impacts pour Linux (Lu 267 fois)

vivien · « **le:** **Aujourd'hui** à 09:27:12 »

Le 24 juin 2026, les anciennes autorités Secure Boot de 2011 expirent !

L'expiration des certificats de démarrage sécurisé Microsoft émis en 2011 (notamment l'autorité Microsoft Corporation UEFI CA 2011, qui arrive à échéance le 24 juin 2026) pose une question cruciale pour les utilisateurs Windows, mais aussi Linux. Par exemple, Ubuntu s'appuie historiquement sur ce certificat pour signer son chargeur de démarrage initial (shim).

Il faut ajouter les clés Microsoft UEFI CA 2023, via une mise à jour du BIOS / UEFI.

Dell par exemple indique la version minimum du BIOS pour prendre en chrage CA 2023 sur cette page.

Sous Linux, comment savoir si CA 2023 est installé ?

Il suffit de lancer dans un terminal la commande mokutil --db | grep "Subject:" (ou mokutil --kek | grep 'Subject:')

Si "Microsoft UEFI CA 2023" apparaît, vous êtes déjà protégé.

Quels sont les impacts d'une absence des certificats Microsoft 2023 pour Linux ?

À court terme : Aucun blocage immédiat du démarrage. Tant que les fichiers actuels (shim, grub, noyau) ne changent pas et sont signés avec la clé 2011, la plupart des micrologiciels UEFI continueront de charger les distributions Linux normalement, car ils ne bloquent pas activement les certificats expirés pour le boot existant.

Les limitations vont venir quand les distributions Linux vont cesser de signer leurs chargeurs de démarrage (shim) avec la clé de 2011 obsolète et utiliseront exclusivement la clé 2023. Cela pourait arriver dans les prochaines semaines. Canonical Annonce que Ubuntu 26.04.1 (mise à jour mineur qui sort en aout 2026) pourraient nécessiter l'autorité de certification 2023.

Conséquence : Si vous tentez d'installer une future version de Linux (ou de mettre à niveau vers une version majeure) qui intègre un shim exclusivement signé en 2023, votre PC affichera une erreur de violation de sécurité au démarrage. Pour votre Linux actuel, il ne recevra plus de mises à jour de sécurité pour le chargeur de démarrage shim sans le CA 2023. De ce fait, il ne sera plus possible d'appliquer les mises à jour aux autres composants de la pile de démarrage, ce qui pourrait permettre des attaques par rétrogradation sur des éléments tels que GRUB ou fwupd.

Si votre machine ne reçoit plus de mises à jour de BIOS/UEFI de la part du fabricant pour injecter les clés 2023, le plus simple est de désactiver le Secure Boot : En désactivant le Secure Boot dans les paramètres UEFI (BIOS) de votre PC, vous contournez complètement la vérification des certificats Microsoft. Linux démarrera et se mettra à jour sans aucune restriction.

C'est une opération qui se fait en allant dans les paramètres UEFI de votre PC. Canonical, l'éditeur d'Ubuntu, a prévu de publier prochainement des instructions à ce sujet.

Il est aussi possible d'injecter manuellement les nouvelles clés de 2023 dans la base de données de la carte mère, mais c'est souvent compliqué à réaliser.

Sylv_01 · « **Réponse #1 le:** **Aujourd'hui** à 09:32:08 »

Bonjour vivien, merci pour l'info...
Il faut que je vérifie sur mon Dell Inspiron qui est en dual-boot, mais il est relativement récent (2024 je crois

), donc ça devrait aller.

vivien · « **Réponse #2 le:** **Aujourd'hui** à 09:37:00 »

Attention, un PC acheté récemment peut aussi avoir un BIOS qui n'est pas de toute dernière génération.

Exemple avec ce PC Core i7-12700 :

Paul · « **Réponse #3 le:** **Aujourd'hui** à 09:52:25 »

Je suis au courant, et embêté parce que j'ai évidemment encore une partie de matériel dans mon lab qui n'a plus de mises à jour d'UEFI depuis de très longues années. Il existe un outil qui permet d'enregistrer les nouveaux certificats dans un UEFI sans le mettre à jour, du moment qu'il a un mode écriture : Mosby

J'ai mis ça sur une clé mais impossible de démarrer l'utilitaire en exécutant mosby dans le terminal UEFI. J'ai dû rater quelque chose mais je persisterai, comme ça urge.

Si on a un parc Proxmox, on est vernis parce qu'ils ont prévu la fonctionnalité il y a quelques mises à jour. Il faut juste redémarrer la VM.

J'ai une mise à jour d'UEFI à faire sur mon PC portable AORUS de 2022, la première depuis 3 ans, ça doit concerner ça.

seb30 · « **Réponse #4 le:** **Aujourd'hui** à 14:24:02 »

Hello,
même problème de mon coté, sur une vieille carte mère, il semblerait possible avec les utilitaires mokutil et/ou efivars de mettre a jour les clef Microsoft disponibles sur github.
Mon bios n'a pas les fonctions de mise ajour de clef intégrées, il a seulement un mode user ou setup+effacement des clef.
Pas encore réussi à tout mettre a jour, les clef KEK et la db semblent ok mais impossible d'ecrire la clef PK...
Et je ne sais pas comment repasser en mode user sans écrire les clef d'origine !

Trellen · « **Réponse #5 le:** **Aujourd'hui** à 15:02:52 »

la PK n'est pas fourni par Microsoft mais par le fabricant de ta carte mère, si tu mets à jour la KEK et les db BD et BDX de Microsoft sans mettre à jour la PK tu ne pourras plus mettre à jour la KEK ni rien ajouter dans les DB(X) une fois la date passée. (en théorie, j'ai ouïe-dire que certains uefi ignoraient la date des certificats)

Citation de: seb30 le Aujourd'hui à 14:24:02

Mon bios n'a pas les fonctions de mise ajour de clef intégrées, il a seulement un mode user ou setup+effacement des clef.

en général pas besoin du mode setup, tu peux mettre à jour les clés/DB avec les fichiers .auth qui sont signés (à partir des fichiers .esl qui eux requièrent une PK valide + mode setup) directement depuis linux (je ne connais pas windows)

Citation de: seb30 le Aujourd'hui à 14:24:02

Et je ne sais pas comment repasser en mode user sans écrire les clef d'origine !

ça dépend de l'uefi car certains t'empêchent de te mettre un état "à risque" type KEK/DB/DBX mis à jour sans PK, je recommande d'utiliser tes clés s'il n'y a plus de maj uefi pour ta carte mère