हुवावे MateBook Linux Secure Boot प्रमाणपत्र संकट: 2026 UEFI CA समाप्ति उत्तरजीविता गाइड

दिनांक: 30 मई 2026 प्लेटफ़ॉर्म: HUAWEI BoF-XX (MateBook M1010), 12th Gen Intel Core i7-1260P, Ubuntu Resolute Raccoon (Noble), GNOME 50.0 स्थिति: Platform is in Setup Mode, SecureBoot अक्षम, db चर अनुपस्थित

सारांश

27 जून 2026 को Microsoft UEFI CA 2011 रूट प्रमाणपत्र समाप्त हो जाएगा। अधिकांश Windows उपयोगकर्ताओं के लिए यह केवल एक पृष्ठभूमि अपडेट है। लेकिन असमर्थित OEM हार्डवेयर वाले Linux उपयोगकर्ताओं के लिए—विशेष रूप से वे हुवावे MateBook जो Linux Vendor Firmware Service (LVFS) और Microsoft व्हाइटलिस्ट दोनों पर नहीं हैं—यह एक टाइम बम है। यह लेख संकट का पूर्ण तकनीकी विच्छेदन प्रस्तुत करता है, “Linux को Microsoft हस्ताक्षर की आवश्यकता नहीं” के मिथक को खारिज करता है, और एक युद्ध-परीक्षित, शुद्ध Linux वातावरण में सुधार पथ प्रदान करता है—उन उपकरणों के लिए जो Setup Mode में फंसे हैं और जिनके पास कोई आधिकारिक विक्रेता समर्थन चैनल नहीं है।

1. समाप्ति का विच्छेदन

1.1 वास्तव में क्या मर रहा है

Secure Boot की विश्वास श्रृंखला Microsoft द्वारा 2011 में जारी तीन प्रमाणपत्रों पर निर्भर करती है:

प्रमाणपत्र	भूमिका	समाप्ति तिथि
`Microsoft Corporation KEK CA 2011`	कुंजी विनिमय कुंजी (KEK) — `db`/`dbx` अपडेट पर हस्ताक्षर	जून 2026
`Microsoft UEFI CA 2011`	तृतीय-पक्ष बूटलोडर, ड्राइवर, Linux shim सत्यापित करता है	जून 2026
`Microsoft Windows Production PCA 2011`	Windows Boot Manager पर हस्ताक्षर	अक्टूबर 2026

ये प्रमाणपत्र डिस्क पर नहीं हैं। ये मदरबोर्ड फ़र्मवेयर NVRAM वेरिएबल्स (db, KEK, PK, dbx) में मौजूद हैं। समाप्ति के बाद, X.509 वैधता को सख्ती से जाँचने वाला फ़र्मवेयर केवल 2011 CA द्वारा हस्ताक्षरित किसी भी बूटलोडर को लोड करने से इनकार कर देगा—जिसमें भविष्य के Linux shim, NVIDIA GPU Option ROM, और अपडेटेड Windows Boot Manager शामिल हैं।

1.2 विश्वास श्रृंखला (2026 से पहले)

graph TD
    A[प्लेटफ़ॉर्म कुंजी / PK<br/>OEM या Microsoft] -->|हस्ताक्षर| B[कुंजी विनिमय कुंजी / KEK<br/>Microsoft KEK CA 2011]
    B -->|हस्ताक्षर| C[हस्ताक्षर डेटाबेस / db<br/>Microsoft UEFI CA 2011]
    C -->|सत्यापन| D[shim.efi<br/>Linux बूटलोडर]
    C -->|सत्यापन| E[Windows Boot Manager]
    C -->|सत्यापन| F[NVIDIA GOP / Option ROM]
    D -->|सत्यापन| G[GRUB2]
    G -->|सत्यापन| H[Linux कर्नेल]
    style C fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style B fill:#ff9999,stroke:#cc0000,stroke-width:3px

चित्र 1: 2011 प्रमाणपत्र (लाल) संपूर्ण तृतीय-पक्ष बूट श्रृंखला को支撑 करते हैं। समाप्ति के बाद सभी निचले घटक सत्यापन खो देंगे।

1.3 विश्वास श्रृंखला (2026 के बाद, आदर्श स्थिति)

graph TD
    A[प्लेटफ़ॉर्म कुंजी / PK] -->|हस्ताक्षर| B[कुंजी विनिमय कुंजी / KEK<br/>Microsoft KEK 2K CA 2023]
    B -->|हस्ताक्षर| C[हस्ताक्षर डेटाबेस / db<br/>Microsoft UEFI CA 2023]
    B -->|हस्ताक्षर| D[हस्ताक्षर डेटाबेस / db<br/>Windows UEFI CA 2023]
    C -->|सत्यापन| E[shim.efi<br/>2023 हस्ताक्षरित संस्करण]
    D -->|सत्यापन| F[Windows Boot Manager<br/>2023 हस्ताक्षरित संस्करण]
    C -->|सत्यापन| G[NVIDIA GOP<br/>2023 हस्ताक्षरित संस्करण]
    E -->|सत्यापन| H[GRUB2]
    H -->|सत्यापन| I[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

चित्र 2: 2023 प्रमाणपत्र (हरा) 26 जून 2026 से पहले db में मौजूद होना चाहिए ताकि आगे की संगतता बनी रहे।

2. हुवावे जाल: अद्यतन पारिस्थितिकी तंत्र से परित्यक्त

2.1 OEM व्हाइटलिस्ट समस्या

हुवावे एक सख्त, सीमित SKU व्हाइटलिस्ट बनाए रखता है, केवल वे मॉडल Windows Update के माध्यम से प्रमाणपत्र रोटेशन प्राप्त कर सकते हैं। हुवावे के आधिकारिक समर्थन दस्तावेज़ के अनुसार, केवल 19 विशिष्ट SKU को Windows Update के माध्यम से 2023 प्रमाणपत्र प्राप्त करने की गारंटी है:

MateBook X Pro 2024 / 2022
MateBook 14 2023 (गैर S)
MateBook D16 2024
MateStation S (विशिष्ट बैच)
…… (अन्य 15 मॉडल)

इस लेख का मुख्य पात्र MateBook 14 2022 (BoF-XX / M1010) स्पष्ट रूप से सूची में नहीं है। इसका मतलब है कि भले ही Windows 11 स्थापित हो, Secure-Boot-Update शेड्यूल किए गए कार्य के ट्रिगर होने की संभावना नहीं है, या फ़र्मवेयर वेरिएबल लेखन को अस्वीकार कर देगा।

2.2 LVFS की कमी

graph LR
    subgraph विक्रेता फ़र्मवेयर अद्यतन पारिस्थितिकी तंत्र
        A[Windows Update] -->|प्रमाणपत्र भेजें| B[OEM फ़र्मवेयर<br/>Dell, Lenovo, HP]
        C[LVFS / fwupd] -->|.cab भेजें| D[Linux Vendor Firmware Service]
        D -->|समर्थन| E[Dell XPS]
        D -->|समर्थन| F[Lenovo ThinkPad]
        D -->|समर्थन| G[System76]
        D -->|समर्थन| H[Framework]
        D -.->|अनुपलब्ध| I[HUAWEI MateBook]
    end
    style I fill:#ff9999,stroke:#cc0000,stroke-width:3px

चित्र 3: हुवावे LVFS को फ़र्मवेयर अपडेट जारी नहीं करता। Linux उपयोगकर्ता fwupdmgr के माध्यम से आधिकारिक BIOS या प्रमाणपत्र अद्यतन प्राप्त नहीं कर सकते।

2.3 “Fedora ने स्वचालित रूप से मेरे प्रमाणपत्र अपडेट कर दिए” का भ्रम

सामुदायिक चर्चाओं में एक सामान्य प्रतिवाद है—“Fedora ने स्वचालित रूप से फ़र्मवेयर अपडेट भेज दिया, Linux को Microsoft हस्ताक्षर की बिल्कुल आवश्यकता नहीं है”।

यह उत्तरजीविता पूर्वाग्रह है। Fedora का fwupd काम करता है क्योंकि:

हार्डवेयर विक्रेता (जैसे Lenovo) ने LVFS पर नए प्रमाणपत्रों वाले कैप्सूल अपडेट अपलोड किए।
उस विक्रेता का फ़र्मवेयर OS-पक्ष वेरिएबल लेखन की अनुमति देता है (सभी विक्रेता नहीं देते—HP और Fujitsu db लेखन को लॉक करने के लिए जाने जाते हैं)।
डिवाइस मॉडल विक्रेता के समर्थन मैट्रिक्स में है।

हुवावे MateBook उपयोगकर्ताओं के लिए, उपरोक्त में से कोई भी शर्त पूरी नहीं होती। प्रमाणपत्र फ़र्मवेयर NVRAM में मौजूद हैं, /boot/efi में नहीं। कोई भी Linux वितरण उन प्रमाणपत्रों को “जादुई रूप से” इंजेक्ट नहीं कर सकता जिन्हें OEM ने अधिकृत नहीं किया है और जिन्हें फ़र्मवेयर स्वीकार करने से इनकार करता है।

3. Setup Mode की जीवन रेखा

3.1 स्वर्णिम स्थिति की खोज

लेखक के हुवावे MateBook M1010 पर, निम्नलिखित निदान आदेश चलाए गए:

$ 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

मुख्य खोजें:

SecureBoot disabled: बूट श्रृंखला वर्तमान में अप्रमाणित है।
Platform is in Setup Mode: PK (प्लेटफ़ॉर्म कुंजी) वेरिएबल खाली है।
db वेरिएबल अनुपस्थित: हस्ताक्षर डेटाबेस NVRAM में मौजूद नहीं है—केवल फ़ैक्टरी डिफ़ॉल्ट dbDefault बचा है।

3.2 Setup Mode सुपरपावर क्यों है

User Mode (सामान्य संचालन) में, db में लिखने के लिए हस्ताक्षरित .auth फ़ाइलों की आवश्यकता होती है। हस्ताक्षर मौजूदा KEK द्वारा सत्यापित होना चाहिए—और KEK की निजी कुंजी Microsoft के पास अनन्य रूप से है। कोई व्यक्तिगत उपयोगकर्ता वैध हस्ताक्षर उत्पन्न नहीं कर सकता।

Setup Mode (PK खाली) में, फ़र्मवेयर वेरिएबल लेखन के लिए हस्ताक्षर सत्यापन लागू नहीं करता। इसका मतलब है कि बिना हस्ताक्षरित कच्ची .esl (EFI Signature List) फ़ाइलें सीधे db, KEK और PK में लिखी जा सकती हैं।

stateDiagram-v2
    [*] --> SetupMode: फ़ैक्टरी रीसेट / PK हटाएँ
    [*] --> UserMode: सामान्य बूट, PK पंजीकृत

    SetupMode --> UserMode: PK.auth लिखें (स्व-हस्ताक्षरित)
    UserMode --> SetupMode: PK हटाएँ / फ़ैक्टरी कुंजी पुनर्स्थापित

    state SetupMode {
        [*] --> db_write_unsigned
        db_write_unsigned --> [*]: efi-updatevar -f file.esl db
        note right of db_write_unsigned
            कोई हस्ताक्षर नहीं चाहिए।
            KEK निजी कुंजी की आवश्यकता नहीं।
            सीधे NVRAM में लिखें।
        end note
    }

    state UserMode {
        [*] --> db_write_signed
        db_write_signed --> [*]: efi-updatevar -f file.auth db
        note right of db_write_signed
            KEK-हस्ताक्षरित .auth फ़ाइल चाहिए।
            KEK निजी कुंजी केवल Microsoft के पास।
            व्यक्तिगत उपयोगकर्ता के लिए अवरुद्ध।
        end note
    }

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

चित्र 4: UEFI Secure Boot वेरिएबल एक्सेस स्टेट मशीन। Setup Mode (हरा) एकमात्र ऐसी अवस्था है जहाँ व्यक्तिगत उपयोगकर्ता Microsoft की निजी कुंजी के बिना प्रमाणपत्र लिख सकता है।

4. जोखिम मॉडलिंग: “Linux को हस्ताक्षर की आवश्यकता नहीं” क्यों गलत है

4.1 खतरे की सतह

मान लें (R) कुल बूट समय जोखिम है, इसे विभाजित करें:

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

जहाँ:

(R_{bootkit}): फ़र्मवेयर-स्तरीय मैलवेयर संक्रमण की संभावना (जैसे BlackLotus, CosmicStrand)
(R_{compat}): हस्ताक्षर सत्यापन के कारण भविष्य के सिस्टम अपडेट के विफल होने की संभावना
(R_{maint}): गैर-मानक बूट श्रृंखला के मैन्युअल प्रबंधन की रखरखाव लागत

जब Secure Boot बंद है और 2011 प्रमाणपत्र समाप्त हो गए हैं:

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

dbx (निरसन सूची) अद्यतन न मिलने का मतलब है कि ज्ञात कमजोरियों वाले बूटलोडर और shim संस्करणों को फ़र्मवेयर द्वारा ब्लैकलिस्ट नहीं किया जा सकता। सिस्टम की प्रतिरक्षा प्रणाली स्थायी रूप से स्थिर हो गई है।

4.2 संगतता जोखिम मैट्रिक्स

परिदृश्य	केवल 2011 प्रमाणपत्र	2023 प्रमाणपत्र पंजीकृत	SecureBoot बंद
वर्तमान Linux बूट	✅	✅	✅
भविष्य shim अद्यतन (2023 हस्ताक्षरित)	❌	✅	✅
नया NVIDIA ड्राइवर (GOP 2023 हस्ताक्षरित)	❌	✅	N/A
Windows दोहरा बूट (भविष्य में स्थापना)	❌	✅	✅
`dbx` निरसन सूची अद्यतन	❌	✅	N/A
Bootkit रक्षा क्षमता	कम	उच्च	कोई नहीं

तालिका 1: संगतता और सुरक्षा मैट्रिक्स। “केवल 2011 प्रमाणपत्र” कॉलम जून 2026 के बाद फंसी हुई स्थिति दर्शाता है।

5. शुद्ध Linux सुधार: चरण-दर-चरण

5.1 पूर्व शर्तें

लक्ष्य Linux सिस्टम पर रूट पहुँच
efitools, openssl, uuid-runtime स्थापित
Microsoft के 2023 प्रमाणपत्र डाउनलोड करने के लिए इंटरनेट कनेक्शन
वर्तमान NVRAM वेरिएबल्स का बैकअप (यदि मौजूद हों)

5.2 चरण 1: प्रमाणपत्र प्राप्त करें

# कार्य निर्देशिका बनाएँ
mkdir -p ~/secureboot && cd ~/secureboot

# Microsoft UEFI CA 2023 डाउनलोड करें (DER प्रारूप)
wget -O MicUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239872"

# Windows UEFI CA 2023 डाउनलोड करें (DER प्रारूप)
wget -O WinUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239776"

# efitools के लिए PEM प्रारूप में बदलें
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 चरण 2: EFI हस्ताक्षर सूची उत्पन्न करें

# हस्ताक्षर सूची स्वामित्व के लिए यादृच्छिक GUID उत्पन्न करें
uuidgen --random > guid.txt
GUID=$(cat guid.txt)

# प्रमाणपत्रों को 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 चरण 3: NVRAM में इंजेक्ट करें (Setup Mode)

क्योंकि प्लेटफ़ॉर्म Setup Mode में है, बिना हस्ताक्षरित .esl फ़ाइलें सीधे लिखें। .auth हस्ताक्षर की आवश्यकता नहीं।

# पहली बार db वेरिएबल बनाएँ (बिना -a फ़्लैग)
sudo efi-updatevar -f MicUEFICA2023.esl db

# दूसरा प्रमाणपत्र जोड़ें (-a फ़्लैग)
sudo efi-updatevar -a -f WinUEFICA2023.esl db

सत्यापन:

sudo mokutil --db

अपेक्षित आउटपुट अंश:

[...]
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 चरण 4: Setup Mode से बाहर निकलें (अनुशंसित लेकिन अनिवार्य नहीं)

सिस्टम को Setup Mode में छोड़ना खतरनाक है—कोई भी OS या दुर्भावनापूर्ण बूटलोडर db को संशोधित कर सकता है। हम User Mode पर स्विच करने के लिए व्यक्तिगत प्लेटफ़ॉर्म कुंजी (PK) उत्पन्न करेंगे, जबकि Secure Boot अक्षम रहेगा।

# स्व-हस्ताक्षरित प्लेटफ़ॉर्म कुंजी उत्पन्न करें
openssl req -new -x509 -newkey rsa:2048 \
  -subj "/CN=Personal MateBook PK/" \
  -keyout PK.key -out PK.pem \
  -days 3650 -nodes

# ESL प्रसंस्करण के लिए DER में बदलें
openssl x509 -in PK.pem -out PK.der -outform DER

# ESL उत्पन्न करें
cert-to-efi-sig-list -g "$GUID" PK.der PK.esl

# Setup Mode से बाहर निकलने के लिए PK लिखें
sudo efi-updatevar -f PK.esl PK

# स्थिति परिवर्तन सत्यापित करें
sudo mokutil --sb-state
# अपेक्षित: "SecureBoot disabled" + "Platform is in User Mode"

5.6 पूर्ण प्रवाह चार्ट

flowchart TD
    A[शुरू: हुवावे MateBook<br/>शुद्ध Linux वातावरण] --> B{स्थिति जाँचें}
    B -->|mokutil --sb-state| C[Setup Mode में?<br/>PK खाली?]
    C -->|हाँ| D[Microsoft के<br/>2023 प्रमाणपत्र डाउनलोड करें]
    C -->|नहीं| E[BIOS में जाएँ → PK हटाएँ<br/>→ Linux पर रीबूट करें]

    D --> F[DER → PEM → ESL में बदलें]
    F --> G[efi-updatevar -f cert.esl db]
    G --> H{सत्यापित करें<br/>mokutil --db}
    H -->|2023 प्रमाणपत्र मौजूद| I[व्यक्तिगत PK उत्पन्न करें]
    H -->|अनुपस्थित| J[डीबग: dmesg जाँचें<br/>efivarfs अनुमतियाँ]

    I --> K[efi-updatevar -f PK.esl PK]
    K --> L[Setup Mode से बाहर<br/>User Mode में प्रवेश]
    L --> M[भविष्य के लिए तैयार:<br/>db में 2023 प्रमाणपत्र मौजूद<br/>SecureBoot अभी भी बंद]

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

चित्र 5: Setup Mode में हुवावे MateBook उपकरणों के लिए शुद्ध Linux सुधार निर्णय प्रवाह।

6. सीमांत मामले और विफलता मोड

6.1 यदि `efi-updatevar` `Permission denied` लौटाता है

कुछ OEM (HP, Fujitsu, और संभावित रूप से भविष्य के हुवावे फ़र्मवेयर संस्करण) Setup Mode में भी फ़र्मवेयर स्तर पर NVRAM लेखन को लॉक करते हैं। यदि ऐसा हो:

Error: Could not update variable: Permission denied

वैकल्पिक समाधान: efitools पैकेज से KeyTool.efi का उपयोग करें, इसे सीधे EFI शेल या बूट मेनू से चलाएँ। यह प्रमाणपत्र पंजीकरण के लिए ग्राफ़िकल इंटरफ़ेस प्रदान करता है और OS-स्तरीय सिस्टम कॉल सीमाओं को बायपास कर सकता है।

6.2 यदि `db` वेरिएबल पहले से मौजूद है

यदि ls /sys/firmware/efi/efivars/ में db-8be4df61-93ca-11d2-aa0d-00e098032b8c फ़ाइल (मानक EFI वैश्विक वेरिएबल GUID) दिखाई देती है, तो सभी लेखन जोड़ फ़्लैग के साथ करें:

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

6.3 NVIDIA GPU ब्लैक स्क्रीन जोखिम

कुछ पुराने NVIDIA GPU (GTX 600/700/900 श्रृंखला और प्रारंभिक 10 श्रृंखला) में UEFI GOP ड्राइवर केवल Microsoft UEFI CA 2011 द्वारा हस्ताक्षरित है। यदि जून 2026 के बाद Secure Boot सक्षम किया जाता है लेकिन 2023 CA पंजीकृत नहीं है, तो ये GPU डिस्प्ले को प्रारंभ करने में विफल हो सकते हैं, जिससे OS के संभालने से पहले ब्लैक स्क्रीन हो सकती है।

शमन: यह लेख का समाधान 2023 प्रमाणपत्र पंजीकृत करते समय Secure Boot को अक्षम रखता है। यह भविष्य की संगतता को संरक्षित करता है बिना बूट के समय GPU Option ROM सत्यापन को ट्रिगर किए।

7. निष्कर्ष

2026 का UEFI प्रमाणपत्र समाप्ति Windows की समस्या नहीं है—यह फ़र्मवेयर स्तर पर विश्वास एंकर की समस्या है। शुद्ध Linux चलाने वाले हुवावे MateBook उपयोगकर्ताओं के लिए, LVFS असमर्थन और Microsoft व्हाइटलिस्ट से बहिष्कार ने एक वास्तविक रखरखाव कगार पैदा कर दिया है।

लेकिन डिवाइस को Setup Mode में फंसा पाना एक असंभव प्रतीत होने वाले प्लेटफ़ॉर्म लॉक परिदृश्य को एक सीधी NVRAM इंजेक्शन समस्या में बदल देता है। 2023 प्रमाणपत्र शुद्ध Linux वातावरण में, Windows के बिना, Microsoft की निजी कुंजी के बिना, fwupd के बिना, सीधे efitools के साथ मूल रूप से पंजीकृत किए जा सकते हैं।

“Linux को Microsoft हस्ताक्षर की आवश्यकता नहीं” आज के बूट के लिए तकनीकी रूप से सही है, लेकिन कल के रखरखाव के लिए यह एक विनाशकारी गलती है। अभी 2023 प्रमाणपत्र पंजीकृत करना भविष्य के shim अपडेट, GPU फ़र्मवेयर और दोहरे बूट परिदृश्यों के लिए एक बीमा है—अन्यथा वे सभी केवल 2011 विश्वास एंकर के साथ चुपचाप विफल हो जाएँगे।

परिशिष्ट A: त्वरित संदर्भ आदेश

# वर्तमान स्थिति जाँचें
sudo mokutil --sb-state
sudo mokutil --db | grep -i "2023"
ls /sys/firmware/efi/efivars/ | grep -i db

# डाउनलोड करें और बदलें
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

# उत्पन्न करें और लिखें
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

परिशिष्ट B: शब्दावली

शब्द	परिभाषा
PK	प्लेटफ़ॉर्म कुंजी (Platform Key) — Secure Boot वेरिएबल अपडेट का विश्वास मूल
KEK	कुंजी विनिमय कुंजी (Key Exchange Key) — `db` और `dbx` अपडेट पर हस्ताक्षर
db	हस्ताक्षर डेटाबेस (Signature Database) — अनुमत बूटलोडर/ड्राइवरों की श्वेतसूची
dbx	निषिद्ध हस्ताक्षर डेटाबेस (Forbidden Signature Database) — निरस्त हस्ताक्षरों की कालीसूची
Setup Mode	PK खाली है, फ़र्मवेयर वेरिएबल लेखन के लिए हस्ताक्षर सत्यापन लागू नहीं करता
User Mode	PK पंजीकृत, सभी वेरिएबल अपडेट क्रिप्टोग्राफ़िक रूप से हस्ताक्षरित होने चाहिए
shim	प्रथम-स्तरीय Linux बूटलोडर, Microsoft UEFI CA द्वारा हस्ताक्षरित
LVFS	Linux Vendor Firmware Service — Linux के लिए केंद्रीकृत फ़र्मवेयर वितरण सेवा

दस्तावेज़ संस्करण: 1.0.0
परीक्षण प्लेटफ़ॉर्म: HUAWEI BoF-XX (M1010), Ubuntu Resolute Raccoon, कर्नेल 7.0.0-12-generic

हुवावे MateBook Linux Secure Boot प्रमाणपत्र संकट: 2026 UEFI CA समाप्ति उत्तरजीविता गाइड

सारांश

1. समाप्ति का विच्छेदन

1.1 वास्तव में क्या मर रहा है

1.2 विश्वास श्रृंखला (2026 से पहले)

1.3 विश्वास श्रृंखला (2026 के बाद, आदर्श स्थिति)

2. हुवावे जाल: अद्यतन पारिस्थितिकी तंत्र से परित्यक्त

2.1 OEM व्हाइटलिस्ट समस्या

2.2 LVFS की कमी

2.3 “Fedora ने स्वचालित रूप से मेरे प्रमाणपत्र अपडेट कर दिए” का भ्रम

3. Setup Mode की जीवन रेखा

3.1 स्वर्णिम स्थिति की खोज

3.2 Setup Mode सुपरपावर क्यों है

4. जोखिम मॉडलिंग: “Linux को हस्ताक्षर की आवश्यकता नहीं” क्यों गलत है

4.1 खतरे की सतह

4.2 संगतता जोखिम मैट्रिक्स

5. शुद्ध Linux सुधार: चरण-दर-चरण

5.1 पूर्व शर्तें

5.2 चरण 1: प्रमाणपत्र प्राप्त करें

5.3 चरण 2: EFI हस्ताक्षर सूची उत्पन्न करें

5.4 चरण 3: NVRAM में इंजेक्ट करें (Setup Mode)

5.5 चरण 4: Setup Mode से बाहर निकलें (अनुशंसित लेकिन अनिवार्य नहीं)

5.6 पूर्ण प्रवाह चार्ट

6. सीमांत मामले और विफलता मोड

6.1 यदि `efi-updatevar` `Permission denied` लौटाता है

6.2 यदि `db` वेरिएबल पहले से मौजूद है

6.3 NVIDIA GPU ब्लैक स्क्रीन जोखिम

7. निष्कर्ष

परिशिष्ट A: त्वरित संदर्भ आदेश

परिशिष्ट B: शब्दावली

Share this page

Scan to share on WeChat

हुवावे MateBook Linux Secure Boot प्रमाणपत्र संकट: 2026 UEFI CA समाप्ति उत्तरजीविता गाइड

सारांश

1. समाप्ति का विच्छेदन

1.1 वास्तव में क्या मर रहा है

1.2 विश्वास श्रृंखला (2026 से पहले)

1.3 विश्वास श्रृंखला (2026 के बाद, आदर्श स्थिति)

2. हुवावे जाल: अद्यतन पारिस्थितिकी तंत्र से परित्यक्त

2.1 OEM व्हाइटलिस्ट समस्या

2.2 LVFS की कमी

2.3 “Fedora ने स्वचालित रूप से मेरे प्रमाणपत्र अपडेट कर दिए” का भ्रम

3. Setup Mode की जीवन रेखा

3.1 स्वर्णिम स्थिति की खोज

3.2 Setup Mode सुपरपावर क्यों है

4. जोखिम मॉडलिंग: “Linux को हस्ताक्षर की आवश्यकता नहीं” क्यों गलत है

4.1 खतरे की सतह

4.2 संगतता जोखिम मैट्रिक्स

5. शुद्ध Linux सुधार: चरण-दर-चरण

5.1 पूर्व शर्तें

5.2 चरण 1: प्रमाणपत्र प्राप्त करें

5.3 चरण 2: EFI हस्ताक्षर सूची उत्पन्न करें

5.4 चरण 3: NVRAM में इंजेक्ट करें (Setup Mode)

5.5 चरण 4: Setup Mode से बाहर निकलें (अनुशंसित लेकिन अनिवार्य नहीं)

5.6 पूर्ण प्रवाह चार्ट

6. सीमांत मामले और विफलता मोड

6.1 यदि efi-updatevar Permission denied लौटाता है

6.2 यदि db वेरिएबल पहले से मौजूद है

6.3 NVIDIA GPU ब्लैक स्क्रीन जोखिम

7. निष्कर्ष

परिशिष्ट A: त्वरित संदर्भ आदेश

परिशिष्ट B: शब्दावली

Share this page

6.1 यदि `efi-updatevar` `Permission denied` लौटाता है

6.2 यदि `db` वेरिएबल पहले से मौजूद है