Crise du certificat Secure Boot Linux sur Huawei MateBook : guide de survie pour l'expiration du CA UEFI 2026

Date : 30 mai 2026 Plateforme : HUAWEI BoF-XX (MateBook M1010), 12th Gen Intel Core i7-1260P, Ubuntu Resolute Raccoon (Noble), GNOME 50.0 Statut : Platform is in Setup Mode, SecureBoot désactivé, variable db manquante

Résumé

Le 27 juin 2026, le certificat racine Microsoft UEFI CA 2011 expirera. Pour la plupart des utilisateurs Windows, ce n’est qu’une mise à jour en arrière-plan. Pour les utilisateurs Linux sur du matériel OEM non pris en charge — en particulier les Huawei MateBook exclus du Linux Vendor Firmware Service (LVFS) et de la liste blanche Microsoft — c’est une bombe à retardement. Cet article dissèque intégralement la crise technique, démonte le mythe selon lequel « Linux n’a pas besoin de signature Microsoft », et fournit une voie de réparation éprouvée, en environnement purement Linux, applicable aux appareils bloqués en Setup Mode sans canal de support officiel du fabricant.

1. Anatomie de l’expiration

1.1 Ce qui meurt vraiment

La chaîne de confiance Secure Boot repose sur trois certificats signés par Microsoft en 2011 :

Ces certificats ne sont pas sur le disque. Ils résident dans les variables NVRAM du firmware de la carte mère (db, KEK, PK, dbx). Après expiration, un firmware qui valide strictement la durée de validité X.509 refusera de charger tout bootloader signé uniquement par le CA 2011 — y compris les futurs shims Linux, les Option ROM NVIDIA GPU et le Windows Boot Manager mis à jour.

1.2 Chaîne de confiance (avant 2026)

graph TD
    A[Platform Key / PK<br/>OEM ou Microsoft] -->|signe| B[Key Exchange Key / KEK<br/>Microsoft KEK CA 2011]
    B -->|signe| C[Signature Database / db<br/>Microsoft UEFI CA 2011]
    C -->|valide| D[shim.efi<br/>Bootloader Linux]
    C -->|valide| E[Windows Boot Manager]
    C -->|valide| F[NVIDIA GOP / Option ROM]
    D -->|valide| G[GRUB2]
    G -->|valide| H[Noyau Linux]
    style C fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style B fill:#ff9999,stroke:#cc0000,stroke-width:3px

Figure 1 : Les certificats de 2011 (en rouge) soutiennent toute la chaîne de démarrage tierce. Après expiration, tous les composants aval perdront leur validation.

1.3 Chaîne de confiance (après 2026, état idéal)

graph TD
    A[Platform Key / PK] -->|signe| B[Key Exchange Key / KEK<br/>Microsoft KEK 2K CA 2023]
    B -->|signe| C[Signature Database / db<br/>Microsoft UEFI CA 2023]
    B -->|signe| D[Signature Database / db<br/>Windows UEFI CA 2023]
    C -->|valide| E[shim.efi<br/>version signée 2023]
    D -->|valide| F[Windows Boot Manager<br/>version signée 2023]
    C -->|valide| G[NVIDIA GOP<br/>version signée 2023]
    E -->|valide| H[GRUB2]
    H -->|valide| I[Noyau Linux]
    style C fill:#99ff99,stroke:#009900,stroke-width:3px
    style D fill:#99ff99,stroke:#009900,stroke-width:3px
    style B fill:#99ff99,stroke:#009900,stroke-width:3px

Figure 2 : Les certificats de 2023 (en vert) doivent être présents dans db avant juin 2026 pour préserver la compatibilité ascendante.

2. Le piège Huawei : abandonné par l’écosystème de mise à jour

2.1 Le problème de la liste blanche OEM

Huawei maintient une liste blanche stricte et limitée de SKU pouvant recevoir la rotation des certificats via Windows Update. Selon la documentation officielle de Huawei, seuls 19 SKU spécifiques sont garantis pour recevoir les certificats 2023 via Windows Update :

• MateBook X Pro 2024 / 2022
• MateBook 14 2023 (non S)
• MateBook D16 2024
• MateStation S (lots spécifiques)
• … (15 autres modèles)

Le sujet de cet article — MateBook 14 2022 (BoF-XX / M1010) — n’est manifestement pas sur la liste. Cela signifie que même sous Windows 11, la tâche planifiée Secure-Boot-Update ne se déclenchera probablement pas, ou que le firmware refusera l’écriture des variables.

2.2 L’absence sur LVFS

graph LR
    subgraph Écosystème de mise à jour du firmware
        A[Windows Update] -->|pousse les certificats| B[Firmware OEM<br/>Dell, Lenovo, HP]
        C[LVFS / fwupd] -->|pousse .cab| D[Linux Vendor Firmware Service]
        D -->|prend en charge| E[Dell XPS]
        D -->|prend en charge| F[Lenovo ThinkPad]
        D -->|prend en charge| G[System76]
        D -->|prend en charge| H[Framework]
        D -.->|absent| I[HUAWEI MateBook]
    end
    style I fill:#ff9999,stroke:#cc0000,stroke-width:3px

Figure 3 : Huawei ne publie pas de mises à jour firmware sur LVFS. Les utilisateurs Linux ne peuvent pas obtenir de mise à jour officielle du BIOS ou des certificats via fwupdmgr.

2.3 L’erreur du « Fedora a mis à jour mes certificats automatiquement »

Les discussions communautaires voient souvent une objection — « Fedora a poussé automatiquement une mise à jour firmware, Linux n’a pas besoin de signature Microsoft ».

C’est un biais du survivant. Si fwupd fonctionne sous Fedora, c’est parce que :

1. Le fabricant (ex. Lenovo) a téléversé une mise à jour capsule contenant les nouveaux certificats vers LVFS.
2. Le firmware de ce fabricant autorise l’écriture de variables côté OS (ce n’est pas le cas de tous — HP et Fujitsu sont connus pour verrouiller l’écriture de db).
3. Le modèle d’appareil figure dans la matrice de support du fabricant.

Pour les utilisateurs de Huawei MateBook, aucune de ces conditions n’est remplie. Les certificats résident dans la NVRAM du firmware, pas dans /boot/efi. Aucune distribution Linux ne peut « miraculeusement » injecter des certificats que l’OEM n’a pas autorisés et que le firmware refuse.

3. La bouée de sauvetage du mode Setup

3.1 Découverte de l’état idéal

Sur le Huawei MateBook M1010 de l’auteur, les commandes de diagnostic suivantes ont été exécutées :

$ sudo mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode

$ ls /sys/firmware/efi/efivars/ | grep -i db
dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c

Constat clé :

• SecureBoot disabled : la chaîne de démarrage n’est actuellement pas vérifiée.
• Platform is in Setup Mode : la variable PK (Platform Key) est vide.
• La variable db est absente : la base de signatures n’existe pas dans la NVRAM — seuls les dbDefault d’usine subsistent.

3.2 Pourquoi le mode Setup est un super-pouvoir

En User Mode (fonctionnement normal), l’écriture dans db nécessite un fichier .auth signé. La signature doit être validée par la KEK existante — or la clé privée de la KEK est détenue exclusivement par Microsoft. Un utilisateur individuel ne peut pas générer de signature valide.

En Setup Mode (PK vide), le firmware n’applique pas la validation de signature pour l’écriture des variables. Cela signifie que des fichiers .esl (EFI Signature List) bruts non signés peuvent être écrits directement dans db, KEK et PK.

stateDiagram-v2
    [*] --> SetupMode: Retour usine / effacement PK
    [*] --> UserMode: Démarrage normal, PK enregistrée

    SetupMode --> UserMode: Écriture de PK.auth (auto-signée)
    UserMode --> SetupMode: Suppression PK / retour aux clés d'usine

    state SetupMode {
        [*] --> db_write_unsigned
        db_write_unsigned --> [*]: efi-updatevar -f file.esl db
        note right of db_write_unsigned
            Aucune signature requise.
            Aucune clé privée KEK nécessaire.
            Écriture directe dans la NVRAM.
        end note
    }

    state UserMode {
        [*] --> db_write_signed
        db_write_signed --> [*]: efi-updatevar -f file.auth db
        note right of db_write_signed
            Nécessite un fichier .auth signé par KEK.
            Clé privée KEK détenue uniquement par Microsoft.
            Bloqué pour l'utilisateur individuel.
        end note
    }

    style SetupMode fill:#99ff99,stroke:#009900
    style UserMode fill:#ffcccc,stroke:#cc0000

Figure 4 : Machine d’état d’accès aux variables UEFI Secure Boot. Le mode Setup (vert) est le seul état permettant à un utilisateur individuel d’écrire des certificats sans la clé privée Microsoft.

4. Modélisation des risques : pourquoi « Linux n’a pas besoin de signature » est faux

4.1 Surface de menace

Soit (R) le risque total sur la durée de fonctionnement, décomposé ainsi :

[ R = R_{bootkit} + R_{compat} + R_{maint} ]

Où :

• (R_{bootkit}) : probabilité d’infection par un malware au niveau firmware (ex. BlackLotus, CosmicStrand)
• (R_{compat}) : probabilité qu’une future mise à jour système échoue en raison de la validation des signatures
• (R_{maint}) : coût de maintenance d’une chaîne de démarrage non standard gérée manuellement

Lorsque Secure Boot est désactivé et que les certificats 2011 ont expiré :

[ R_{bootkit}^{(post)} = R_{bootkit}^{(pre)} \times \delta^{-1}, \quad \delta \in (0,1) ]

L’absence de mise à jour de dbx (liste de révocation) signifie que les versions vulnérables connues de bootloaders et de shims ne peuvent pas être ajoutées à la liste noire par le firmware. Le système immunitaire est gelé de façon permanente.

4.2 Matrice des risques de compatibilité

Tableau 1 : Matrice de compatibilité et de sécurité. La colonne « Certificats 2011 uniquement » représente l’état d’échouage après juin 2026.

5. Correction purement Linux : procédure pas à pas

5.1 Prérequis

• Accès root sur le système Linux cible
• Paquets efitools, openssl, uuid-runtime installés
• Accès réseau pour télécharger les certificats 2023 publiés par Microsoft
• Sauvegarde des variables NVRAM actuelles (si existantes)

5.2 Phase 1 : Récupération des certificats

# Créer le répertoire de travail
mkdir -p ~/secureboot && cd ~/secureboot

# Télécharger Microsoft UEFI CA 2023 (format DER)
wget -O MicUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239872"

# Télécharger Windows UEFI CA 2023 (format DER)
wget -O WinUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239776"

# Convertir au format PEM pour efitools
openssl x509 -in MicUEFICA2023.der -inform DER \
  -out MicUEFICA2023.pem -outform PEM

openssl x509 -in WinUEFICA2023.der -inform DER \
  -out WinUEFICA2023.pem -outform PEM

5.3 Phase 2 : Génération des listes de signatures EFI

# Générer un GUID aléatoire pour la propriété de la liste
uuidgen --random > guid.txt
GUID=$(cat guid.txt)

# Convertir les certificats en ESL (EFI Signature List)
cert-to-efi-sig-list -g "$GUID" \
  MicUEFICA2023.pem MicUEFICA2023.esl

cert-to-efi-sig-list -g "$GUID" \
  WinUEFICA2023.pem WinUEFICA2023.esl

5.4 Phase 3 : Injection dans la NVRAM (mode Setup)

La plateforme étant en mode Setup, on écrit directement les fichiers .esl non signés. Aucune signature .auth n’est nécessaire.

# Créer la variable db (sans l'option -a)
sudo efi-updatevar -f MicUEFICA2023.esl db

# Ajouter le second certificat (option -a)
sudo efi-updatevar -a -f WinUEFICA2023.esl db

Vérification :

sudo mokutil --db

Extrait de sortie attendu :

[...]
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:00:00:02:5a:76:fb:8f:76:14:44:3b:91:00:00:00:02:5a:76
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Microsoft Corporation, CN = Microsoft UEFI CA 2023
[...]

5.5 Phase 4 : Quitter le mode Setup (recommandé mais pas obligatoire)

Laisser le système en mode Setup est dangereux — tout OS ou bootloader malveillant peut modifier db. Nous allons générer une Platform Key (PK) personnelle pour basculer en User Mode, tout en laissant Secure Boot désactivé.

# Générer une clé de plateforme auto-signée
openssl req -new -x509 -newkey rsa:2048 \
  -subj "/CN=Personal MateBook PK/" \
  -keyout PK.key -out PK.pem \
  -days 3650 -nodes

# Convertir en DER pour le traitement ESL
openssl x509 -in PK.pem -out PK.der -outform DER

# Générer l'ESL
cert-to-efi-sig-list -g "$GUID" PK.der PK.esl

# Écrire la PK pour quitter le mode Setup
sudo efi-updatevar -f PK.esl PK

# Vérifier le changement d'état
sudo mokutil --sb-state
# Attendu : "SecureBoot disabled" + "Platform is in User Mode"

5.6 Schéma de procédure complet

flowchart TD
    A[Début : Huawei MateBook<br/>environnement Linux pur] --> B{Vérifier l'état}
    B -->|mokutil --sb-state| C[En mode Setup ?<br/>PK vide ?]
    C -->|Oui| D[Télécharger les certificats<br/>Microsoft 2023]
    C -->|Non| E[Aller dans le BIOS → effacer PK<br/>→ redémarrer sous Linux]

    D --> F[Convertir DER → PEM → ESL]
    F --> G[efi-updatevar -f cert.esl db]
    G --> H{Vérifier<br/>mokutil --db}
    H -->|Certificat 2023 présent| I[Générer une PK personnelle]
    H -->|Absent| J[Déboguer : vérifier dmesg<br/>droits efivarfs]

    I --> K[efi-updatevar -f PK.esl PK]
    K --> L[Quitter le mode Setup<br/>entrer en User Mode]
    L --> M[Prêt pour l'avenir :<br/>certificats 2023 dans db<br/>SecureBoot toujours désactivé]

    style C fill:#99ff99,stroke:#009900
    style H fill:#ffcc66,stroke:#cc9900
    style M fill:#99ff99,stroke:#009900

Figure 5 : Arbre de décision pour la correction purement Linux sur les appareils Huawei MateBook en mode Setup.

6. Cas limites et modes de défaillance

6.1 Si efi-updatevar retourne Permission denied

Certains OEM (HP, Fujitsu, et potentiellement les futures versions du firmware Huawei) verrouillent l’écriture NVRAM au niveau du firmware, même en mode Setup. En cas d’erreur :

Error: Could not update variable: Permission denied

Solution alternative : Utiliser KeyTool.efi (du paquet efitools), lancé directement depuis le shell EFI ou le menu de démarrage. Il offre une interface graphique pour l’enregistrement des certificats, contournant les limitations d’appels système au niveau OS.

6.2 Si la variable db existe déjà

Si ls /sys/firmware/efi/efivars/ affiche un fichier db-8be4df61-93ca-11d2-aa0d-00e098032b8c (GUID standard de variable globale EFI), utilisez le marqueur d’ajout pour toutes les écritures :

sudo efi-updatevar -a -f MicUEFICA2023.esl db
sudo efi-updatevar -a -f WinUEFICA2023.esl db

6.3 Risque d’écran noir avec GPU NVIDIA

Certains GPU NVIDIA plus anciens (séries GTX 600/700/900 et premières séries 10) embarquent un pilote UEFI GOP signé uniquement par Microsoft UEFI CA 2011. Si Secure Boot est activé après juin 2026 sans que le CA 2023 soit enregistré, ces GPU peuvent ne pas initialiser l’affichage, provoquant un écran noir avant la prise en main par le système d’exploitation.

Atténuation : La solution proposée dans cet article enregistre les certificats 2023 tout en laissant Secure Boot désactivé. Cela préserve la compatibilité future sans déclencher la validation des Option ROM GPU au démarrage.

7. Conclusion

L’expiration des certificats UEFI en 2026 n’est pas un problème Windows — c’est un problème d’ancre de confiance au niveau firmware. Pour les utilisateurs de Huawei MateBook sous Linux pur, l’absence de support LVFS combinée à l’exclusion de la liste blanche Microsoft crée un véritable gouffre de maintenance.

Mais la découverte que l’appareil est échoué en mode Setup transforme un scénario de verrouillage apparemment impossible en un simple problème d’injection NVRAM. Les certificats 2023 peuvent être enregistrés en environnement purement Linux, sans Windows, sans clé privée Microsoft, sans fwupd, directement avec efitools.

« Linux n’a pas besoin de la signature Microsoft » est techniquement vrai pour le démarrage d’aujourd’hui, mais désastreusement faux pour la maintenance de demain. Enregistrer les certificats 2023 dès maintenant, c’est s’assurer une protection pour les futures mises à jour shim, les firmwares GPU et les scénarios de double démarrage — sinon ils échoueront silencieusement avec la seule ancre de confiance 2011.

Annexe A : Commandes de référence rapide

# Vérifier l'état actuel
sudo mokutil --sb-state
sudo mokutil --db | grep -i "2023"
ls /sys/firmware/efi/efivars/ | grep -i db

# Télécharger et convertir
wget https://go.microsoft.com/fwlink/?linkid=2239872 -O MicUEFICA2023.der
wget https://go.microsoft.com/fwlink/?linkid=2239776 -O WinUEFICA2023.der
openssl x509 -in MicUEFICA2023.der -inform DER -out MicUEFICA2023.pem -outform PEM
openssl x509 -in WinUEFICA2023.der -inform DER -out WinUEFICA2023.pem -outform PEM

# Générer et écrire
uuidgen --random > guid.txt
cert-to-efi-sig-list -g "$(cat guid.txt)" MicUEFICA2023.pem MicUEFICA2023.esl
cert-to-efi-sig-list -g "$(cat guid.txt)" WinUEFICA2023.pem WinUEFICA2023.esl
sudo efi-updatevar -f MicUEFICA2023.esl db
sudo efi-updatevar -a -f WinUEFICA2023.esl db

Annexe B : Glossaire

Version du document : 1.0.0
Plateforme testée : HUAWEI BoF-XX (M1010), Ubuntu Resolute Raccoon, kernel 7.0.0-12-generic