Huawei MateBook Linux Secure Boot Zertifikatskrise: Überlebensleitfaden für den UEFI-CA-Ablauf 2026

Datum: 30. Mai 2026 Plattform: HUAWEI BoF-XX (MateBook M1010), 12th Gen Intel Core i7-1260P, Ubuntu Resolute Raccoon (Noble), GNOME 50.0 Status: Platform is in Setup Mode, SecureBoot deaktiviert, db-Variable fehlt

Zusammenfassung

Am 27. Juni 2026 läuft das Microsoft UEFI CA 2011-Root-Zertifikat ab. Für die meisten Windows-Nutzer ist das nur ein Hintergrundupdate. Für Linux-Nutzer mit nicht unterstützter OEM-Hardware – insbesondere Huawei MateBook, die weder im Linux Vendor Firmware Service (LVFS) noch auf der Microsoft-Whitelist stehen – ist das eine tickende Zeitbombe. Dieser Artikel dokumentiert das vollständige technische Bild der Krise, widerlegt den Mythos „Linux braucht keine Microsoft-Signatur“ und bietet einen praxisgeprüften, reinen Linux-Reparaturpfad – geeignet für Geräte, die im Setup Mode feststecken und keinen offiziellen Hersteller-Supportkanal haben.

1. Anatomie des Ablaufs

1.1 Was genau stirbt

Die Vertrauenskette von Secure Boot beruht auf drei von Microsoft im Jahr 2011 ausgestellten Zertifikaten:

Diese Zertifikate befinden sich nicht auf der Festplatte. Sie existieren in den NVRAM-Variablen des Mainboard-Firmware (db, KEK, PK, dbx). Nach ihrem Ablauf wird strikte Firmware, die die X.509-Gültigkeit prüft, sich weigern, Bootloader zu laden, die nur von der 2011-CA signiert wurden – einschließlich zukünftiger Linux-Shims, NVIDIA-GPU-Option-ROMs und aktualisierter Windows-Boot-Manager.

1.2 Vertrauenskette (vor 2026)

graph TD
    A[Plattformschlüssel / PK<br/>OEM oder Microsoft] -->|signiert| B[Schlüsselaustauschschlüssel / KEK<br/>Microsoft KEK CA 2011]
    B -->|signiert| C[Signaturdatenbank / db<br/>Microsoft UEFI CA 2011]
    C -->|verifiziert| D[shim.efi<br/>Linux-Bootloader]
    C -->|verifiziert| E[Windows Boot Manager]
    C -->|verifiziert| F[NVIDIA GOP / Option ROM]
    D -->|verifiziert| G[GRUB2]
    G -->|verifiziert| H[Linux-Kernel]
    style C fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style B fill:#ff9999,stroke:#cc0000,stroke-width:3px

Abbildung 1: Die 2011-Zertifikate (rot) tragen die gesamte Third-Party-Startkette. Nach Ablauf verlieren alle nachgelagerten Komponenten ihre Verifizierung.

1.3 Vertrauenskette (nach 2026, Idealzustand)

graph TD
    A[Plattformschlüssel / PK] -->|signiert| B[Schlüsselaustauschschlüssel / KEK<br/>Microsoft KEK 2K CA 2023]
    B -->|signiert| C[Signaturdatenbank / db<br/>Microsoft UEFI CA 2023]
    B -->|signiert| D[Signaturdatenbank / db<br/>Windows UEFI CA 2023]
    C -->|verifiziert| E[shim.efi<br/>2023 signiert]
    D -->|verifiziert| F[Windows Boot Manager<br/>2023 signiert]
    C -->|verifiziert| G[NVIDIA GOP<br/>2023 signiert]
    E -->|verifiziert| H[GRUB2]
    H -->|verifiziert| I[Linux-Kernel]
    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

Abbildung 2: Die 2023-Zertifikate (grün) müssen vor Juni 2026 in der db vorhanden sein, um Abwärtskompatibilität zu gewährleisten.

2. Die Huawei-Falle: Vom Update-Ökosystem abgehängt

2.1 Das OEM-Whitelist-Problem

Huawei pflegt eine strenge, begrenzte SKU-Whitelist – nur diese Modelle erhalten den Zertifikatswechsel über Windows Update. Laut offiziellem Huawei-Supportdokument sind nur 19 bestimmte SKUs garantiert, um die 2023-Zertifikate über Windows Update zu erhalten:

• MateBook X Pro 2024 / 2022
• MateBook 14 2023 (nicht S)
• MateBook D16 2024
• MateStation S (bestimmte Chargen)
• … (weitere 15 Modelle)

Der in diesem Artikel dokumentierte MateBook 14 2022 (BoF-XX / M1010) ist eindeutig nicht auf dieser Liste. Das bedeutet, dass selbst mit Windows 11 der Secure-Boot-Update-Scheduled-Task höchstwahrscheinlich nicht ausgelöst wird oder die Firmware die Variablen-Schreibvorgänge ablehnt.

2.2 Fehlende LVFS-Unterstützung

graph LR
    subgraph Hersteller-Firmware-Update-Ökosystem
        A[Windows Update] -->|push Zertifikate| B[OEM-Firmware<br/>Dell, Lenovo, HP]
        C[LVFS / fwupd] -->|push .cab| D[Linux Vendor Firmware Service]
        D -->|unterstützt| E[Dell XPS]
        D -->|unterstützt| F[Lenovo ThinkPad]
        D -->|unterstützt| G[System76]
        D -->|unterstützt| H[Framework]
        D -.->|fehlt| I[HUAWEI MateBook]
    end
    style I fill:#ff9999,stroke:#cc0000,stroke-width:3px

Abbildung 3: Huawei veröffentlicht keine Firmware-Updates auf LVFS. Linux-Nutzer können keine offiziellen BIOS- oder Zertifikatsupdates über fwupdmgr erhalten.

2.3 Der Trugschluss „Fedora hat meine Zertifikate automatisch aktualisiert”

In Community-Diskussionen taucht häufig ein Gegenargument auf – „Fedora hat das Firmware-Update automatisch gepusht, Linux braucht keine Microsoft-Signatur”.

Das ist Überlebensfehler (Survivorship Bias). Fedoras fwupd funktioniert nur, weil:

1. Der Hardware-Hersteller (z. B. Lenovo) ein Capsule-Update mit den neuen Zertifikaten auf LVFS hochgeladen hat.
2. Die Firmware des Herstellers erlaubt, dass die Betriebssystemseite Variablen schreibt (nicht alle Hersteller erlauben das – HP und Fujitsu sind dafür bekannt, db-Schreibvorgänge zu sperren).
3. Das Gerätemodell in der Support-Matrix des Herstellers enthalten ist.

Für Huawei MateBook-Nutzer trifft keine dieser Bedingungen zu. Die Zertifikate befinden sich im Firmware-NVRAM, nicht in /boot/efi. Keine Linux-Distribution kann „auf magische Weise” Zertifikate injizieren, die der OEM nicht autorisiert hat und die die Firmware ablehnt.

3. Die Rettung durch den Setup Mode

3.1 Entdeckung des Goldstatus

Auf dem Huawei MateBook M1010 des Autors ergaben folgende Diagnosebefehle:

$ 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

Kernerkenntnisse:

• SecureBoot disabled: Die Startkette wird derzeit nicht geprüft.
• Platform is in Setup Mode: Die PK-Variable (Plattformschlüssel) ist leer.
• db-Variable fehlt: Die Signaturdatenbank existiert nicht im NVRAM – nur der werksseitige dbDefault ist noch vorhanden.

3.2 Warum Setup Mode eine Superkraft ist

Im User Mode (Normalbetrieb) erfordert das Schreiben in db signierte .auth-Dateien. Die Signatur muss vom vorhandenen KEK verifiziert werden – dessen privater Schlüssel jedoch ausschließlich bei Microsoft liegt. Einzelpersonen können keine gültige Signatur erzeugen.

Im Setup Mode (PK ist leer) erzwingt die Firmware keine Signaturprüfung für Variablen-Schreibvorgänge. Das bedeutet, dass unsignierte rohe .esl-Dateien (EFI Signature List) direkt in db, KEK und PK geschrieben werden können.

stateDiagram-v2
    [*] --> SetupMode: Werksreset / PK löschen
    [*] --> UserMode: Normaler Start, PK registriert

    SetupMode --> UserMode: PK.auth schreiben (selbstsigniert)
    UserMode --> SetupMode: PK löschen / Werksschlüssel wiederherstellen

    state SetupMode {
        [*] --> db_write_unsigned
        db_write_unsigned --> [*]: efi-updatevar -f datei.esl db
        note right of db_write_unsigned
            Keine Signatur nötig.
            Kein KEK-Privatey erforderlich.
            Direktes Schreiben in NVRAM.
        end note
    }

    state UserMode {
        [*] --> db_write_signed
        db_write_signed --> [*]: efi-updatevar -f datei.auth db
        note right of db_write_signed
            KEK-signierte .auth-Datei nötig.
            KEK-Privatey nur bei Microsoft.
            Einzelpersonen ausgesperrt.
        end note
    }

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

Abbildung 4: Zustandsautomat für den Zugriff auf UEFI-Secure-Boot-Variablen. Der Setup Mode (grün) ist der einzige Zustand, in dem Einzelpersonen Zertifikate ohne Microsofts Privatey schreiben können.

4. Risikomodellierung: Warum „Linux braucht keine Signatur” nicht stimmt

4.1 Bedrohungsfläche

Sei (R) das gesamte Bootzeit-Risiko, aufgeschlüsselt als:

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

wobei:

• (R_{bootkit}): Wahrscheinlichkeit einer Firmware-Malware-Infektion (z. B. BlackLotus, CosmicStrand)
• (R_{compat}): Wahrscheinlichkeit zukünftiger Systemupdate-Fehler aufgrund von Signaturprüfungen
• (R_{maint}): Wartungskosten der manuellen Verwaltung einer nicht standardmäßigen Startkette

Nach Deaktivierung von Secure Boot und Ablauf der 2011-Zertifikate:

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

dbx (Sperrliste) kann nicht aktualisiert werden – bekannte anfällige Bootloader- und Shim-Versionen können von der Firmware nicht auf die Blacklist gesetzt werden. Das Immunsystem des Systems wird dauerhaft eingefroren.

4.2 Kompatibilitätsrisiko-Matrix

Tabelle 1: Kompatibilitäts- und Sicherheitsmatrix. Die Spalte „Nur 2011-Zertifikate” repräsentiert den Gestrandet-Status nach Juni 2026.

5. Reine Linux-Reparatur: Schritt-für-Schritt-Anleitung

5.1 Voraussetzungen

• Root-Rechte auf dem Ziel-Linux-System
• Installierte Pakete: efitools, openssl, uuid-runtime
• Internetzugang zum Herunterladen der von Microsoft veröffentlichten 2023-Zertifikate
• Sicherung der aktuellen NVRAM-Variablen (falls vorhanden)

5.2 Phase 1: Zertifikate beschaffen

# Arbeitsverzeichnis erstellen
mkdir -p ~/secureboot && cd ~/secureboot

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

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

# In PEM-Format für efitools konvertieren
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: EFI-Signaturliste erstellen

# Zufällige GUID für Signaturlisten-Besitz generieren
uuidgen --random > guid.txt
GUID=$(cat guid.txt)

# Zertifikate in ESL (EFI Signature List) konvertieren
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: In NVRAM injizieren (Setup Mode)

Da sich die Plattform im Setup Mode befindet, werden unsignierte .esl-Dateien direkt geschrieben. Keine .auth-Signatur erforderlich.

# db-Variable erstmalig anlegen (ohne -a-Flag)
sudo efi-updatevar -f MicUEFICA2023.esl db

# Zweites Zertifikat hinzufügen (-a-Flag)
sudo efi-updatevar -a -f WinUEFICA2023.esl db

Verifizierung:

sudo mokutil --db

Erwarteter Ausgabeausschnitt:

[...]
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: Setup Mode verlassen (empfohlen, aber nicht zwingend)

Das System im Setup Mode zu belassen ist gefährlich – jedes Betriebssystem oder jeder bösartige Bootloader könnte db modifizieren. Wir generieren einen persönlichen Plattformschlüssel (PK), um in den User Mode zu wechseln, während Secure Boot deaktiviert bleibt.

# Selbstsignierten Plattformschlüssel generieren
openssl req -new -x509 -newkey rsa:2048 \
  -subj "/CN=Personal MateBook PK/" \
  -keyout PK.key -out PK.pem \
  -days 3650 -nodes

# In DER für ESL-Verarbeitung konvertieren
openssl x509 -in PK.pem -out PK.der -outform DER

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

# PK schreiben, um Setup Mode zu verlassen
sudo efi-updatevar -f PK.esl PK

# Statusänderung verifizieren
sudo mokutil --sb-state
# Erwartet: "SecureBoot disabled" + "Platform is in User Mode"

5.6 Vollständiges Ablaufdiagramm

flowchart TD
    A[Start: Huawei MateBook<br/>Reine Linux-Umgebung] --> B{Status prüfen}
    B -->|mokutil --sb-state| C[Im Setup Mode?<br/>PK leer?]
    C -->|Ja| D[Microsoft<br/>2023-Zertifikate<br/>herunterladen]
    C -->|Nein| E[BIOS aufrufen → PK löschen<br/>→ Neustart nach Linux]

    D --> F[DER → PEM → ESL konvertieren]
    F --> G[efi-updatevar -f cert.esl db]
    G --> H{Verifizieren<br/>mokutil --db}
    H -->|2023-Zertifikat vorhanden| I[Persönlichen PK generieren]
    H -->|Fehlt| J[Debuggen: dmesg prüfen<br/>efivarfs-Berechtigungen]

    I --> K[efi-updatevar -f PK.esl PK]
    K --> L[Setup Mode verlassen<br/>→ User Mode]
    L --> M[Zukunftssicher:<br/>2023-Zertifikate in db<br/>SecureBoot weiterhin aus]

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

Abbildung 5: Entscheidungsablauf der reinen Linux-Reparatur für Huawei MateBook-Geräte im Setup Mode.

6. Grenzfälle und Fehlermodi

6.1 Wenn efi-updatevar Permission denied zurückgibt

Manche OEMs (HP, Fujitsu sowie zukünftige Huawei-Firmware-Versionen) sperren NVRAM-Schreibvorgänge auf Firmware-Ebene, selbst im Setup Mode. Falls dies auftritt:

Error: Could not update variable: Permission denied

Alternative: KeyTool.efi (aus dem efitools-Paket) verwenden, direkt aus der EFI-Shell oder dem Boot-Menü starten. Es bietet eine grafische Oberfläche für den Zertifikatsregistrierungsprozess und kann Betriebssystem-seitige Syscall-Beschränkungen umgehen.

6.2 Wenn die db-Variable bereits existiert

Wenn ls /sys/firmware/efi/efivars/ eine Datei db-8be4df61-93ca-11d2-aa0d-00e098032b8c (Standard-EFI-Globalvariable-GUID) anzeigt, alle Schreibvorgänge mit dem Anhänge-Flag durchführen:

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

6.3 NVIDIA-GPU-Schwarzbild-Risiko

Einige ältere NVIDIA-GPUs (GTX 600/700/900-Serie und frühe 10er-Serie) haben UEFI-GOP-Treiber, die nur von Microsoft UEFI CA 2011 signiert sind. Wenn Secure Boot nach Juni 2026 aktiviert wird, ohne dass die 2023-CA registriert ist, können diese GPUs den Bildschirm möglicherweise nicht initialisieren, was vor Betriebssystem-Übernahme zu einem Schwarzbild führt.

Abhilfe: Das vorliegende Schema registriert die 2023-Zertifikate und hält Secure Boot deaktiviert. So bleibt die zukünftige Kompatibilität erhalten, ohne dass die GPU-Option-ROM beim Start geprüft wird.

7. Fazit

Der UEFI-Zertifikatsablauf 2026 ist kein Windows-Problem – er ist ein Problem des Vertrauensankers auf Firmware-Ebene. Für Huawei MateBook-Nutzer, die reines Linux betreiben, führen fehlende LVFS-Unterstützung und der Ausschluss von der Microsoft-Whitelist zu einer echten Wartungsklippe.

Doch die Entdeckung, dass das Gerät im Setup Mode festsitzt, verwandelt ein scheinbar unmögliches Plattform-Lockout-Szenario in ein direktes NVRAM-Injektionsproblem. Die 2023-Zertifikate können in einer reinen Linux-Umgebung – ohne Windows, ohne Microsofts Privatey, ohne fwupd – nativ mit efitools registriert werden.

„Linux braucht keine Microsoft-Signatur” ist technisch für den heutigen Start richtig, aber für die morgige Wartung katastrophal falsch. Die 2023-Zertifikate jetzt zu registrieren, ist eine Absicherung für zukünftige Shim-Updates, GPU-Firmware und Dual-Boot-Szenarien – andernfalls werden sie alle mit dem alleinigen 2011-Vertrauensanker still und leise versagen.

Anhang A: Kurzreferenz-Befehle

# Aktuellen Status prüfen
sudo mokutil --sb-state
sudo mokutil --db | grep -i "2023"
ls /sys/firmware/efi/efivars/ | grep -i db

# Herunterladen und konvertieren
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

# Generieren und schreiben
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

Anhang B: Glossar

Dokumentversion: 1.0.0
Getestete Plattform: HUAWEI BoF-XX (M1010), Ubuntu Resolute Raccoon, Kernel 7.0.0-12-generic