Wi-Fi qui ne fonctionne plus après une mise à jour : le coupable inattendu s’appelle Secure Boot

Il y a quelques mois, nous étions intervenus à distance sur un vieux PC portable passé sous Linux Mint pour réparer sa carte Wi-Fi Broadcom récalcitrante : pilote introuvable, compilation qui échouait, le classique sur ce genre de puce. Après un peu de travail, tout refonctionnait parfaitement.

Cette semaine, rebelote : même machine, même client, le Wi-Fi avait de nouveau disparu. Sauf que cette fois, la cause n’avait rien à voir avec un pilote cassé — et c’est justement ce qui rend cette panne intéressante.

Le symptôme : un pilote installé… mais qui refuse de charger

Premier réflexe lors d’un diagnostic à distance : vérifier si le pilote (wl, le pilote propriétaire Broadcom packagé via DKMS) était toujours présent.

dkms status
→ broadcom-sta/6.30.223.271, 6.17.0-40-generic, x86_64: installed

Bonne nouvelle, il était bien compilé pour le noyau en cours. Le problème n’était donc pas une histoire de mise à jour de noyau qui aurait cassé la compilation, comme c’est souvent le cas avec ce genre de pilote « hors arbre » (out-of-tree).

Mais dès qu’on tentait de le charger manuellement :

sudo modprobe wl
→ modprobe: ERROR: could not insert 'wl': Key was rejected by service

Ce message est la clé de toute l’histoire.

Le vrai coupable : Secure Boot

« Key was rejected by service » est un message caractéristique du Secure Boot — cette fonctionnalité du BIOS/UEFI qui vérifie que chaque composant chargé au démarrage (bootloader, noyau, mais aussi modules noyau) est signé par une clé de confiance.

Un pilote comme wl, compilé localement sur la machine par DKMS, n’est pas signé par une clé reconnue par défaut. Tant que Secure Boot est désactivé, ce n’est pas un problème : le noyau charge le module sans broncher. Mais dès que Secure Boot est réactivé — après une réinitialisation du BIOS, une mise à jour de firmware, ou simplement une case décochée par erreur — le noyau se met à rejeter silencieusement tout module non signé.

Résultat : la carte Wi-Fi physique fonctionne, le pilote est bien installé, mais rien ne se charge. Pour un utilisateur, cela ressemble exactement à une carte Wi-Fi qui « ne marche plus », alors que le matériel n’a jamais bougé. C’est le même genre de piège que celui décrit dans notre article sur un PC qui se bloque à cause d’un logiciel de sécurité mal configuré : le symptôme pointe vers le matériel ou une application, alors que la cause réelle se trouve dans une couche de sécurité qu’on ne pense pas à regarder en premier.

La solution propre : signer le module plutôt que désactiver la sécurité

La solution la plus simple — désactiver Secure Boot dans le BIOS — fonctionne, mais ce n’est pas la meilleure : elle réduit la protection du système contre les malwares de bas niveau (bootkits, rootkits UEFI). Sur Windows, on retrouve un peu la même logique de prudence que celle qu’on recommande avant de lancer DISM et SFC : corriger le problème précisément plutôt que de désactiver une protection ou tout réinstaller.

La bonne pratique consiste à faire reconnaître le module par le système, via un mécanisme appelé MOK (Machine Owner Key) :

1. DKMS génère automatiquement une paire de clés lors de la compilation du module (/var/lib/shim-signed/mok/MOK.der), mais ne l’enregistre pas forcément dans le firmware.
2. On met cette clé en attente d’inscription avec mokutil --import, en définissant un mot de passe temporaire.
3. Au redémarrage suivant, un écran bleu « MOK Manager » apparaît avant même le chargement du système d’exploitation. C’est le seul moment où l’inscription peut se faire — impossible à distance, il faut être physiquement devant la machine.
4. On choisit « Enroll MOK », on saisit le mot de passe défini à l’étape précédente, on confirme, et le système redémarre.

Une fois cette clé enregistrée, le noyau lui fait confiance : le module signé avec cette clé se charge normalement, Secure Boot reste activé, et la sécurité du poste n’est pas dégradée.

Le piège auquel personne ne pense : le clavier

Petit détail qui a son importance si vous devez faire cette manipulation vous-même : l’écran MOK Manager tourne dans un environnement minimaliste qui ne connaît que la disposition clavier US (QWERTY), quelle que soit la disposition réellement configurée dans votre système (AZERTY en France, par exemple).

Concrètement, si vous avez défini un mot de passe contenant des lettres comme M, W, Q ou A et que vous le tapez sur un clavier AZERTY physique, les caractères qui s’affichent ne seront pas ceux que vous croyez taper — ces touches ne sont pas à la même position sur les deux dispositions. Résultat : mot de passe « refusé » alors qu’il est objectivement correct, ce qui peut être déroutant à distance.

La parade la plus simple : choisir un mot de passe MOK uniquement composé de chiffres. Les chiffres sont interprétés correctement quelle que soit la disposition clavier, puisqu’ils occupent la même position physique sur un clavier AZERTY et QWERTY.

En résumé

Un « Wi-Fi qui ne marche plus » peut avoir des causes très différentes d’une panne à l’autre, même sur la même machine :

• la première fois, un pilote non compatible avec le noyau installé,
• la seconde fois, une politique de sécurité du BIOS qui bloque un pilote pourtant parfaitement fonctionnel.

Le symptôme est identique côté utilisateur, mais le diagnostic — et donc la solution — n’a rien à voir. C’est tout l’intérêt d’un vrai diagnostic technique plutôt que d’appliquer la même recette à l’aveugle : ça évite de désactiver des protections de sécurité qui n’ont, au final, rien à voir avec le problème.

FAQ : Secure Boot, Wi-Fi et pilotes Linux

Faut-il désactiver Secure Boot pour utiliser Linux ?

Non. La grande majorité des distributions Linux modernes fonctionnent très bien avec Secure Boot activé. Le problème ne survient que pour des pilotes tiers non signés, comme certains pilotes Wi-Fi propriétaires compilés localement via DKMS.

Qu’est-ce qu’une clé MOK ?

MOK signifie Machine Owner Key. C’est une clé de signature que le propriétaire de la machine peut ajouter lui-même à la liste des clés de confiance du firmware, pour autoriser des modules noyau spécifiques sans désactiver Secure Boot dans son ensemble.

Pourquoi l’inscription MOK doit-elle se faire physiquement sur la machine ?

L’écran de validation MOK Manager s’affiche avant que le système d’exploitation ne démarre, donc avant que le réseau ou SSH ne soient disponibles. Aucun outil d’accès à distance ne peut intervenir à ce stade : une présence physique est nécessaire, ne serait-ce que quelques secondes.

---

Un Wi-Fi ou un périphérique qui ne fonctionne plus après une mise à jour ou un changement de configuration BIOS ? sephy lab peut diagnostiquer précisément la cause — pilote, firmware, ou sécurité du système — et corriger le problème sans désactiver les protections de votre machine.

📡 Soutenir le labo

Sephy-Lab est un projet libre et gratuit. Si tu veux soutenir les expériences et maintenir le système en ligne, tu peux m’aider ici.

Payez-moi un café !