情景
Windows Hyper-V 安裝 ubuntu server 24 時遇見錯誤。提示 The signed image's hash is not allowed (DB)。
解法
關閉 "啟用安全開機"，並開啟 "啟用信賴平台模組"(如果你沒想根本解決，也可以選擇跳過此步驟)。
成因
Secure Boot 的工作方式
- 開機時驗證
Secure Boot 會在系統啟動時檢查所有的開機元件（bootloader、kernel、驅動程式）的數位簽章。 它比對的依據是存在 UEFI 韌體裡的信任資料庫（db），裡面有允許的憑證與雜湊值。 - 阻擋未簽章或不受信任的程式碼
如果某個映像檔（例如 kernel image 或第三方驅動程式）的 hash 或簽章憑證不在資料庫裡，就會被判定為不可信，Secure Boot 會拒絕載入，出現你看到的錯誤訊息： 「the image's hash and certificate are not allowed」
為什麼關掉 Secure Boot 就好了
- 關掉後不再檢查：
一旦停用 Secure Boot，UEFI 就不再檢查簽章或 hash。任何映像檔或驅動程式都能載入，不管它有沒有被簽章，或是用什麼憑證簽章。 因此即使該映像的 hash/cert 不在允許清單中，也不會被阻擋。 - 本質上是跳過驗證機制：
Secure Boot 的目的是防止惡意軟體（bootkit、rootkit）在開機階段插入。如果關閉它，就等於告訴系統「不要驗證，直接執行就好」。
為什麼會遇到這種情況
- 自建或未簽章的 kernel/驅動：例如自己編的 Linux kernel 或某些第三方驅動程式。
- 使用社群版本：部分 Linux 發行版的某些模組沒有被 Microsoft 或 distro 的 key 簽章。
- Secure Boot 資料庫沒更新：信任清單（db）缺少必要的憑證，導致合法但未被登錄的映像被擋。
UEFI Secure Boot 的信任鏈與資料庫（都存於韌體 NVRAM）：
- PK（Platform Key）：整機的「最高」信任根。
- KEK（Key Exchange Key）：允許更新 db/dbx 的「管理者」鑰。
- db（Allow list）：允許的憑證或雜湊（可載入）。
- dbx（Deny list）：撤銷名單（即使簽過也要擋）。
開機流程常見路徑（以 Linux 為例）：
UEFI →（驗證）shim.efi（多半由 Microsoft 第三方 CA 簽）→（驗證）GRUB/systemd-boot →（驗證）Kernel（或 UKI） →（Kernel 內部）模組簽章強制。
只要某一段的執行檔/模組的簽章鏈結不到 db（或被 dbx 撤銷），就會看到像「the image's hash and certificate are not allowed」之類的錯誤。
完整解法
1) 自建或未簽章的 kernel / 驅動（DKMS/第三方）
哪裡會卡？
- 兩個常見層級：
- UEFI 層：若你把 kernel 打成 UKI（Unified Kernel Image, .efi） 或自行簽的 bootloader，要被 UEFI 直接驗證。你用的憑證若不在 db，就會被擋。
- Kernel 層（模組簽章強制）：啟用 Secure Boot 時，Linux kernel 會進入 lockdown，只允許載入帶有效 X.509 簽章且鑰在 kernel 信任金鑰圈（built-in key 或 MOK 匯入的 key）的 .ko 模組。否則就會出現： module verification failed: signature and/or required key missing Required key not available
為什麼會這樣？
- 你本機用 DKMS/手編的
.ko沒被「系統已信任的公鑰」簽過；或你的 UKI/bootloader 用自簽憑證，但該公鑰沒在 db/MOK 之中。
要保留 Secure Boot 的解法（推薦做法）
- 路線 A：MOK（Machine Owner Key）路線（最通用而且安全）
- 產生簽章鑰： openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -nodes -days 3650 -subj "/CN=My MOK/" openssl x509 -in MOK.crt -outform DER -out MOK.der
- 匯入 MOK（進 NVRAM，開機由 MokManager 互動確認）： sudo mokutil --import MOK.der # 會要求你設定一組臨時密碼；重開機後在藍色畫面完成 Enroll
- 用這把鑰簽 內核模組（單檔範例）： sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 MOK.key MOK.crt /path/to/module.ko 驗證： modinfo /path/to/module.ko | grep -i sig
- 若你是 UKI / .efi 路線，要讓 UEFI 也接受你的映像，可用 sbsign： sbsign --key MOK.key --cert MOK.crt --output vmlinuz.efi.signed vmlinuz.efi 然後由 shim/bootloader 載入這個已簽的映像。
- 路線 B：讓 DKMS 自動簽
- 多數發行版支援設定 DKMS 自動用你的 MOK key 簽新編出的模組（例如在 /etc/dkms/framework.conf 指定 sign_key、sign_cert，或用發行版提供的 helper）。
- 這樣每次 kernel 更新後 DKMS 重編也會自動產生「已簽章」的 .ko。
2) 使用「社群版本」：沒有被 Microsoft 或發行版 key 簽章
典型情境
- ZFS、NVIDIA（官方 runfile）、VirtualBox、VMware、某些 Wi-Fi/USB 驅動等，常用 DKMS 在你機器上即時編譯，因此不會帶上發行版的官方簽章。
- 有些第三方套件雖然提供已簽的
.ko，但用的是他們自己的憑證，Linux kernel 不一定信任（除非把他們的公鑰編進 kernel 或用 MOK 匯入）。
哪裡會卡？
- 幾乎都卡在 kernel 模組簽章強制（不是 UEFI 層），錯誤如上。
保留 Secure Boot 的解法
- 還是用 MOK 路線最穩：把第三方供應者的公鑰（若有）或你自己的公鑰匯入 MOK，並確保模組是用該私鑰簽過。
- 若供應者只提供未簽的
.ko，就用你自己的 MOK key 幫它簽。 - 某些發行版（例如 Fedora/Ubuntu 的特定 repo）會替外部模組做「akmods/簽章整合」，只要你的 MOK 已匯入，系統就能自動簽。
3) Secure Boot 資料庫沒更新（或撤銷清單變動）
這一類比較常見在 UEFI 層 就被擋住，訊息會更像你看到的「image's hash and certificate are not allowed」。
常見子情境
- 機器的 db 裡根本沒有 Microsoft 第三方 UEFI CA
- 有的 OEM/BIOS 把「允許第三方 UEFI CA」關掉了。這會導致 shim.efi（通常由 MS 第三方 CA 簽）直接被擋，連到 GRUB/Kernel 前就掛。
- 解法：進 BIOS/UEFI，把「Allow Microsoft 3rd-party UEFI CA」打開，或進入 Custom Mode 手動把需要的 CA/憑證加進 db（風險高，不熟不建議）。
- dbx（撤銷名單）更新把舊的 shim/bootloader 撤銷了
- 近年常因修補漏洞而把舊版 shim/GRUB 加進 dbx。結果：舊的、雖然被簽過，但因已被撤銷仍會被擋。
- 解法：在 OS 內更新到新的 shim-signed/bootloader 套件（發行版會提供），同時讓韌體/OS 把 dbx 更新到最新。更新後新的 shim 有新的簽章，能過驗證。
- 你用自簽的 UKI / Bootloader，但憑證只進了 MOK，卻沒有走 shim 的驗證路徑
- 注意：MOK 是 shim/Kernel 層用的（shim 驗證下一階段、Kernel 驗證模組）。UEFI 韌體本身不看 MOK。
- 如果你嘗試讓 UEFI 直接載入你自簽的 .efi，但你的公鑰沒進 db，就會被擋。
- 解法：要嘛讓 **shim（已被 MS 簽）**先起來，再由 shim 用 MOK 驗證你的下一階段；要嘛把你的公鑰放進 db（高風險，不建議一般使用者）。
診斷速查
搞清楚卡在哪一層
- 看 Secure Boot 狀態：
mokutil --sb-state
- 看 Kernel 是否在鎖定模式/模組拒載：
dmesg | egrep -i 'secureboot|lockdown|module verification|EFI'
- 檢查
.efi的簽章（UEFI 層相關）：sbverify --list /path/to/image.efi
# 或 pesign -S -i /path/to/image.efi - 檢查模組是否帶簽章（Kernel 層）：
modinfo /path/to/module.ko | grep -i sig
keyctl list %:.system_keyring
keyctl list %:.platform
風險與建議的優先順序
- 首選：MOK 路線（安全、通用、風險低）
用 MOK 匯入你的公鑰；用同一把私鑰簽 UKI（若需要）與 .ko 模組。 - 更新發行版提供的 shim/bootloader
解決 dbx 撤銷導致的阻擋。 - BIOS 內啟用「Microsoft 3rd-party UEFI CA」
讓 shim 能被 UEFI 接受。 - 最後才考慮 Custom Mode 改 PK/KEK/db
做錯可能導致整機無法開機；除非你在做企業級 key 基礎設施管理。
