Linux 與安全開機（Secure Boot）憑證到期問題（2025） （★ 102 分）
啟用 Secure Boot（安全開機）的 Linux 使用者，可能會受到 Microsoft 舊 UEFI 簽署憑證到期與換發的影響。許多 Linux 發行版透過 shim（Linux 發行版常用的第一階段 UEFI 開機載入程式）啟動核心，而 shim 長期仰賴 Microsoft 2011 年的第三方 UEFI 憑證簽署；文中指出這條舊信任鏈即將不再適合簽署新的 shim。Microsoft 2023 UEFI 第三方金鑰已可使用，但不少電腦的韌體資料庫尚未納入，因此未來新的 Linux 安裝媒體若只使用新金鑰簽署，可能無法在舊韌體上以 Secure Boot 開機。既有已安裝系統通常不會突然失效，主要風險集中在新安裝、救援媒體、未來 shim 安全更新，以及韌體是否已取得新金鑰。
文章指出，更新路徑牽涉多個層級：硬體廠商可提供完整韌體更新，或透過 KEK（Key Exchange Key，金鑰交換金鑰）與受信任簽章資料庫（db）更新，把 Microsoft 2023 UEFI CA 加入韌體信任清單。LVFS（Linux Vendor Firmware Service，Linux 廠商韌體服務）與 fwupd（Linux 上用來套用韌體更新的工具）是 Linux 端的重要管道；相關維護者表示，近期 fwupd 已強化處理能力，KEK 與 db 更新成功率約在 98% 至 99%。但即使 1% 失敗，乘上大量裝置仍會形成可觀問題，尤其老舊 BIOS/UEFI 可能因 EFI 變數儲存空間碎片化而無法寫入更新，有時需重開機或將 BIOS 設定恢復出廠值才有機會完成。
若硬體廠商不再提供更新，或平台金鑰（PK, Platform Key）管理出問題，使用者可能只能暫時或永久關閉 Secure Boot 才能安裝新版 Linux。文章也提到，部分韌體實作未必會檢查憑證有效期限；真正確定的是 Microsoft 到期後不會再用舊金鑰簽署新的 shim，因此繼續依賴舊 shim 會讓日後安全修補變得困難。整體而言，這凸顯 Linux 在 Secure Boot 生態中仍受 Microsoft 與硬體廠商控制的信任根影響，特別是 Linux 發行版通常仍希望支援比 Windows 生態更老的硬體。
Hacker News 討論中，許多人補充實務檢查方式，例如用 mokutil --sb-state 確認 Secure Boot 是否啟用，或用 mokutil --db --short 查看韌體中是否已有 Microsoft 2023 金鑰；也有人引用 Debian 文件與 Proxmox 在虛擬機 BIOS 更新上的提示。較技術性的回應認為，多數 UEFI 韌體不會檢查憑證日期，因為開機前缺乏可信時間來源，若嚴格執行到期檢查，甚至可能讓 PCIe 顯示卡、網路卡等 option ROM（硬體擴充卡開機韌體）無法初始化。也有使用者提醒雙系統與 BitLocker（Windows 磁碟加密功能）使用者要保存 TPM（Trusted Platform Module，可信平台模組）復原金鑰，因為 Secure Boot 金鑰變更可能改變開機量測結果。
討論也延伸到 Secure Boot 的信任模型。部分 Linux 使用者認為依賴 Microsoft 金鑰本身就是問題，Linux-only 機器乾脆關閉 Secure Boot 最省事；另一些人則指出可自行建立並註冊金鑰，只是這對一般使用者與安裝媒體並不友善，因此多數發行版才採用 shim 作為折衷方案。也有人強調 Secure Boot 若搭配全磁碟加密與 TPM，可降低開機載入程式或核心遭竄改的風險。整體共識偏向「不太可能造成大量既有系統無法開機」，但使用者、發行版與硬體廠商仍需及早處理金鑰更新，尤其是老舊硬體、新安裝媒體與虛擬機環境。
👥 51 則討論、評論 💬
https://news.ycombinator.com/item?id=48633941