# Message Erreur Secure Boot

**URL:** <https://www.debian-fr.org/t/message-erreur-secure-boot/92247>\
**Category:** Support Debian\
**Created:** [Avril 25, 2026, 2:58 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247 "2026-04-25T02:58:55Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 26, 2026, 2:01 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/24 "2026-04-26T14:01:28Z")

</div>

Oui,  
voilà ce que ça donne :  
amnesia@amnesia:~$ mokutil --pk --short  
d52ac7db95 HP UEFI Secure Boot PK 2017

---

<div class="post-metadata">

**Author:** ![Thierz](https://www.debian-fr.org/user_avatar/www.debian-fr.org/thierz/32/15124_2.png) [@Thierz](https://www.debian-fr.org/u/Thierz)\
**Post date:** [Avril 26, 2026, 2:07 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/26 "2026-04-26T14:07:01Z")

</div>

> [@fran.b](#):
>
> Renseignement ppris, cela veut dire que je n’ai pas une clef OEM garantie par le constructeur mais celle de «fabriquant» du firmware EFI  
> En clair ça n’est pas un souci

Regarde cet article : [PKfail, la faille qui met KO le secure boot](https://www.lemondeinformatique.fr/actualites/lire-pkfail-la-faille-qui-met-ko-secure-boot-94393.html)

Faille majeure, mais faible probabilité d’être ciblé, c’est à toi de voir si le risque est acceptable ou pas.

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 26, 2026, 2:08 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/27 "2026-04-26T14:08:50Z")

</div>

Oui,  
je sais, c’est bien ce que je cherchais à la base, une distribution live avec une partition persistente qui ne vient pas polluer le disque de la machine.  
C’est tombé sur Tails dès le début de mes recherches et je suis resté la-dessus.  
Pour autant, ce n’est pas l’idéal, c’est une distribution contraignante.  
J’en cherche une autre avec des caractéristiques similaires mais plus souple dans l’utilisation au quotidien, si tu as une idée ou de l’expérience à ce sujet, merci.

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 26, 2026, 2:10 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/28 "2026-04-26T14:10:45Z")

</div>

Oui,  
c’est une des caractéristiques qui m’a plu au début.

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 26, 2026, 2:15 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/31 "2026-04-26T14:15:13Z")

</div>

Pour moi ça semble bien être une clef d’origine HP, non ?

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Avril 27, 2026, 8:19 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/32 "2026-04-27T08:19:13Z")

</div>

> [@romain254](#):
>
> Mon problème c’est de pouvoir ouvrir un port sur une distrib live semble t-il particulièrement bien « cadenassée » pour répondre à des obligations provenant de microsoft.  
> Un comble quand même !  
> Merci.

Est d’utiliser une distribution live avec une persistance pour une utilisation de tous les jours … de surcroît sur un PC ou ni le firmware est à jour ni le système d’exploitation dessus (pas fini d’installer).

La distribution Tails redirige les connexion vers TOR, je ne crois pas qu’il y est de Naviguateur qui puissent facilement exploiter le port 443.

Vue que tu tournes en rond avec Tails et ton OS Windows pas installé, utilisent un Ubuntu/Debian live ou autre distribution comme ça si tu utilise un Portable le permettant (HP, Lenovo, Toshiba, Dell), tu l’installes si pas disponible.  
Mais comme dit précédemment, il faut parfois un OS installé pour manipuler la partie EFI.  
Sinon c’est clé usb depuis laquelle tu démarré l’outil fourni par le constructeur (il ne le font pas tous, voir avec le matériel).

Dans tous les cas Tails ne sera pas d’un grand secours, à la différence de Kali qui se veux un outil de Forensics, Tails est une distribution voué à simplement être utilisée tel quelle.

---

<div class="post-metadata">

**Author:** ![anon3605821](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/edb3f5/32.png) [@anon3605821](https://www.debian-fr.org/u/anon3605821)\
**Post date:** [Avril 27, 2026, 8:19 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/33 "2026-04-27T08:19:52Z")

</div>

> [@romain254](#):
>
> C’est tombé sur Tails dès le début de mes recherches et je suis resté la-dessus.

tu t’es enquiquiné pour rien comme ca a été dit par ailleurs un debian live aurait ete aussi simple et tu aurais eu peut etre moins d’emdts pour la config initiale  
Pour ce qui est de la «&nbsp;persistence&nbsp;» il me semble que la live debian la propose aussi  
Tor laisse des traces sur ton reseau sauf si tu te connectes via un wifi qui n’est pas le tien

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 27, 2026, 12:02 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/34 "2026-04-27T12:02:21Z")

</div>

> [@Clochette](#):
>
> Est d’utiliser une distribution live avec une persistance pour une utilisation de tous les jours … de surcroît sur un PC ou ni le firmware est à jour ni le système d’exploitation dessus (pas fini d’installer).  
> La distribution Tails redirige les connexion vers TOR, je ne crois pas qu’il y est de Naviguateur qui puissent facilement exploiter le port 443.

Où est le problème ?  
Ça tournait depuis 2 ans et soudainement les gens de tails décident de prendre en considération les exigences de microsoft, je n’y suis pour rien.  
Le navigateur ne pose pas de problème dans mon cas de figure, c’est la ligne de commande et gnome-firmware (je n’ai essayé que ces solutions) qui sont bloqués.

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 27, 2026, 12:04 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/35 "2026-04-27T12:04:39Z")

</div>

> [@anon3605821](#):
>
> tu t’es enquiquiné pour rien comme ca a été dit par ailleurs un debian live aurait ete aussi simple et tu aurais eu peut etre moins d’emdts pour la config initiale

Enquiquiné avec quoi ?  
Quelle config initiale ?

---

<div class="post-metadata">

**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\
**Post date:** [Avril 27, 2026, 3:17 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/36 "2026-04-27T15:17:16Z")

</div>

> [@romain254](#):
>
> Ça tournait depuis 2 ans et soudainement les gens de tails décident de prendre en considération les exigences de microsoft, je n’y suis pour rien.

Non, ça n’est pas Microsoft, c’est le système de secure boot (largement initié par Microsoft il est vrai). Tous les OS installés ont un système de mise à jour du bios EFI et des bases de données des certificats.  
Le fil va dérapé mais Apple OS est à Windows ce que Windows est à linux. Là je me bas pour qu’une personne puisse exécuter un qemu avec accélération sur un Mac M1 aarch64. Pourquoi? Pour faire tourner une version arm64 de la clef APESAM. Impossible de démarrer un mac M1 sur un périphérique extérieur sans modifier la machine. La seule solution que j’ai trouvé est de lancer un qemu qui utilise le périphérique extérieur comme disque, le tout avec l’accélération HVF. Oui, mais pour utiliser cette accélération, il faut avoir la certification d’Apple (une après midi et je n’ai pas fini). Cette certification est payante sauf si on est une gentielle association qui sème la paix et le bonheur dans le monde (c’est notre cas 🙂 ).  
Donc en clair tu as une machine et tu ne peux PAS l’utiliser comme tu veux. Entre autres, l’installation de linux sur les mac ARM64 est quasi impossible à ce jour.  
Les PCs standards ARM64 et les Raspberries boutent ss pbm (à vérifier, je n’ai pas bcp de recul)  
PS: peut être à mettre ds pause café ça non?

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 28, 2026, 2:08 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/37 "2026-04-28T02:08:51Z")

</div>

Tu veux dire qu’il n’y a pas d’échappatoire à cette histoire de certificats ?  
Je suis obligé d’y passer ?  
Au final, existe t-il une solution pour libérer temporairement le port 443 ?  
Merci.

---

<div class="post-metadata">

**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\
**Post date:** [Avril 28, 2026, 6:11 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/38 "2026-04-28T06:11:30Z")

</div>

```auto
sudo iptables -F INPUT
sudo iptables -F OUTPUT 
sudo iptables -F FORWARD
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -F PREROUTING
sudo iptables -F POSTROUTING
```

Si iptables n’existe pas, essaye xptables  
C’est surtout les routing et output qui comptent

---

<div class="post-metadata">

**Author:** ![droopy191](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c89c15/32.png) [@droopy191](https://www.debian-fr.org/u/droopy191)\
**Post date:** [Avril 28, 2026, 8:34 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/39 "2026-04-28T08:34:09Z")

</div>

Je vous suggère la lecture de cette explication complète de Zargos

[Fonctionnement de secure boot Debian](https://www.debian-fr.org/t/activer-le-demarrage-securise-secure-boot-dans-debian/91380)

En résumé, la chaine de boot sécurisée est  
UEFI → Shim → Grub → kernel  
Par défaut, seules les clés Microsoft sont présentes dans le bios/EFI . Celles ci expirent ( cf votre premier message). La première étape est de voir si le fabricant de votre carte mère fourni un bios/efi mise à jour avec ces clés ( pour un CM de plus de 5-6 ans, c’est pas évident).

Si ce n’est pas le cas, vous pouvez soit désactiver secureboot ou vous pouvez intégrer votre propre clé et signer kernel et module avec celle ci ( loin d’etre simple, et à faire à chaque maj).

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Avril 28, 2026, 8:39 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/40 "2026-04-28T08:39:15Z")

</div>

> [@droopy191](#):
>
> ( loin d’etre simple, et à faire à chaque maj).

Mise à joru du BIOS précisément.

> [@droopy191](#):
>
> Par défaut, seules les clés Microsoft sont présentes dans le bios/EFI .

Microsoft et fournisseur de la carte mère.  
Pour M$ c’est normal, c’est eux qui sont à l’origine de la techno.

> [@fran.b](#):
>
> Si iptables n’existe pas, essaye xptables

Ou bien directement nftables? Car si Tail est issu de Debian, c’est nftables au cœur du pare-feu.

Quand au port 443, il n’y a aucune corrélation en le Secure Boot et le protocole HTTPS. Je ne vois pas le rapport ici.

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 28, 2026, 12:57 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/41 "2026-04-28T12:57:36Z")

</div>

Bonjour,  
j’ai déjà tenté de désactiver le secure boot, sans succès.

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 28, 2026, 1:11 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/42 "2026-04-28T13:11:47Z")

</div>

Bonjour,  
merci pour ta réponse.  
Cette suite de commandes me permettraient de pouvoir éliminer temporairement cette problématique de port 443 ?

Voilà la réponse que j’obtient de la part de la base de données :

```auto
**sudo fwupdmgr refresh**
**[sudo] Mot de passe de amnesia :**
 **Mise à jour lvfs**
**Téléchargement… [-]**
 **Failed to download metadata for lvfs: failed to download file: Failed to connect to cdn.fwupd.org port 443 after 790 ms: Could not connect to server**

```

Idem avec gnome-firmware :

 ![certificats](https://www.debian-fr.org/uploads/default/original/2X/d/dd6e70ec994ecb14b125c749ab3590469961ff36.jpeg)

Concernant iptables, voilà ce que j’ai pu trouver :

```auto
**sudo iptables -L --line-numbers**
**[sudo] Mot de passe de amnesia :**
**Chain INPUT (policy DROP)**
 **num target prot opt source destination**
 **1 ACCEPT all -- anywhere anywhere state ESTABLISHED**
 **2 ACCEPT all -- anywhere anywhere**
 **3 ACCEPT tcp -- 10.200.1.2 10.200.1.1 multiport dports 9050,951**
 **4 ACCEPT tcp -- 10.200.1.6 10.200.1.5 multiport dports 951**
 **5 ACCEPT tcp -- 10.200.1.10 10.200.1.9 multiport dports 951**
 **6 ACCEPT tcp -- 10.200.1.14 10.200.1.13 multiport dports 9050,951**
 **7 REJECT all -- anywhere 10.200.1.0/24 reject-with icmp-port-unreachable**

**Chain FORWARD (policy DROP)**
 **num target prot opt source destination**
 **1 ACCEPT all -- anywhere anywhere**
 **2 ACCEPT all -- anywhere anywhere**

**Chain OUTPUT (policy DROP)**
 **num target prot opt source destination**
 **1 ACCEPT all -- anywhere anywhere state ESTABLISHED**
 **2 ACCEPT icmp -- anywhere anywhere state RELATED**
 **3 ACCEPT tcp -- anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match _apt**
 **4 ACCEPT tcp -- anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match proxy**
 **5 ACCEPT tcp -- anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match nobody**
 **6 ACCEPT tcp -- anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-upgrade-frontend**
 **7 ACCEPT tcp -- anywhere localhost tcp dpt:9062 flags:FIN,SYN,RST,ACK/SYN owner UID match htp**
 **8 ACCEPT tcp -- anywhere localhost tcp dpt:9062 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-upgrade-frontend**
 **9 ACCEPT tcp -- anywhere localhost tcp dpt:9063 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-iuk-get-target-file**
 **10 log_reject tcp -- anywhere localhost tcp dpt:9063 flags:FIN,SYN,RST,ACK/SYN owner UID match amnesia**
 **11 log_reject tcp -- anywhere localhost tcp dpt:9052 owner UID match amnesia**
 **12 ACCEPT tcp -- anywhere localhost tcp dpt:9052 owner UID match root**
 **13 ACCEPT tcp -- anywhere localhost tcp dpt:951 owner UID match root**
 **14 ACCEPT udp -- anywhere localhost udp dpt:domain owner UID match amnesia**
 **15 ACCEPT udp -- anywhere localhost udp dpt:mdns owner UID match amnesia**
 **16 ACCEPT udp -- anywhere localhost udp dpt:domain owner UID match htp**
 **17 ACCEPT udp -- anywhere localhost udp dpt:mdns owner UID match htp**
 **18 log_reject udp -- anywhere localhost udp dpt:domain owner UID match _apt**
 **19 log_reject udp -- anywhere localhost udp dpt:mdns owner UID match _apt**
 **20 ACCEPT udp -- anywhere localhost udp dpt:domain owner UID match root**
 **21 ACCEPT udp -- anywhere localhost udp dpt:mdns owner UID match root**
 **22 ACCEPT tcp -- anywhere localhost tcp dpt:4101 flags:FIN,SYN,RST,ACK/SYN owner UID match Debian-gdm**
 **23 ACCEPT tcp -- anywhere localhost tcp flags:FIN,SYN,RST,ACK/SYN owner UID match amnesia**
 **24 ACCEPT tcp -- anywhere anywhere owner UID match clearnet**
 **25 ACCEPT udp -- anywhere anywhere owner UID match clearnet udp dpt:domain**
 **26 ACCEPT tcp -- anywhere anywhere owner UID match debian-tor tcp flags:FIN,SYN,RST,ACK/SYN state NEW**
 **27 ACCEPT udp -- anywhere anywhere owner UID match debian-tor udp dpt:domain**
 **28 lan all -- anywhere 10.0.0.0/8**
 **29 lan all -- anywhere 172.16.0.0/12**
 **30 lan all -- anywhere 192.168.0.0/16**
 **31 log_reject all -- anywhere anywhere**

**Chain lan (3 references)**
 **num target prot opt source destination**
 **1 log_reject tcp -- anywhere anywhere tcp dpt:domain**
 **2 log_reject udp -- anywhere anywhere udp dpt:domain**
 **3 log_reject udp -- anywhere anywhere udp dpt:netbios-ns**
 **4 ACCEPT all -- anywhere anywhere**

**Chain log_reject (8 references)**
 **num target prot opt source destination**
 **1 LOG all -- anywhere anywhere LOG level debug uid prefix "Dropped outbound packet: "**
 **2 REJECT all -- anywhere anywhere reject-with icmp-port-unreachable**

```

Merci.

---

<div class="post-metadata">

**Author:** ![romain254](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/ecb155/32.png) [@romain254](https://www.debian-fr.org/u/romain254)\
**Post date:** [Avril 28, 2026, 1:14 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/43 "2026-04-28T13:14:54Z")

</div>

> [@Zargos](#):
>
> Quand au port 443, il n’y a aucune corrélation en le Secure Boot et le protocole HTTPS. Je ne vois pas le rapport ici.

Bonjour,  
je ne sais pas si c’est le cas mais le système me renvoie systématiquement la même erreur concernant le port 443 (cf. ma réponse précédente).  
Merci.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Avril 28, 2026, 1:16 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/44 "2026-04-28T13:16:36Z")

</div>

> [@romain254](#):
>
> je ne sais pas si c’est le cas mais le système me renvoie systématiquement la même erreur concernant le port 443 (cf. ma réponse précédente).

C’est un défaut de la configuration de ton système.

---

<div class="post-metadata">

**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\
**Post date:** [Avril 28, 2026, 2:17 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/45 "2026-04-28T14:17:37Z")

</div>

Visiblement les commandes sudo n’ont pas efface tes règles iptables existantes  
Bon fais un

```auto
Sudo iptables -I OUTPUT --dport 443 -j ACCEPT 
```

(Syntaxe à vérifier) Mais c’est curieux, les -F auraient dû tout effacer

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Avril 28, 2026, 2:21 UTC](https://www.debian-fr.org/t/message-erreur-secure-boot/92247/46 "2026-04-28T14:21:51Z")

</div>

Vous êtes sur qu’il n’y a pas un UFW ou autre d’utilisé? car pour une distro de ce type, je doute que la ligne de commande soit la seule configuration possible.

[Page précédente](https://www.debian-fr.org/t/message-erreur-secure-boot/92247.md?page=1)

[Page suivante](https://www.debian-fr.org/t/message-erreur-secure-boot/92247.md?page=3)
