Crisis de certificados Secure Boot en Huawei MateBook Linux: Guía de supervivencia para la expiración del CA UEFI 2026

Fecha: 30 de mayo de 2026 Plataforma: HUAWEI BoF-XX (MateBook M1010), 12th Gen Intel Core i7-1260P, Ubuntu Resolute Raccoon (Noble), GNOME 50.0 Estado: Platform is in Setup Mode, SecureBoot deshabilitado, variable db ausente

Resumen

El 27 de junio de 2026, el certificado raíz Microsoft UEFI CA 2011 expirará. Para la mayoría de los usuarios de Windows, esto es solo una actualización en segundo plano. Para los usuarios de Linux que utilizan hardware OEM no compatible —en particular los Huawei MateBook que no están en el Linux Vendor Firmware Service (LVFS) ni en la lista blanca de Microsoft— esto es una bomba de relojería. Este artículo documenta por completo el panorama técnico de la crisis, desmonta el mito de que “Linux no necesita firmas de Microsoft” y ofrece una ruta de reparación probada en un entorno 100 % Linux, válida para dispositivos atascados en Setup Mode sin canal oficial de soporte del fabricante.

1. Anatomía de la expiración

1.1 Qué es lo que realmente muere

La cadena de confianza de Secure Boot depende de tres certificados emitidos por Microsoft en 2011:

Estos certificados no están en el disco. Residen en las variables NVRAM del firmware de la placa base (db, KEK, PK, dbx). Tras la expiración, el firmware que valide estrictamente la vigencia X.509 se negará a cargar cualquier bootloader firmado solo por la CA de 2011 —incluyendo futuros shim de Linux, Option ROM de GPU NVIDIA y versiones actualizadas de Windows Boot Manager.

1.2 Cadena de confianza (antes de 2026)

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

Figura 1: Los certificados de 2011 (en rojo) sostienen toda la cadena de arranque de terceros. Tras la expiración, todos los componentes aguas abajo perderán la validación.

1.3 Cadena de confianza (después de 2026, estado ideal)

graph TD
    A[Platform Key / PK] -->|firma| B[Key Exchange Key / KEK<br/>Microsoft KEK 2K CA 2023]
    B -->|firma| C[Signature Database / db<br/>Microsoft UEFI CA 2023]
    B -->|firma| D[Signature Database / db<br/>Windows UEFI CA 2023]
    C -->|verifica| E[shim.efi<br/>Versión firmada 2023]
    D -->|verifica| F[Windows Boot Manager<br/>Versión firmada 2023]
    C -->|verifica| G[NVIDIA GOP<br/>Versión firmada 2023]
    E -->|verifica| H[GRUB2]
    H -->|verifica| I[Kernel 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

Figura 2: Los certificados de 2023 (en verde) deben estar presentes en db antes de junio de 2026 para mantener la compatibilidad hacia adelante.

2. La trampa de Huawei: Abandonado por el ecosistema de actualizaciones

2.1 El problema de la lista blanca OEM

Huawei mantiene una lista blanca estricta y limitada de SKU que pueden recibir la rotación de certificados mediante Windows Update. Según la documentación oficial de soporte de Huawei, solo 19 SKU específicos tienen garantizada la recepción de los certificados de 2023 a través de Windows Update:

• MateBook X Pro 2024 / 2022
• MateBook 14 2023 (no S)
• MateBook D16 2024
• MateStation S (lotes específicos)
• …… (otros 15 modelos)

El protagonista de este artículo, MateBook 14 2022 (BoF-XX / M1010), no está en la lista. Esto significa que incluso con Windows 11 instalado, es probable que la tarea programada Secure-Boot-Update no se active, o que el firmware rechace la escritura de las variables.

2.2 Ausencia en LVFS

graph LR
    subgraph Ecosistema de actualización de firmware OEM
        A[Windows Update] -->|envía certificados| B[Firmware OEM<br/>Dell, Lenovo, HP]
        C[LVFS / fwupd] -->|envía .cab| D[Linux Vendor Firmware Service]
        D -->|compatible| E[Dell XPS]
        D -->|compatible| F[Lenovo ThinkPad]
        D -->|compatible| G[System76]
        D -->|compatible| H[Framework]
        D -.->|no compatible| I[HUAWEI MateBook]
    end
    style I fill:#ff9999,stroke:#cc0000,stroke-width:3px

Figura 3: Huawei no publica actualizaciones de firmware en LVFS. Los usuarios de Linux no pueden obtener actualizaciones oficiales de BIOS o certificados a través de fwupdmgr.

2.3 La falacia de “Fedora actualizó automáticamente mis certificados”

Es común encontrar en debates comunitarios la réplica: “Fedora envió la actualización de firmware automáticamente; Linux no necesita firmas de Microsoft”.

Esto es un sesgo de supervivencia. El fwupd de Fedora funciona porque:

1. El fabricante del hardware (por ejemplo, Lenovo) subió una actualización capsule con los nuevos certificados a LVFS.
2. El firmware de ese fabricante permite que el sistema operativo escriba variables (no todos lo permiten — HP y Fujitsu son conocidos por bloquear la escritura de db).
3. El modelo del dispositivo está dentro de la matriz de soporte del fabricante.

Para los usuarios de Huawei MateBook, ninguna de las condiciones anteriores se cumple. Los certificados residen en la NVRAM del firmware, no en /boot/efi. Ninguna distribución Linux puede “mágicamente” inyectar certificados que el OEM no autorizó y que el firmware rechaza.

3. El salvavidas del Setup Mode

3.1 Descubriendo el estado dorado

En el Huawei MateBook M1010 del autor, al ejecutar los siguientes comandos de diagnóstico:

$ 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

Hallazgos clave:

• SecureBoot disabled: la cadena de arranque actualmente no está verificada.
• Platform is in Setup Mode: la variable PK (Platform Key) está vacía.
• La variable db está ausente: la base de datos de firmas no existe en NVRAM — solo queda el valor predeterminado de fábrica dbDefault.

3.2 Por qué Setup Mode es un superpoder

En User Mode (operación normal), escribir en db requiere un archivo .auth firmado. La firma debe ser validada por la KEK existente — cuya clave privada pertenece exclusivamente a Microsoft. Un usuario particular no puede generar una firma válida.

En Setup Mode (PK vacía), el firmware no exige validación de firma para la escritura de variables. Esto significa que archivos .esl (EFI Signature List) sin firmar pueden escribirse directamente en db, KEK y PK.

stateDiagram-v2
    [*] --> SetupMode: Restaurar valores de fábrica / borrar PK
    [*] --> UserMode: Arranque normal, PK registrada

    SetupMode --> UserMode: Escribir PK.auth (autofirmada)
    UserMode --> SetupMode: Eliminar PK / restaurar claves de fábrica

    state SetupMode {
        [*] --> db_write_unsigned
        db_write_unsigned --> [*]: efi-updatevar -f file.esl db
        note right of db_write_unsigned
            Sin firma necesaria.
            Sin clave privada KEK.
            Escritura directa en NVRAM.
        end note
    }

    state UserMode {
        [*] --> db_write_signed
        db_write_signed --> [*]: efi-updatevar -f file.auth db
        note right of db_write_signed
            Requiere archivo .auth firmado por KEK.
            Clave privada KEK solo en manos de Microsoft.
            Usuario particular bloqueado.
        end note
    }

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

Figura 4: Máquina de estados del acceso a variables Secure Boot en UEFI. Setup Mode (verde) es el único estado donde un usuario particular puede escribir certificados sin la clave privada de Microsoft.

4. Modelado de riesgos: Por qué “Linux no necesita firmas” es incorrecto

4.1 Superficie de amenaza

Sea (R) el riesgo total de tiempo de actividad del sistema, descompuesto como:

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

Donde:

• (R_{bootkit}): probabilidad de infección por malware a nivel de firmware (ej. BlackLotus, CosmicStrand)
• (R_{compat}): probabilidad de fallo en actualizaciones futuras del sistema debido a la validación de firmas
• (R_{maint}): coste de mantenimiento de una cadena de arranque no estándar gestionada manualmente

Cuando Secure Boot está desactivado y los certificados de 2011 han expirado:

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

dbx (lista de revocación) sin actualizar significa que versiones de bootloader y shim con vulnerabilidades conocidas no pueden ser bloqueadas por el firmware. El sistema inmunológico del sistema queda congelado permanentemente.

4.2 Matriz de riesgos de compatibilidad

Tabla 1: Matriz de compatibilidad y seguridad. La columna “Solo certificados 2011” representa el estado de abandono tras junio de 2026.

5. Reparación nativa en Linux: Procedimiento paso a paso

5.1 Requisitos previos

• Acceso root en el sistema Linux objetivo
• Tener instalados efitools, openssl, uuid-runtime
• Conexión a Internet para descargar los certificados 2023 publicados por Microsoft
• Copia de seguridad de las variables NVRAM actuales (si existen)

5.2 Fase 1: Obtener los certificados

# Crear directorio de trabajo
mkdir -p ~/secureboot && cd ~/secureboot

# Descargar Microsoft UEFI CA 2023 (formato DER)
wget -O MicUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239872"

# Descargar Windows UEFI CA 2023 (formato DER)
wget -O WinUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239776"

# Convertir a formato PEM para 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 Fase 2: Generar lista de firmas EFI

# Generar UUID aleatorio para la propiedad de la lista de firmas
uuidgen --random > guid.txt
GUID=$(cat guid.txt)

# Convertir certificados a 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 Fase 3: Inyectar en NVRAM (Setup Mode)

Dado que la plataforma está en Setup Mode, se escriben directamente los archivos .esl sin firmar. No se necesita firma .auth.

# Crear la variable db por primera vez (sin bandera -a)
sudo efi-updatevar -f MicUEFICA2023.esl db

# Añadir el segundo certificado (bandera -a)
sudo efi-updatevar -a -f WinUEFICA2023.esl db

Verificación:

sudo mokutil --db

Fragmento de salida esperada:

[...]
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 Fase 4: Salir del Setup Mode (recomendado pero no obligatorio)

Dejar el sistema en Setup Mode es peligroso — cualquier sistema operativo o bootloader malicioso podría modificar db. Generaremos una Platform Key (PK) personal para cambiar a User Mode, manteniendo Secure Boot desactivado.

# Generar Platform Key autofirmada
openssl req -new -x509 -newkey rsa:2048 \
  -subj "/CN=Personal MateBook PK/" \
  -keyout PK.key -out PK.pem \
  -days 3650 -nodes

# Convertir a DER para procesamiento ESL
openssl x509 -in PK.pem -out PK.der -outform DER

# Generar ESL
cert-to-efi-sig-list -g "$GUID" PK.der PK.esl

# Escribir PK para salir de Setup Mode
sudo efi-updatevar -f PK.esl PK

# Verificar el cambio de estado
sudo mokutil --sb-state
# Esperado: "SecureBoot disabled" + "Platform is in User Mode"

5.6 Diagrama de flujo completo

flowchart TD
    A[Inicio: Huawei MateBook<br/>Entorno 100 % Linux] --> B{Verificar estado}
    B -->|mokutil --sb-state| C[¿En Setup Mode?<br/>¿PK vacía?]
    C -->|Sí| D[Descargar certificados<br/>Microsoft 2023]
    C -->|No| E[Entrar en BIOS → Borrar PK<br/>→ Reiniciar a Linux]

    D --> F[Convertir DER → PEM → ESL]
    F --> G[efi-updatevar -f cert.esl db]
    G --> H{Verificar<br/>mokutil --db}
    H -->|Certificado 2023 presente| I[Generar PK personal]
    H -->|Ausente| J[Depurar: revisar dmesg<br/>permisos efivarfs]

    I --> K[efi-updatevar -f PK.esl PK]
    K --> L[Salir de Setup Mode<br/>Entrar en User Mode]
    L --> M[Preparado para el futuro:<br/>Certificado 2023 en db<br/>SecureBoot aún desactivado]

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

Figura 5: Diagrama de decisión para la reparación nativa en Linux de dispositivos Huawei MateBook en Setup Mode.

6. Casos límite y modos de fallo

6.1 Si efi-updatevar devuelve Permission denied

Algunos OEM (HP, Fujitsu, y potencialmente futuras versiones del firmware de Huawei) bloquean la escritura en NVRAM a nivel de firmware incluso en Setup Mode. Si ocurre:

Error: Could not update variable: Permission denied

Solución alternativa: Usar KeyTool.efi (del paquete efitools), iniciándolo directamente desde el shell EFI o desde el menú de arranque. Ofrece un flujo gráfico de registro de certificados que puede eludir las limitaciones de las llamadas al sistema a nivel de SO.

6.2 Si la variable db ya existe

Si ls /sys/firmware/efi/efivars/ muestra un archivo db-8be4df61-93ca-11d2-aa0d-00e098032b8c (GUID estándar de variable global EFI), todas las escrituras deben usar la bandera de añadir:

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

6.3 Riesgo de pantalla negra con NVIDIA GPU

Algunas NVIDIA GPU antiguas (series GTX 600/700/900 y primeras series 10) incorporan controladores GOP UEFI firmados únicamente por Microsoft UEFI CA 2011. Si después de junio de 2026 se activa Secure Boot sin haber registrado la CA 2023, estas GPU podrían no inicializar el monitor, provocando una pantalla negra antes de que el sistema operativo tome el control.

Mitigación: El procedimiento descrito en este artículo registra los certificados de 2023 mientras mantiene Secure Boot desactivado. De esta forma se preserva la compatibilidad futura sin activar la validación de Option ROM de GPU durante el arranque.

7. Conclusión

La expiración de los certificados UEFI en 2026 no es un problema de Windows — es un problema del ancla de confianza a nivel de firmware. Para los usuarios de Huawei MateBook que ejecutan Linux puro, la falta de soporte en LVFS combinada con la exclusión de la lista blanca de Microsoft crea un verdadero precipicio de mantenimiento.

Sin embargo, descubrir que el dispositivo está varado en Setup Mode convierte un escenario de bloqueo de plataforma aparentemente imposible en un problema directo de inyección en NVRAM. Los certificados de 2023 pueden registrarse de forma nativa en un entorno 100 % Linux, sin usar Windows, sin necesidad de la clave privada de Microsoft y sin fwupd, utilizando directamente efitools.

“Linux no necesita firmas de Microsoft” es técnicamente cierto para el arranque de hoy, pero catastróficamente erróneo para el mantenimiento del mañana. Registrar los certificados de 2023 ahora es un seguro para futuras actualizaciones de shim, firmware de GPU y escenarios de arranque dual — de lo contrario, todos fallarán silenciosamente con solo el ancla de confianza de 2011.

Apéndice A: Comandos de referencia rápida

# Verificar el estado actual
sudo mokutil --sb-state
sudo mokutil --db | grep -i "2023"
ls /sys/firmware/efi/efivars/ | grep -i db

# Descargar y 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

# Generar y escribir
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

Apéndice B: Glosario

Versión del documento: 1.0.0
Plataforma de pruebas: HUAWEI BoF-XX (M1010), Ubuntu Resolute Raccoon, kernel 7.0.0-12-generic