Preuve s’il en est que Debian n’a pas besoin des clefs Microsoft 
Quand je vous dit que ce n’est qu’un remake de la daube de l’an 2000 
complètement, ca veut dire que tu n’es pas en UEFI
²
Bien sur que si, le shim-signed est signé avec la clef microsoft 2011 actuellement:
/tmp]$ sbverify --list /media/francois/61B9-05E6/EFI/BOOT/shimx64.efi
warning: data remaining[833960 vs 960080]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
[/tmp]$ Cela est indispensable pour bouter une clef live sur une machine avec le secure boot. Il est probable que les mises à jour à venir vont mettre un shimx64.efi signé avec le nouveau certificat. Ça ne fonctionne pas comme les certificats des sites, le 26 juin 2026, il ne se passera rien, le certitificat 2011 sera encore utilisé pour valider les noyaux, simplement il ne sera plus utilisé pour signer des nouveaux noyaux windows. Cela signifie juste que les noyaux windows signés après cette date ne fonctionneront pas avec les anciennes machines sans rajout du cettificat. En ce qui concerne linux, la compatibilité descendante fait que pendant pas mal de temps, les noyaux seront signés avec les deux certificats. Bref, pour moi rien à faire si ce n’est prendre un café et attendre tranquillement sans souci pendant qques années.
Ta machine est en multi-booTourst? sous Grub? c’est pour ça que tu as microsoft. Sans multiboot avec Windows il n’y a aucune raison que ce soit signé avec Microsoft. Ou alors tu utilises les fichiers par defaut (comme BOOTX64.efi).
D’ailleurs quand tu utilise UKI et systemd-boot, il n’y a pas de signature Microsoft:
- BOOTX64.efi a les signature microsoft parce que c’est mis par défaut dans la structure UEFI.
- shimx64.efi ne prend que ce qui lui est demandé:
Lié à Grub:
sbverify --list /mnt/boot/efi/EFI/debian/shimx64.efi
warning: data remaining[831016 vs 957136]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
Sans GRUB avec systemd-boot:
~# sbverify --list /mnt/boot/efi/EFI/systemd/systemd-bootx64.efi
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2024 - 20425036 - systemd-boot
issuer: /CN=Debian Secure Boot CA
Avec UKI (anonymisé car ce sont mes propres clefs/certificats de signature):
~# sbverify --list /mnt/boot/efi/EFI/Linux/debian.efi
signature 1
image signature issuers:
- /C=FR/ST=*/L=*/O=*/OU=Secure Boot Cert/CN=*
image signature certificates:
- subject: /C=FR/ST=*/L=Tours/O=*/OU=Secure Boot Cert/CN=*
issuer: /C=FR/ST=*/L=*/O=*/OU=Secure Boot Cert/CN=*
Hors grub et fichier UEFI standard, et éventuellement multiboot avec windows, il n’y a aucune signature microsoft. (sur ce type d’installation, sans GRUB et sans Multiboot, j’ai fait plus de 300 tests).
C’est d’ailleurs une des (nombreuses) raisons qui m’ont fait définitivement abandonné GRUB.
Et c’est aussi pour ça que je dit que cette histoire est un piège du même ordre de grandeur que le soit disant bug de l’an 2000.
Non, j’ai fait une clef (clef distribué par l’association APESAM), clef live contenant des logiciels utiles à l’enseignement en Maths, Physique, SI, SNV, FLE, Info ainsi que des éditeurs, etc. Cette clef doit bouter sur toutes les machines quelles qu’elles soient. Je suis donc tenu de mettre un système de boot validé par le BIOS donc signé par microsoft. Microsoft a signé le shimx64 qui lui vérifie la signature des noyaux (si j’ai bien compris). Ce shim est fourni par le paquet shim-signed (il y a aussi un shim-unsigned) qui lui démarre les noyaux debian. Il me faut cette signature microsoft pour que cette clef puisse marcher sur les PCs classiques vieux ou récents voire très récents, et ce, sans y toucher.
Sur ma machine, je m’en tape, je n’ai pas le secure boot et je compile mon noyau. Je n’ai pas eu de machine sous windows depuis 1999.
L’amusant est qu’on peut faire une clef live boutant sur des PC X86_64, des machines AARCH64 (arm 64bits) dont les raspberry (qui sont particuliers). En revanche, si la clef démarre sur des Mac Intel, Apple a définitivement écarté toute méthode pour démarrer une clef linux sans avoir installé un truc sur les Mac arm64.
Le boot de la clef ne concerne que la clef.
du média sur lequel le démarrage se fait.
Non là le système s’en balance car sans secure boot, il n’y a aucune vérification des signature. Après tout dépend ce que tu appelles ancien 
J’avoue que pour moi MAC n’est utilise que pour se la péter sur une étagère, ce depuis que le macintosh et ses copains de l’époque n’existent plus.
Le truyc qu’il faut comprendre c’est que si tu installes un système avec secure boot qui utilise une signature microsoft , c’est parce qu’un paquet ou une copie directe de fichier l’y a mis.
Le processus d’installation ne le fait en aucun cas.
Ce qui fait que si tu signes tes fichier .efi avec ta clef/certificat, tu peux dégommer Microsoft aussi sec sans impact.
Cependant, il faut faire très attention car le chargement d’un système de démarrage va charger d’abord le noyau EFI avant de charger l’autre noyau efi qui lui lancera le système.
C’est là que la difficulté apparaît.
Il faut d’assurer d’avoir ses propres certificats dans les diverses bank du secure boot avant de faire l’opération de suppression des certificats microsoft.
Ce n’est pas compliqué mais il faut être méticuleux et bien respecter la chaine des opérations.
Autre petit aspect: l’utilisation de clefs microsoft implique que tout le monde a la même dans le KEK par exemple.
Ben il est installé avec le paquet shim-signed:
[/]# sbverify --list .//usr/lib/shim/shimx64.efi
warning: data remaining[824320 vs 950440]: gaps between PE/COFF sections?
No signature table present
[/]# sbverify --list .//usr/lib/shim/shimx64.efi.signed
warning: data remaining[833960 vs 960080]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
root@talon:/# dpkg -S /usr/lib/shim/shimx64.efi.signed
shim-signed:amd64: /usr/lib/shim/shimx64.efi.signed
root@talon:/# Encore une fois, je n’ai pas loisir de modifier les machines qui vont faire tourner cette clef, elles sont au Sénégal, en Ouzbékistan, au Liban, etc. Pire, apparemment désormais si tu enlèves et remet le secure boot avec Windows 11, ce dernier activant par defaut Bitlocker, au reboute la machine te demande la clef du Bitlocker. Ça avait mis dans la panade plusieurs personnes. Mon but est que la clef démarre sur une machine avec n’importe quoi dessus (donc windows 11) sans qu’il n’y ait autre chose à faire que d’avoir le menu de boot et il est atteint avec juste l’installation de grub+shim-signed avec les noyaux debian (signés) (backport ou non)
Dans ma boite, 1200 personnes ont été affectées.
C’est une malfaçon de Microsoft dans des mises à jour d’octobre dernier et de janvier.
Nuls mais constants, conformes aux attendus.
OK.
Si j’installe shim-signed et toutes ses dépendances (grub-efi-amd64-bin…), ça ne va pas mettre le binz dans mon démarrage ?
Ca ne sert à rien si tu n’es pas en EUFI.
Et je crois (à vérifier) qu’en installant shim ça va modifier tes paquets GRUB et donc ton installation GRUB.
Ça change juste le binaire shimx64.efi dans la partition boot en la remplaçant la version unsigned par la signed. C’est en amont de grub, donc ça ne change rien sur la config.
Je viens de faire un petit check de mon système maintenant que j’y vois un peu plus clair dans tout ça. Voici les clés PK, KEK et DB installées sur mon système :
$ mokutil --pk --short
ecd988462e ASUSTeK MotherBoard PK Certificate
$ mokutil --kek --short
297643592d ASUSTeK MotherBoard KEK Certificate
31590bfd89 Microsoft Corporation KEK CA 2011
76a0920658 Canonical Ltd. Master Certificate Authority
$ mokutil --db --short
16b36b31bb ASUSTeK MotherBoard SW Key Certificate
62b51ed2e6 ASUSTeK Notebook SW Key Certificate
46def63b5c Microsoft Corporation UEFI CA 2011
580a6f4cc4 Microsoft Windows Production PCA 2011
76a0920658 Canonical Ltd. Master Certificate Authority
En clair, mes clés Microsoft sont seulement celles de 2011, je n’ai pas celles de 2023.
Actuellement, je démarre en secure boot par la séquence :
EFI > shim > grub > vmlinuz-6.12.74+deb13+1-amd64
Si je regarde la signature de mon shim :
$ sudo sbverify --list /boot/efi/EFI/debian/shimx64.efi
warning: data remaining[831016 vs 957136]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
Il est signé par la clé Microsoft de 2011 : tout à fait normal, c’est grâce à ça que la séquence EFI > shim se passe bien. Suivons la chaîne. À partir du moment où shim est lancé, on peut utiliser les clés MOK, que je consulte ici :
$ mokutil --list-enrolled --short
53610cf81f Debian Secure Boot CA
Ce qui permet de lancer grub dont la signature est :
$ sudo sbverify --list /boot/efi/EFI/debian/grubx64.efi
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2022 - grub2
issuer: /CN=Debian Secure Boot CA
On passe donc sans encombre le maillon shim > grub de la chaîne de confiance. Suivons encore un maillon, voici comment est signé mon noyau :
$ sbverify --list /boot/vmlinuz-6.12.74+deb13+1-amd64
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2022 - linux
issuer: /CN=Debian Secure Boot CA
Même signature que grub, reconnue dans les clés MOK de shim. J’ai donc AUJOURD’HUI tout ce qu’il faut pour suivre ma séquence de bout en bout :
EFI > shim > grub > vmlinuz-6.12.74+deb13+1-amd64
Et maintenant, qu’est-ce qui va se passer le 24/06/2026, date d’expiration de ce fameux certificat Microsoft 2011 ? Je lis diverses choses à ce sujet.
- Pour certains, le secure boot de l’UEFI refusera de lancer un shim signé par un certificat expiré
- Pour d’autres, la péremption n’empêchera pas le lancement de shim, mais la signature de la prochaine version post 24/06/2026 sera faite par Microsoft avec la clé issue en 2023.
Quelle que soit la vraie réponse, ce qui est sûr c’est que ça finira par arriver. Ce jour-là (ou avant, si j’anticipe un peu et ne procrastine pas trop), j’aurai le choix entre :
- Installer la clé Microsoft 2023 sur mon système
- Changer ma séquence de boot pour n’utiliser que des softs n’ayant pas besoin des clés Microsoft
- Enlever le secure boot
Je pense plutôt aller vers le deuxième choix. Ce qui me fait me poser une question : techniquement, qu’est-ce qui m’empêcherait dès aujourd’hui d’installer la clé Debian directement dans les clés DB de mon système, et d’utiliser une séquence de boot comme ceci ?
EFI > grub > vmlinuz-blabla
Edit : ah je pense pouvoir répondre moi-même à ma question : c’est parce que je n’ai aucune clé KEK qui se porterait garante d’une clé Debian en DB ?
Pas de soucis à te faire pour les clef Debian. Il y aura des mises à jour.
Idem pour shim-signed.
C’est bien ce que je crains, les futures versions de shim-signed seront signées avec la clé Microsoft 2023 que je n’ai pas encore.
Quel est le problème?
Ben il faut juste que je m’y mette un de ces quatre :
Je viens de tester sur une VM Virtualbox le lancement du système sans aucune signature microsoft sur shim debian.efi et sur BOOTX64.efi (copie de shim).
Ca marche très bien, aussi bien en systemd-boot, qu’en UKI.
Je n’utilise plus GRUB, mais fondamentalement il n’y a pas de raison d’échec.
Je parle ici d’une machine qui n’a pas Windows d’installé et qui ne l’aura jamais, car je n’utilise plus windows. La dernière partition existant est sur mon portable, et je pense la virer bientôt.
~# find /boot/efi/EFI -name '*.efi' -type f -exec sbverify --list {} \;
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2024 - 20425036 - systemd-boot
issuer: /CN=Debian Secure Boot CA
warning: data remaining[823928 vs 950048]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /O=toto Org/OU=toto UEFI Cert 2026/CN=toto.org
image signature certificates:
- subject: /O=toto Org/OU=toto UEFI Cert 2026/CN=toto.org
issuer: /O=toto Org/OU=toto UEFI Cert 2026/CN=toto.org
warning: data remaining[73664 vs 87888]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2022 - shim
issuer: /CN=Debian Secure Boot CA
signature 1
image signature issuers:
- /O=toto Org/OU=Secure Boot Cert/CN=toto.org
image signature certificates:
- subject: /O=toto Org/OU=Secure Boot Cert/CN=toto.org
issuer: /O=toto Org/OU=Secure Boot Cert/CN=toto.org
warning: data remaining[823928 vs 950048]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /O=toto Org/OU=toto UEFI Cert 2026/CN=toto.org
image signature certificates:
- subject: /O=toto Org/OU=toto UEFI Cert 2026/CN=toto.org
issuer: /O=toto Org/OU=toto UEFI Cert 2026/CN=toto.org
warning: data remaining[73664 vs 87888]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2022 - shim
issuer: /CN=Debian Secure Boot CA
warning: data remaining[732096 vs 850176]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2022 - shim
issuer: /CN=Debian Secure Boot CA
Cependant, je n’ai pour l’instant supprimé Microsoft que de la base DB de Secure Boot:
root@machine:~# mokutil --pk | grep -i 'Subject:'
Subject: C=US, ST=California, L=Redwood City, O=Oracle Corporation, OU=VirtualBox, CN=UEFI PK
root@machine:~# mokutil --kek | grep -i 'Subject:'
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
Subject: C=US, O=Microsoft Corporation, CN=Microsoft Corporation KEK 2K CA 2023
root@machine:~# mokutil --db | grep -i 'Subject:'
Subject: OU=toto UEFI Cert 2026, CN=toto.org
Pour le moment je passe par le BIOS pour enroller mon certificat et pour supprimer les certificats Microsoft.
Il ne me reste plus qu’à remplacer le certificat PK et le(s) KEK.
Le test montre aussi qu’il est impératif de mettre un mot de passe sur le bios, car il est possible de tout modifier sans limites (bien qu’en respectant le format DER, mais sans avoir besoind e la clef privée pour valider).
Par la même occasion je conserve les certificats des constructeurs (Oracle VirtualBox pour les VM, ASUS par exemple pour une machine).
Mais ça s’annonce bien
Très bonne analyse.
Je vais refaire un tour sur les PC de la maison.
Mais je ne pense pas être impacté.
Merci Zargos, j’ai quelques petites questions STP :
- Sur ton système, que donne la commande
mokutil --list-enrolled --short? Je suppose qu’il y a juste le certificat Debian ? - Sur ta commande
findje ne vois pas à quel fichier .efi sont attachées les signatures, as-tu moyen de nous les donner ? Si je compte bien, tu as 4 fichiers .efi - Comment as-tu fait le shim sans signature Microsoft ? Compilation maison + signature perso ?
Merci d’avance !