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 Vertraünskette 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 Vertraünskette (vor 2026)

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

1.3 Vertraünskette (nach 2026, Idealzustand)

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

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.

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 daürhaft 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

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 Vertraünsankers 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 – ändernfalls werden sie alle mit dem alleinigen 2011-Vertraünsanker 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