Normalement, sous Linux il n’y a pas besoin des certificats microsoft.
D’ailleurs sur mon ordinateur, je n’ai aucune clef microsoft.
Par contre j’ai des clefs du constructeur de ma carte mère ASUSTek.
Pour voir vos clefs, il faut utiliser l’utilitaire mokutil.
Pour l’installer:
apt install mokutil
Pour visualiser les clefs PK:
mokutil --pk
Celle ci est unique chez moi, de ASUSTek
Pour les clefs KEK:
mokutil --kek
Là j’ai encore de l’ASUSTek et du Microsoft (je suis en train de voir pour les supprimer, étant donné que je n’utiliserais plus jamais Microsoft).
Les clef DB:
mokutil --db
Pareil ASUSTek et Microsoft
Pour les clefs DBX:
mokutil --dbx
Clef dont le owner est Micorosft (une des clefs db).
Pour information, une de mes clef KEK Microrostf est invalide depuis janvier, sans aucun impact sur mon système et le fonctionnement de mon ,PC.
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
*******
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
Validity
Not Before: Jun 24 20:41:29 2011 GMT
Not After : Jun 24 20:51:29 2026 GMT
Sur les vieux PC, la question ne se pose quasiment pas car ils n’y a pas le plus souvent de secure boot.
Les mises à jour du BIOS peuvent mettre à jour ces clefs.
Attention, pour ce qui est de la signature DKMS, ou de vos executable uefi et les modules du kernel, ce ne sont pas ces clefs qui sont utilisées, mais celles qui sont listées avec:
mokutil --list-enrolled
D’ailleurs, c’est là que vous verrez la clefs Debian, enrollée lors de l’instalaltion:
[key 1]
Owner: *******
SHA1 Fingerprint: *******
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
*******
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Debian Secure Boot CA
Validity
Not Before: Aug 16 18:09:18 2016 GMT
Not After : Aug 9 18:09:18 2046 GMT
Subject: CN=Debian Secure Boot CA
Subject Public Key Info:
Chez moi, j’ai ma propre clef, ce qui fait que je n’utilise pas la clef Debian:
Owner: ******
SHA1 Fingerprint: ******
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
18:51:7a:00:62:bc:c2:0c:c0:20:0c:42:5d:2e:43:77:65:de:0e:73
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=FR, ST=***, L=***, O=******, OU=Secure Boot Cert, CN=******
Validity
Not Before: Jan 25 00:00:00 2026 GMT
Not After : Jan 25 00:00:00 2056 GMT
Subject: C=FR, ST=***, L=***, O=******, OU=Secure Boot Cert, CN=******
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Pour le fun, j’ai regardé mes PC dont aucun n’est sous µ$oft 
Le plus récent a les 2 : CA 2011 et CA 2023.
Les autres ont au mieux le CA 2011 ou rien.
Il faut faire attention par contre aux clefs constructeurs, car elles peuvent avoir servit à valider les bios, et donc les mises à jour du bios.
Celles-ci sont encore plus importante que les clefs microsoft.
Pour le moment le shim-signed de bookworm-backport n’est pas signé par CA2023, seulement par CA2011, c’est ennuyeux à moyen terme pour faire une clef boutant sur toute machine d’autant plus que désormais, avec bitlocker activé par défaut, enlever le secure boot d’une machine windows torpille le démarrage à venir sous windows y compris si on remet le secure boot.
Si les constructeurs ne sont pas trop idiots, ils proposeront des « mises à jours » des Certificats dans les UEFI.
J’ai déjà vérifié pour deux modèles de marque Lenovo via les numéros de série.
Mais je n’ai pas le souci des « dual-boot » car je n’en ai pas.
Clevo NS5x_NS7xAU, encore sous bookworm, bientôt… sous Trixie en dual-boot
mokutil --db
indique: Not After : Oct 19 18:51:42 2026 GMT
à quoi correspond --db, et que faire de cette information?
Que peut-il se passer le 19 octobre à 18h52 ?
De quelle clef s’agit-il? si c’est Microsoft, et que tu n’as pas windows sur cette machine, ça n’aura aucun effet normalement.
Sinon, la sécurité sera simplement dégradée, mais à terme elle peut ne plus fonctionner du tout.
Microsoft va normalement déployer des mises à jour qui vont mettre à jour le secure boot aussi.
D’une façon générale, faite très attention aux différents site qui proposes des solutions pas forcement toute correcte. Sur Windows, Microsoft déploie les mises à jour; donc ne faites rien d’autre.
Pour Linux pas d’impact (j’ai déjà un certificat à date dépassé sans impacts car n’ayant pas Windows, ces certificat ne me servent pas).
Je n’ai aucune idée de tout ça, c’est en lisant ce nouveau fil que je suis allé voir.
Je n’ai jamais eu windows, mais le vendeur avait utilisé ubuntu pour son installation de Debian (j’avais trouvé des traces sous ce nom). Il pourrait correspondre à un firmware, car j’ai perdu au moins quelques commandes pour gérer l’éclairage du clavier en réinstallant moi-même Bookworm)
bref je suis dans le noir complet sur cette question
dans ce sujet, ceci n’a rien à voir. Les éclairages de clavier nécessitent souvent une configuration manuelle post installation du système.
En regardant de plus près:
mokutil --db | egrep -i 'Issuer|not after'
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
Not After : Oct 19 18:51:42 2026 GMT
CA Issuers - URI:http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
Not After : Jun 27 21:32:45 2026 GMT
CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt
Issuer: CN=Secure Certificate
Not After : Dec 31 23:59:59 2039 GMT
Issuer: CN=Cus CA
Not After : Dec 31 23:59:59 2039 GMT
Donc pour 2026, que du microsoft.
Pour une utilisation perso, je vais même pas regarder ni essayer de creuser le sujet.
Si je suis impacté, on aura plus d’infos et je pense qu’il n’y aura pas de problème pour trouver la procédure adéquat.
Ce qui peut être gênant, ça peut être pour ceux qui aident à l’utilisation de linux certaines personnes.
Je viens de voir https://github.com/fwupd/fwupd/issues/9731
est-ce que ça pourrait être une solution ?
Donc si j’ai bien compris, si on n’utilise pas Windows, on s’en fout ?
Non non :
- Sans le Microsoft UEFI CA 2023 , les distributions Linux (GRUB, shim) et les applications EFI tierces échoueront à charger.
Un ordinateur non préparé affichera au démarrage des messages du type « Secure Boot violation » empêchant complètement le lancement du système d’exploitation.
je ne suis pas d’accord, car la distribution linux n’est pas signée avec Microsoft.
La seule chose qui peut impacter c’est au niveau du bios, où si des modules sont des modules microsoft il peut y avoir un impact.
j’ai un tuto à étudier avec d’autres documents techniques qui permettent de faire en sorte de ne plus avoir Microsoft y compris dans le secure boot.
Pour avoir fait le test, je n’ai aucun fichier sur mon installation linux qui ne soit signé par Microsoft à aucun niveau que ce soit.
Cette affaire est exactement du même type que le soit disant bug de l’an 2000
Tout va bien sur mon Thinkpad, j’ai 0 certificat dedans 
Ca veut dire que ton secure boot n’est pas activé ou qu’il est en mode dégradé (ou éventuellement en mode maintenance).
OK.
Si une commande comme mokutil --db répond EFI variables are not supported on this system, on s’en fout ?
C’est juste que j’ai vidé les clefs lors d’une installation.