Bonjour à tous.

Comme le problème est récurrent et que la question est posée régulièrement sur les topics Windows, voici un guide pour mettre à jour les certificats Secure Boot avec Mosby, un logiciel open source qui se lance sur un shell UEFI, par l'auteur de Rufus.
Mosby sait mettre à jour les certificats et les listes de révocations, mais il est aussi capable d'ajouter des certificats personnalisés (qu'il peut créer) si vous le souhaitez.

L'auteur le présente ainsi:

Voici quelques-un des intérêts à utiliser Mosby:

• Si votre Secure Boot n'a pas reçu les nouveaux certificats 2023, il ne pourra pas démarrer un OS signé avec ces clés, or le certificat 2011 arrive a expiration à la mi 2026, ce qui signifie que passé cette date il ne peut plus être utilisé pour signer les nouveaux bootloaders. Mosby sait installer les certificats 2023 sur une machine qui ne les possède pas.

• Si votre Secure Boot a reçu les nouveaux certificats 2023 via mise à jour (Windows sait le faire), mais que vous clés Secure Boot par défaut sont uniquement en 2011, alors un reset des clés Secure Boot vous empêchera de démarrer avec Secure Boot. Là aussi en utilisant Mosby, vous récupérerez un Secure Boot fonctionnel et sécurisé.

• Certains constructeurs ont été très négligents sur la PK (Primary Key, celle utilisée pour signer les autres clés), ce qui compromet la sécurité de millions de machines. Mosby installe une PK unique, qui vous appartient, elle est donc par nature bien plus sécurisée que celle de votre système par défaut, partagée par des milliers voire des millions de machines, et dans les mains de on ne sait qui...

Pour plus d'infos, rendez vous sur la page Github (en anglais): https://github.com/pbatard/Mosby

Prérequis

• Une clé USB (pour la taille, idéalement entre 64 Mo et 32 Go. Une plus grosse fonctionnera probablement aussi sauf sur certains vieux BIOS). Attention celle-ci sera formatée par Rufus, pensez à sauvegarder le contenu si besoin.
• La version la plus récente de Rufus
• La version la plus récente de Mosby
• Il vous faudra aussi connaitre la touche clavier qui permet d'accéder au BIOS, et celle qui permet de choisir le périphérique de démarrage. Ces touches varient d'une marque à l'autre, en voici une liste (miroir webarchive).

Préparation de la clé USB

• Insérez la clé USB, lancez Rufus, sélectionnez la clé USB dans la partie Périphérique si besoin, et choisissez UEFI Shell 2.2 comme ceci:

26H1 n'a rien à voir avec Windows, c'est simplement la version de UEFI Shell au moment de ma capture, par défaut il proposera la plus récente.
Si on prend la plus récente comme sur ma capture, Mosby est inclus (on peut néanmoins écraser avec le contenu de l'archive Mosby la plus récente si une version de Mosby est sortie entre-temps).
Si c'est un vieux PC qui ne démarre pas avec UEFI Shell 2.2, il faudra choisir UEFI Shell 2.0, et dans cas il faudra extraire le contenu de l'archive Mosby une fois que Rufus aura préparé la clé.

• Une fois UEFI Shell téléchargé, cliquez sur DÉMARRER en bas, cliquez sur OK sur l’avertissement de formatage, et laissez Rufus travailler.

Configuration du BIOS

• Entrez dans le BIOS et mettez Secure Boot en mode setup. La manipulation dépend de votre BIOS, en général ça se trouve dans la partie Secure Boot, Boot, ou Security

Si vous ne pouvez pas mettre Secure Boot en mode Setup, mais que vous avez l'option Other OS choisissez-là.

• Sauvegardez les changements, puis sortez du BIOS, le PC va alors redémarrer. Passez immédiatement à l'étape suivante.

Démarrage de Mosby

• Démarrez sur la clé USB, une fois sur le shell UEFI, tapez Mosby (attention le clavier est en QWERTY, en AZERTY le M se fait avec la touche ? à droite du N, le reste est inchangé), puis laissez-vous guider. Mosby va mettre à jour les certificats, révoquer ceux qui sont compromis le cas échéant, et en installer un unique si vous le souhaitez.

En répondant "No" à ce second message (demande de reboot dans le BIOS), on a le log qui s'affiche:

On voit que Mosby a généré puis installé un nouveau fichier PK, et a installé tous les fichiers DB, DBX KEK et SBAT nécessaires:

Si vous n'avez pas pu mettre le Secure Boot en mode Setup, tapez Mosby -u il va alors uniquement mettre à jour les certificats Secure Boot DBX (la base de révocation) et SBAT (vous n'aurez pas les certificats 2023 si ils ne sont pas déjà dans le BIOS mais vous aurez tout de même une sécurité accrue).

• Une fois que Mosby a terminé, retournez dans le BIOS et remettez Secure Boot dans le mode précédent (User ou Windows OS) si besoin. Sauvegardez les changement et redémarrez sur Windows.

Voilà, vos certificats sont à jour.

Conservez bien les trois fichiers MosbyKey présents sur la clé, ce sont vos clés privées pour signer vos propres certificats Secure Boot sur toutes vos machines.
Vous pouvez reformater la clé (Avec Rufus, option Non démarrable, ou avec Windows) si vous le souhaitez.

Vous pouvez suivre ce tuto pour vous assurer que les certificats 2023 sont bien installés:
Secure Boot : comment vérifier si les certificats 2023 sont bien installés sur votre PC ?

Cela consiste à coller ces trois commandes dans une invite Powershell administrateur:

Sur ma machine Windows 10, voici ce que je vois après avoir utilisé Mosby avec l'argument Mosby -u:

Vous pouvez aussi utiliser la collection de scripts Check-UEFISecureBootVariables pour vérifier (et en théorie mettre à jour) les certificats.

Voici ce que j'ai sur mon desktop Windows 10 avec le script Check UEFI PK, KEK, DB and DBX.cmd après avoir utilisé Mosby:

Sur mon laptop Lenovo, j'ai utilisé le mode Setup, et Mosby a bien installé ses propres clés, ainsi que les certificats 2023 qui n'étaient pas présents par défaut, bien que le BIOS date d'avril 2025. Il a aussi dégagé le certificat Thinkpad Product CA 2012, je suppose qu'il est expiré, ou révoqué, ou considéré comme dangereux.

Réservé.

Réservé.

Merci d'avoir créer ce topic.
Peut être qu'avant de proposer l'update des certificats, il faudrait rappeler un peu de contexte.
Peut etre décaler les messages, Umi ?
 
Pour rappeler le contexte, la version du gouvernement est propre: https://www.cert.ssi.gouv.fr/actual [...] 6-ACT-014/

Voici un exemple de résultat du script https://github.com/cjee21/Check-UEF [...] 20DBX.ps1:

Il y a tjs 2 parties:

• le "default" correspond au BIOS/UEFI, et donc 1er niveau de MAJ
• le "current" correspond au 2nd niveau, celui du système d’exploitation.

Comme je disais sur le topic Windows 10: pour ceux qui ont un PC assez récent, disons post 2020, le constructeur du PC ou de la carte mère a probablement fourni une MAJ bios/UEFI avec les certificats 2023.
Donc cas facile, où toute la chaîne peut être MAJ.
Ces PC Windows sont probablement quasi tous sous Windows 11 dans une version supportée (24h2 ou 25h2 par ex).
Les PC vraiment vieux (génération jusque Core2Duo) sans UEFI restent sous Windows 10 ou sont passés à Linux.

Et qu'importe l'OS, pour les PC entre les 2, disons ceux sortis entre ~2012 et ~2020, configurés avec UEFI et SecureBoot, mais sans MAJ post 2023 du bios, donc avec un bios/EFI dont les paramètres par défaut reste aux certificats de 2011, il y a plusieurs options:
1) SecureBoot activé avec les certifs 2023 "current", cad Windows a pu mettre à jour à ceux de 2023, bien que les "default" restent sur 2011.
2) SecureBoot activé mais en restant avec 2011 en "current", ainsi aligné sur les "default" en 2011.
3) Désactiver SecureBoot.

En théorie, 1 est recommandé et correspond à l'idéal selon Microsoft.
Sauf que c'est pas résilient: un reset bios et tout est cassé. L outil Secure Boot recovery peut réparer, cf https://support.microsoft.com/en-us [...] esolutions comme j'en parlais sur https://forum.hardware.fr/forum2.ph [...] 0#t3472003 . Cela pourrait ne pas suffire.

J'en ai fait l'expérience sur une vieille tablette (TP8 de 2014 en 32bits) passée avec les certifs 2023, mais sur laquelle les récentes MAJ win10 ont cassé le démarrage.
J'ai pu désactivé SecureBoot (sans vraiment savoir si mon pb de démarage était lié au SecureBoot).
Pour forcer manuellement le retour aux certificats 2011 (donc passer de option 1 à 2), il faut copier (par ex avec robocopy) le répertoire C:\Windows\Boot\EFI sur la partition EFI. À l'inverse, le répertoire C:\Windows\Boot\EFI_EX contient les fichiers avec les certifs 2023.

J'en viens à me dire que 3  - désactiver SecureBoot - est le plus simple.

Sur la question désactiver SecureBoot vs garder SecureBoot actif avec les certificats de 2011, j'ai posé la question sur le fil de discussion de Microsoft AskMeAnything sur SecureBoot. On m'a répondu ainsi:

tant que cela fonctionne, dans pt de vue sécurité, il reste préférable d'avoir SecureBoot actif avec les certificats de 2011 que complètement désactivé, afin de se protéger au moins de certaines vieilles attaques.
Tout cela est évidemment théorique mais chacun peut ainsi mieux mesurer ses propres risques: pour qui a son PC fixe à la maison, c est peut-être pas pertinent:

donc sur sa partition EFI (qu'on peut monter avec 'mount x: /s'), si le fichier \EFI\Microsoft\boot\bootmgfw.efi  ('dir x:EFI\Microsoft\Boot\bootmgfw.efi'):

• correspond à celui de C:\Windows\Boot\EFI\bootmgfw.efi -> les certificats de 2011 sont encore utilisés
• correspond à celui de C:\Windows\Boot\EFI_EX\bootmgfw.efi ou bootmgfw_EX.efi -> les certificats de 2023 sont utilisés

 
Merci pour l'idée et le texte, mais ce n'est pas la vocation du topic, je pars du principe que si on cherche à mettre à jour les certificats on est déjà un minimum au courant du problème.

enfin, normalement, les MAJ mensuelles de Windows devraient déjà faire automatiquement la MAJ des certificats "current".
La MAJ auto de Windows fonctionne avec plusieurs clefs de registre
https://support.microsoft.com/fr-fr [...] 06f43f360d

En fonction des retours de télémétrie, Windows défini un `ConfidenceLevel` pour VOTRE PC (identifié par son `BucketHash`) pour savoir si oui on non les certificats 2023 passent bien dessus.
Ceci n'est pas tjs fiable: mon PC de 2014 en Haswell sous win10 était avec un ConfidenceLevel high, ceci a fait la MAJ des certificats, mais aussi bloqué mon PC: https://forum.hardware.fr/hfr/Windo [...] 6997_1.htm

Forcer la MAJ comme proposé par Umi revient donc à zapper cette étape de recommandation.
Cela pourrait ne pas fonctionner...

ok, mais tu suggères une manipulation sans expliquer le pourquoi du comment, et surtout que c'est pas sans risque...

Les détails techniques sont vite assez complexe.
Cette présentation résume autrement les pts de SecureBoot: https://www.hansenpartnership.com/I [...] /#/step-16
Quelques éléments sur les différents mots clefs DB, DBX, KEK:

Je comprends mieux pourquoi certains vieux PC 'custom' ne peuvent pas MAJ le KEK, peut-être causé par un PK pas bien défini.
Les PC de marque, Dell, HP, Lenovo, etc, ont un PK du dit constructeur.

Tu te méprends, même avec l'argument -x Mosby ne supprime pas de certificats qui pourraient servir, Pete Batard a expliqué cela ici: https://github.com/pbatard/Mosby/issues/31
Et si ceux de 2023 ne "passent pas" comme tu dis, alors ça ne changera rien...

Encore une fois, je ne cherche pas à expliquer en détail ce qu'est Secure Boot, si tu veux en parler libre à toi.

Je ne crois pas qu'il y ait de risques particuliers à utiliser Mosby, lesquels vois-tu ?

Si par extraordinaire le système ne démarrait plus, un simple reset des certificats SB suffit à revenir à l'état par défaut, mais c'est plus l'inverse (certificats SB pas à jour) qui risque d'empêcher les nouveaux systèmes de démarrer que l'inverse.

nos messages sont complémentaires.
Je dis juste que tu présentes une solution avec Mosby sans dire ce que c'est et ce que cela fait.
Ton 1er msg est assez bien dans les étapes, mais AMHA une ligne de plus pour présenter mosby serait bienvenu.
Si j ai bien compris le truc, un truc genre:
"Mosby est une shell UEFI pour mettre à jour les clefs et certificats de securité de SecureBoot"
Si je pige bien, Mosby propose notamment de définir sa propre clef PK, et donc de mieux gérer la sécurité SecureBoot "pour soi" et non "pour le constructeur" ou "pour Microsoft".

Par contre, c est tjs pas très clair ce que modifie Mosby: écrit il dans l UEFI sur les certificats "default" (niveau 1) ? Et/ou les current de la partition EFI (niveau 2)?

Logiquement, l auteur propose la solution avec Rufus.
Mais en théorie, on peut aussi récupérer l ISO 'release' de
https://github.com/pbatard/UEFI-Shell/releases
et le mettre sur sa clef Ventoy.
edit: ou PAS si Mosby écrit les certificats sur la dite clef.

Par ailleurs, un autre prérequis est d'avoir un mode "setup" ou "other OS" dans son bios/UEFI.
Certaines vielles cartes mères (comme ma Asrock Z87) n'ont PAS cela: elle n'offre aucun moyen de lire ou modifier les clefs SecureBoot. Asrock n'a visiblement pas correctement implémenté SecureBoot dessus.
Et je ne pense pas que cela soit un cas isolé...

J'ai ajouté quelques infos au premier post.
Après, pour qui veut creuser, je donne les liens nécessaires.
Je ne sais pas comment Mosby fonctionne exactement, mais je fais confiance à l'auteur.

Ce guide est avant-tout pour les utilisateurs Windows, d'où l’utilisation de Rufus, mais effectivement Ventoy ou même Grub permettent de démarrer un exécutable EFI, on peut donc lancer UEFI Shell, puis ensuite lancer Mosby
https://github.com/ventoy/Ventoy/issues/2976

Si Secure Boot n'est pas correctement implémenté, effectivement ce guide sera inutile, mais le problème sera le même avec ou sans Mosby. Le plus simple étant alors probablement de désactiver entièrement Secure Boot.

Sur mon laptop Lenovo, qui accepte de se mettre en mode Setup, j'ai pu installer ma propre PK.
Sur mon desktop (ASUS TUF GAMING B550-PLUS) je n'ai pas pu installer ma propre PK, mais en mettant sur Other OS j'ai pu installer les updates (Mosby -U).

Si je comprend bien cet article, on peut mettre en Setup Mode si on efface les clés Secure Boot: https://www.asus.com/support/faq/1049829/

Salut j'ai posté sur le TU Windows 11 en Avril mais je n'ai pas eu le temps de m'en occuper depuis. Donc j'ai suivi de loin ces histoires de certificat. Sur mon PC de bureau compatible Windows 11 j'ai ceci
 

 
Concrétement et en language compréhensible    ca veut dire quoi ?
 

UEFI DBX c'est la liste de révocations, chez toi elle est en partie non appliquée, après je ne sais pas ce que ça veut dire dans le détails.
Je vois que tu as une ancienne version du script, pense à le mettre à jour et à relancer.
 
Voici ce que j'ai sur mon desktop Windows 10 après avoir utilisé Mosby:
 
 

Ancienne version ? Je l'ai DL cette aprem    
 
Voici la fenêtre en total
 

 
Je n'ai jamais creusé ces certificats. Y'en a dans Windows et dans le Bios ?
 
Avec ta méthode je peux tout passer en vert ?
 
Tu dis qu'on peut théoriquement mettre à jour avec Check-UEFISecureBootVariables. Tu peux développer ?

Relis les messages au dessus, notamment l intro que j ai mis.
donc oui, il y a des certificats
- "dans" Windows: les "current". En fait c est la partition EFI qui contient des fichiers signés avec ces certificats.
- ET "dans" le bios, les "default"

Dans ton cas, tout est en 2023 dans Windows donc ok.
Mais les defaut du bios sont encore en 2011. Normalement, la MAJ de ces certificats requiert une MAJ du bios. Qui n existe pas si la carte mère a qques années.

J'ai tjs pas compris si Mobsy permet vraiment de modifier les certificats du bios, mais je crois que c est son but, si ton bios offre un mode "setup"  pour faire cette manip.

Sur " théoriquement mettre à jour avec Check-UEFISecureBootVariables", il y a un script "apply update" dans ce repo. Mais cela ne concerne QUE la partie Windows/fichier EFI puisque tu ne peux PAS écrire direct dans le bios à partir de Windows (ou autre OS). Donc inutile pour toi puisque déjà en vert sur Windows.

d'ailleurs, pour vos screenshots, précisez la date du bios/UEFI de votre PC (en supposant que vous avez déjà appliqué le dernier dispo)

Mon bios date de 2024 et plus de MAJ depuis. J'imagine que mon bios a un mode setup...
 
Bon j'ai réalisé la clé avec rufus comme tu l'as indiqué UMI. J'espère ne pas foirer mon bios...

Ah pardon, j'ai mal vu.
 
Avant Mosby, j'avais certaines parties en rouge malheureusement je n'ai pas fait de captures.
 
 
Si j'ai bien compris ce qui est en rouge chez toi c’est la partie Windows, donc pas certain que Mosby aide, mais dans tous les cas tu peux le lancer.  
 
Dans les scripts que tu as téléchargé, tu peux lancer Apply 2023 KEK, DB and bootmgfw update.cmd, attendre "un peu" (le readme ne dit pas la durée) puis redémarrer, normalement Windows devrait appliquer la mise à jour.

Ben non, c'est la partie Windows * SVN qui est en rouge justement. Ou alors je n'ai rien compris, ce qui est possible

Oui et ça c'est normal si le BIOS n'a pas été mise à jour. D'ailleurs certains BIOS mis à jour en 2026 n'ont toujours pas les certificats 2023...

Mosby a besoin du mode Setup car il installe une PK personnalisée, mais c'est facultatif, je l'ai bien expliqué sur le cas de mon desktop justement.
Pas besoin du mode setup pour mettre à jour les clés signés par Microsoft ou le fabricant de CM (ou toute autre autorité présente dans la Default DB)

Si c’est signé avec la clé Microsoft, Windows devrait pouvoir mettre à jour les clés SB (celles qui apparaissent dans la partie Current UEFI DB).
Je parle au conditionnel car j'ai l'impression que ça ne fonctionne pas toujours très bien.

Heuuu la je suis perdu. J'ai réalisé la clé comme tu l'as bien détaillé UMI. Ceci dit vous etes pas d'accord. je souhaiterais avoir les certificat bios et windows.
 
J'ai lancé Apply 2023 KEK, DB and bootmgfw update.cmd, attendu plusieurs minutes, redemarré mais Nada. Rien n'a changé.
 
A quoi correspondent les SHA256 chez toi UMI. Rien de ca chez moi.

 
le sujet est vite complexe avec tant de variables.
en relisant https://github.com/cjee21/Check-UEFISecureBootVariables (dans lequel j'ai fait une petite contribution il y a 2 mois), je comprends que SVN vient de  
SecureBootData.DBX.SecurityVersionNumber.BootMgr.Version.ToString()
 
C'est pas l'élément déterminant. Je maintiens que les "current" sont les update "de niveau 2" (niveau du système d’exploitation dans la description du cert.ssi.gouv.fr) et bien ce qui est actif.
 

vraiment? Cela montre un certain laisser aller des constructeurs. Le bios de FutMan de 2024 va dans le même sens...
 

C'est toi qui a défini ton PK comme "ASUSTeK Motherboard PK certificate" ?? Ou alors le nom de la PK est fixé mais tu as changé que sa valeur?
 

Comme dit, Windows ne met à jour QUE les certificats "current" et QUE si les conditions sont remplies. Ces conditions sont liées aux clefs de registre et à la télémetrie qui permet de ne PAS MAJ certains PC connus pour être problématique.

 
Étais tu en mode "setup" ? As tu créer ton propre PK ?
Sinon, la seule "Apply 2023 KEK, DB and bootmgfw update.cmd" semble faire la même chose que Windows, cad MAJ les certificats "currents" de Windows. Dans ton cas pas de changement puisqu'ils étaient déjà appliqués.

FutMan, ta carte mère semble un Z730-A Pro en socket 1151  (edit, comme tu mets dans la signature de tes msg )
https://www.msi.com/Motherboard/Z370-A-PRO/support
ton bios de 2024 était juste un quick fix d'une énorme faille spécifique aux bios de MSI: https://cyberinsider.com/msi-mother [...] e-attacks/

mais sinon le reste du bios est comme ceux de 2020 ou 2021, d'où le manque de certificats 2023.
(Et le 1er bios donc  la carte mère datent de 2017)

Donc tu peux essayer de crérr un PK pour ensuite signer un KEK puis ta DB et DBX avec le certificat de 2023 pour avoir tout en vert, si cela est possible. J'ai un gros doute là dessus, et cela me semble assez avancé...

Umi, ta carte mère a un dernier bios de 2026, donc j imagine que le bios inclus DÉJÀ les certificats de 2023 par défault, même si PAS référencé dans l'historique des bios:
https://www.asus.com/fr/motherboard [...] -B550-PLUS
Je doute que cela soit Mosby qui ait modifié les lignes "default". Il aurait fallu lancer le script et en garder le résultat AVANT de lancer Mobsy.

Qd je lis la documentation de Asus:
https://www.asus.com/support/faq/1056845/
 
je me demande si c'est moi qui est encore mal compris, ou si c'est Asus qui est de mauvaise fois pour ne pas comprendre l interet d avoir les certificats de 2023 par default: la doc ne parle que de faire un reset du bios avec les clefs par défault (sans préciser si elles sont avec les certificats de 2011 ou 2023) puis ensuite de forcer les MAJ du "current" avec Windows.

Comme je te l'ai dit, je n'ai pas mis cette CM en mode Setup, j'ai utilisé Mosby avec l'argument -U donc seule la mise à jour des certificats a pu avoir lieu (et effectivement dans le cas de cette CM seule la partie DBX avait besoin d'une màj).

Sur mon laptop Lenovo par contre, j'ai utilisé le mode Setup, et Mosby a bien installé ses propres clés, ainsi que les certificats 2023 qui n'étaient pas présents par défaut, bien que le BIOS date d'avril 2025. Il a aussi dégagé le certificat Thinkpad Product CA 2012, je suppose qu'il est expiré, ou révoqué, ou considéré comme dangereux.

cela confirme donc bien que ton PC Asus a eu les MAJ "default" de 2023 via son bios.

Et ton cas Lenovo permet de mieux comprendre ce que peux faire Mobsy:
- le Thinkpad Product CA 2012 a dégagé car il était probablement le PK, et comme le PK est unique, il a été remplacé par le "Mobsy Generared"
- Mobsy permet donc de créer le "Current UEFI PK"
- Mais ne change rien au "Default UEFI PK/KEK/DB" qui restent aussi chez toi tout en 2011 (les 2023 sont avec une croix rouge, donc PAS dispo)

Donc ton Lenovo est comme la MSI de FatMan (et sans doute la majorité des PC): MAJ en 2023 dans Windows, mais qui reste en 2011 par default dans le bios.
C'est bien le cas "peu résilient" que je décris: cela fonctionne très bien et permet d'avoir toutes les MAJ.
Mais il ne faut alors JAMAIS faire un reset des clefs du bios, qui va remettre les "current" à partir des "default", donc restaurer un boot loader de 2011, tandis que l OS (Windows / EFI) sont déjà avec 2023 -> Windows ne pourra pas démarrer.
C'est bien aussi ce que cert.ssi.gouv.fr décrit: "Sans mise à jour des certificats au niveau UEFI, une restauration des paramètres par défaut de l'UEFI de l’appareil pourrait se solder par l’impossibilité de démarrer en démarrage sécurisé"

Ton Lenovo montre aussi que FatMan a besoin de RIEN faire sur sa MSI puisqu'il a déjà les current en 2023, et que les "default" ne peuvent PAS être modifiées (sauf par une MAJ du bios si le constructeur le propose)

Oui puisque ils sont dans la partie "Default".

Non le Default PK est "Ideapad Products", c'est visible dans ma capture.

Oui, puisque ceux par défaut sont ceux livrés dans le BIOS, et rétablis en cas de reset.

C'est justement là que Mosby sera utile.

Sauf si Mosby met à jour la partie Windows SVN en rouge sur sa capture.

J'ai tenté un Mosby -U (avec le Secure Boot  passé en mode Setup) sur le laptop Lenovo, ça fonctionne, voici ce que Mosby a effectué:

Avec -u il installe les DBX et les SBAT donc.

Par contre impossible de sortir du mode Setup, je pense que le BIOS attend qu'une nouvelle PK soit installée pour sortir du mode Setup. Résultat Windows démarre, mais Secure Boot est inactif...

Du coup, et pour la science, j'ai fait un reset des clés Secure Boot, on n'est plus dans le mode setup, mais par contre Windows ne démarre plus (du moins avec Secure Boot activé) car il a été mis à jour avec les clés 2023, et que le BIOS ne les a pas.
Ce problème ne se serait pas présenté avec la CM de mon desktop qui a lés clés 2011 et 2023.

On va donc pouvoir tester l'utilité de Mosby dans ce cas de figure.

Après avoir à nouveau passé Secure Boot en mode Setup, retour sur Mosby, mais sans l’argument -U cette fois, j'en ai profité pour prendre en photo les messages affichés:

En répondant "No" à ce second message (demande de reboot dans le BIOS), on a le log qui s'affiche:

On voit que Mosby a généré puis installé un nouveau fichier PK, en utilisant les clés générées le 16/05 qui étaient encore sur la clé USB, et a installé tous les fichiers DB, DBX et KEK nécessaires:

Le script Check UEFI....confirme tout ça:

Voilà, je pense que ce que fait Mosby est un peu plus clair maintenant.