Connexion Premium

Secure Boot sous Windows et Linux : les certificats expirent le 27 juin, prudence

Prudence est mère de sûreté

Secure Boot sous Windows et Linux : les certificats expirent le 27 juin, prudence

Illustration : Flock

Plusieurs certificats de sécurité utilisés par Microsoft et Linux pour Secure Boot arriveront à échéance cette année, dont une première vague le 27 juin. Nous faisons le point sur la situation, plus simple qu’il n’y paraît. Du moins si tout se passe bien.

Pour comprendre la situation, nous devons rappeler quelques points. Secure Boot est une fonctionnalité de sécurité du firmware UEFI dont l’objectif est d’empêcher l’exécution de code malveillant avant même que le système d’exploitation démarre, c’est-à-dire à un stade où les antivirus et autres protections logicielles classiques n’ont aucune visibilité. Les bootkits sont ainsi particulièrement dangereux, car ils s’exécutent avec un niveau de privilège supérieur à celui du système et survivent à une réinstallation complète de Windows ou Linux.

Le fonctionnement repose sur une chaîne de confiance cryptographique hiérarchisée :

  1. La PK (Platform Key), détenue par le fabricant de la carte mère ou du PC et qui contrôle l’accès au niveau inférieur
  2. La KEK (Key Exchange Key), utilisée pour mettre à jour les bases de signatures
  3. La DB (Signature Database), qui liste les certificats de confiance autorisant tel ou tel bootloader à s’exécuter
  4. La DBX (base de révocation), liste noire des signatures compromises qui bloque l’exécution de bootloaders connus comme vulnérables, même quand ils possèdent une signature valide

Pendant le démarrage, le bootloader vérifie chaque maillon de la chaine l’un après l’autre en comparant leur signature à celles présentes dans les bases mentionnées. Si l’une de ces signatures ne correspond pas ou fait partie de la liste de révocation, le firmware refuse le chargement du composant lié et interrompt le démarrage.

L’origine du problème

En 2011, Microsoft a établi trois certificats centraux : la Microsoft Corporation KEK CA 2011 pour la base KEK, la Microsoft Windows Production PCA 2011 pour les composants Windows signés, et la Microsoft Corporation UEFI CA 2011 pour les logiciels tiers, comme le rappelait Security Today en avril et Ars Technica le 17 juin.

Ces certificats disposaient d’une validité de 15 ans. Chacun a sa date d’expiration : les deux certificats Corporation (KEK et UEFI) expirent respectivement les 24 et 27 juin, le certificat Production court jusqu’au 19 octobre. Deux certificats vont donc expirer dans quelques jours, tandis que l’autre aura lieu dans quatre mois. Or, cette clé UEFI CA 2011, qui expire le 27 juin, est aussi utilisée pour la signature des bootloaders tiers, dont le « shim » de Linux, que les distributions peuvent utiliser pour se rendre compatibles avec Secure Boot.

Il reste 79% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (34)

votre avatar
Je gage que bon nombre de Linuxiens, ont secure boot desactivé.
votre avatar
Ce n'est malheureusement pas toujours possible sur certains portables DELL ou HP...
votre avatar
J'aimerais bien, mais certaines cartes mères passent en CSM si tu n'as pas le Secure Boot. Or, en mode CSM, pas de ReBAR, et les cartes graphiques Intel font alors la gueule.
votre avatar
Mais pourquoi acheter ces portables et cartes-mères du coup ? :-/
votre avatar
Parce que si ce genre de comportement est documenté, il l’est au fin fond d’un manuel lui-même perdu au fin fond du site du constructeur et qui mettra 10 minutes à être téléchargé, en admettant que quelqu’un ait envie de s’y intéresser…
votre avatar
Si je l'avais su avant, ça m'aurait évité 2 jours de debug. Mais j'avoue que, jusqu'à cet épisode, je ne regardais pas spécialement ce genre de choses dans les petites lignes de la documentation avant d'acheter une carte mère. Tu le fais, toi ? Ou tu es juste un gars normal qui ne sait même pas si, en ce moment, il tourne en CSM ?
votre avatar
"Je gage que bon nombre de Linuxiens, ont secure boot desactivé."

Pour le moment, peut-être. Mais secureboot risque de devenir obligatoire pour certaines fonctionnalités à terme, et notamment pour tout ce qui sera du linux immuable (logique, il faudra qu'ils soient signés pour avoir un intérêt).
Secureboot participe du rapprochement des ordis comme appareil de diffusion de contenu de confiance (comme le sont les smartphone non rootés). Cela leur permettrait d'avoir netflix en 4K par exemple, mais cela est travaillé par Valve depuis suffisamment longtemps avec Arch pour penser que SteamOS sera validé par un secureboot, ce qui permettra alors d'avoir une sécurisation de la diffusion et de la lecture du contenu (IE: plus besoin de DRM, et validation des steam machines en tant que machine de confiance).

Bref: pour les linuxiens hardcore: effectivement ils n'ont peut-être pas le secureboot actif (ce qui simplifie la mise à jour des pilotes nvidia par exemple) - pour ceux qui auront Linux au lieu de Windows pour utiliser leur ordi: ça va vite devenir obligatoire pour certains usages à la maison.
votre avatar
Pas moi il est activé sur mon fixe avec Bazzite. Et la maj des certif depuis l'updater de bazzite s'est faite sans aucun problème.
Par contre au boulot, suivant les versions de windows server, c'était beaucoup plus compliqué, étonnant :D
Mon portable pro sous ubuntu, aucun problème pour l'update en 1 clic, je me suis pas géné pour titiller un peu les collègues admins qui aiment windows :mdr2:
votre avatar
Je confirme. Et, seuls les Windows 11 et Server 2025 en ont réellement besoin en fait.
votre avatar
oui et on lance tout en root
votre avatar
M'enfin ?!
votre avatar
Je comprends que:

Une machine qui reçoit encore des mises à jour soit de son firmware, soit de son OS devrait récupérer les nouveaux certificats et continuer à fonctionner.

Par contre si on souhaite installer (ou peut-être utiliser) un ancien OS en secureboot, ou réinstaller une machine qui n'a pas les nouveaux certificats dans son firmware, on va avoir de gros soucis.

Si c'est le cas, ça ressemble fortement à de l'obsolescence programmé puisqu'on fixe une date de fin de fonctionnement sur un système qui est potentiellement parfaitement fonctionnel.
votre avatar
Sans parler des vieux PC pas démarrés ou maj depuis un moment.

Mais le reset est une habitude de base que je comprends aussi comme risquée après la lecture de l'article...
votre avatar
Pour ceux qui recherchent via les paramètres, voici la marche à suivre sous Windows :
Confidentialité et Sécurité / Sécurité Windows / Sécurité de l'Appareil.
Et ensuite, idem à ce qui est écrit dans l'article: Sécurité des appareils / Démarrage sécurisé
votre avatar
Dans les deux cas, la parade est la même : s’assurer, via les dernières mises à jour, que le certificat 2023 est bien inscrit, sans jamais retirer le certificat 2011 existant. Un point qui concerne bien plus les entreprises et les utilisateurs (très) avancés que le grand public.

Pour un parc en entreprise y-a-t-il un autre moyen de voir si l’entrée « Démarrage sécurité » est verte sans passer sur chaque machine ?
votre avatar
Avec une GPO qui lance "Confirm-SecureBootUEFI" en powershell et balance le résultat quelque part ? Par contre il faut que ça soit fait en tant qu'administrateur.
votre avatar
la y a un truc que je comprend pas, Windows pousse dans le bios de nouvelle clés ?
votre avatar
Et dans le cas où on a plus Windows d'installé, qui fait la MàJ des clés ?
votre avatar
De ce que j'ai pu voir, sous Linux ça passe par fwupd. Sur Fedora, c'est déjà installé (Gnome Software m'a récemment proposé la mise à jour), mais sur d'autres distributions, ça ne semble pas être le cas.
votre avatar
Via une mise à jour du BIOS, ou comme dit dans un autre post, fwupd.
votre avatar
Dans le cas d'un ordinateur privé, de plus de 10 ans, qui ne peut pas être migré sur Windows 11, ça se passe comment ? Windows 10 ne recevant plus de mises à jour, est-ce qu'il y a un risque que l'ordinateur ne puisse plus démarrer ?
votre avatar
Windows 10 continue de recevoir les mises à jour de sécurité via le programme ESU, ou si vous avez une version encore supportée (IoT LTSC par exemple).

Les mises à jour des certificats sont en fait poussées via les Cumulatives depuis mai 2023 (mises à jour de la DB) au moins, et l'ensemble des certificats (KEK + DB) sont poussées depuis mai 2025, donc si vous avez une Cumulative plus récente d'installée, vous pouvez déployer les nouveaux certificats via les étapes manuelles : support.microsoft.com Microsoft
votre avatar
Merci pour la réponse. C'est un simple Win 10 Pro installée sur mon ancienne machine de jeu mais que ma femme utilise tous les jours.
J'ai les dernières màj disponibles, mais comme il était question du "dernier patch tuesday", j'avais un doute. ("De nouveaux certificats, signés en 2023 (pour a priori 15 ans, jusqu’en 2038 donc), ont déjà été distribués via Windows Update avec le dernier Patch Tuesday.")
votre avatar
Non, l'ordinateur continuera de démarrer en t'affichant un écran rouge au démarrage comme quoi SecureBoot est désactivé et ta machine est donc non protégée contre les Rootkits.
Pas bien grave si on continue avec une bonne hygiène informatique (pas cliquer tous les liens, pas télécharger n'importe où, etc...)
votre avatar
Fedora Magazine fournit une procédure pour vérifier si on est concerné : https://fedoramagazine.org/expiration-of-microsoft-secure-boot-keys/
votre avatar
Merci, j'ai pu voir que le SecureBoot n'est pas activé et qu'il n'y a aucune clé dans le firmware.
votre avatar
J'ai reçu une mise à jour de l'UEFI sous mon Ubuntu 24.04.4 il y a une dizaine de jours.
Je suppose que lié à l'objet de l'article.

Les informations sont le logiciel Actualisateur de micrologiciel.
votre avatar
En lisant les commentaires, je me demande si j'ai bien compris : j'ai un ou deux pc assez anciens dans mon placard que je pourrais potentiellement remettre en service à l'avenir en installant linux.
Ils risquent de ne pas fonctionner ?
Que faut-il faire ?
votre avatar
Il a fallu que je secoue les puces de mon constructeur pour qu'ils mettent à jour leur page de suivi de l'édition de nouveaux BIOS… et pour mon modèle il ne sera pas disponible avant mi-juillet.

C'est fou, quand la communication d'importance existe côté M$ depuis le début d'année (et qu'ils ne sont pas connus pour leur proactivité).

Encore un autre sujet, d'une autre grosse boite, traité avec procrastination…
votre avatar
Sur ma tour, la mention de secure boot n’apparaît pas dans le centre de sécurité, donc je ne sais même pas comment vérifier xD
(CM Gigabit)
votre avatar
Pour ceux qui veulent vérifier leurs certificats ou tenter d'installer les nouveaux certificats "manuellement", il y a des scripts Powershell ici : github.com GitHub

Et les explications sont ici:https://www.elevenforum.com/t/garlins-powershell-scripts-for-updating-secure-boot-ca-2023.43423/

Sur mon vieux laptop Gigabyte Aero, windows me dit qu'il devrait être compatible, mais ne procède pas à la mise à jour car pas assez de données télémétries sur ce modèle. Le script a apparemment bien installé les nouveaux certificats. On verra à l'usage.

La mise à jour de Bios n'est en principe pas nécessaire. Mais si on se retrouve un jour sans la partition UEFI (formatagee ou changement de disque), le Bios réinstallera l'image qu'il a, avec les anciens certificats expirés, ce qui désactivera SecureBoot. Bon, je suppose qu'on pourra encore installer les nouveaux, mais ça fait des manœuvres en plus.
votre avatar
Attention à la bidouille via scripts quand on ne sait pas ce que l'on fait.
Ces scripts s'adressent explicitement à ceux qui ne sont pas dans ce cas.

La suppression du certificat de 2011 pourrait être désastreux.
Si la mise à jour M$ n'a pas couvert une installation, c'est qu'une mise à jour BIOS est nécessaire. Forcer une installation pour ces matériels peut donc aussi s'avérer désastreux.

En résumé : la bidouille en l'absence de support du fabricant est fortement déconseillé.
Ces scripts devraient vous être inutiles (sauf à vérifier l'état, ce qui peut se faire de multiples manières).
votre avatar
J'ai une machine debian serveur sur laquelle j'ai mis le BIOS à jour et je n'ai aucun moyen de mettre à jour la base de clefs.
J'ai une deuxième machine d'un modèle quasi identique sous mint et là, c'est bon, « sudo fwupdmgr update » marche.

Sur une autre machine windows, parfaitement à jour, le secure boot est activé mais la mise à jour des clefs n'a pas eu lieu pour une raison inconnue. Edit, c'était le BIOS. Il fallait effacer le TPM et remettre une config usine suite à la mise à jour du BIOS.

Edit linux:
Il semble que la version de fwupd installée change tout. C'est à partir de la version 2.0.8 que la mise à jour de la base UEFI DB est mise à jour. Mais cela n'explique pas tout

Quel bordel !
votre avatar
Pour ceux qui ont eu un problème d'activation du secure boot lié à leur carte mère (Gigabyte par exemple), et qui ont enfin le secure boot actif mais avec windows qui annonce que « ... votre appareil utilise une configuration d'approbation de démarrage plus ancienne ... », voici ce qu'il faut faire pour forcer la mise à jour des clefs KEK, DB et du chargeur sécurisé:

  • Dans le powershell en admin:


Set-ItemProperty -Path ‘HKLM:SYSTEM∖CurrentControlSet∖Control∖SecureBoot’ -Name ‘AvailableUpdates’ -Value 0x5944
Start-ScheduledTask -TaskName ‘∖Microsoft∖Windows∖PI∖Secure-Boot-Update’

  • Redémarrer le PC


Pour vérifier que la mise à jour s'est bien passée, vous pouvez refaire la manip comme dans l'article.
En cas de problème, démarrez regedit et recherchez HKEY_LOCAL_MACHINE∖SYSTEM∖CurrentControlSet∖Control∖SecureBoot∖Servicing
Les clefs UEFICA2023Status et UEFICA2023Error vont vous permettre de trouver le problème.

PS: j'ai été obligé de remplacer les antislash par le caractère 0x2216 pour qu'il s'affiche proprement. Vous ne pourrez pas juste copier coller les chemins...