Microsoft 安全啟動憑證到期指南

由於多個 Microsoft 安全啟動憑證將於 2026 年到期，本文將說明如何更新 Compute Engine Shielded VM 執行個體，以信任 UEFI (統一可延伸韌體介面) 安全啟動的更新版 Microsoft 安全啟動憑證。即將到期的兩個最重要憑證是 Microsoft Corporation UEFI CA 2011 (2026 年 6 月 27 日到期)，這個憑證會簽署第三方開機載入器 (例如 Linux Shim)，以及 Microsoft Windows Production PCA 2011 (2026 年 10 月 19 日到期)，這個憑證會簽署 Windows 開機載入器。

UEFI 安全啟動是受防護的 VM 採用的安全標準，可確保 VM 啟動程序只會執行受信任的軟體和韌體。為支援各種作業系統的 Secure Boot，Microsoft 會管理 UEFI 憑證，並將這些憑證儲存在執行個體韌體內的金鑰交換金鑰 (KEK) 和允許的簽章資料庫 (db) 變數中。

安全啟動憑證和到期日

憑證名稱	角色	到期日
Microsoft Corporation UEFI CA 2011	簽署第三方啟動載入程式，例如 Linux Shim	2026 年 6 月 27 日
Microsoft Windows Production PCA 2011	簽署 Windows 啟動載入程式	2026 年 10 月 19 日
Microsoft Corporation KEK CA 2011	用於更新 DB 和 DBX	2026 年 6 月 24 日

如果您的運算執行個體符合下列兩項必要條件，這項憑證到期問題就會對您造成影響：

1. 建立日期：您在 2025 年 11 月 7 日前建立運算執行個體 (Compute Engine 在 UEFI 韌體中更新預設安全啟動憑證的日期)，且尚未更新。
2. 安全啟動狀態：您已在執行個體上啟用安全啟動功能。 Google Cloud 建立 Shielded VM 執行個體時，系統預設不會啟用安全啟動功能。

如果您使用依預設憑證集而定的映像檔，則在 2025 年 11 月 7 日當天或之後建立的執行個體，其韌體變數中已包含更新後的憑證。

如果執行個體不符合這兩項必要條件，憑證到期就不會影響執行個體，您也不需要採取任何行動。

本文說明如何找出受影響的執行個體，並執行必要更新。

Google Cloud 於 2025 年 11 月 7 日完成推出新憑證。如果您在上述日期當天或之後，從依預設憑證集建立的映像檔建立執行個體，這些執行個體的 NVRAM/韌體變數 (db 和 KEK) 就會包含更新後的憑證，因此不需要採取進一步行動。不過，您在上述日期前幾週建立的部分執行個體，可能也會包含新憑證。如要確認系統是否為最新版本，請使用本文「驗證」一節中的指令。

注意：安全啟動憑證到期不會影響下列項目：

• 未啟用安全啟動功能的執行個體。請注意，如果您使用 vTPM 平台設定暫存器 (具體來說是 PCR7) 密封密碼，即使停用安全啟動，更新 UEFI 變數或重新建立執行個體仍會變更 PCR7 測量值，但這種設定非常少見。
• 執行 Container-Optimized OS (COS) 的執行個體。
• 您自行提供安全啟動平台金鑰 (PK) 或金鑰註冊金鑰 (KEK) 的執行個體。

如果是在 2025 年 11 月 7 日前建立的運算執行個體，且沒有更新憑證，請按照 KEK 和資料庫更新指南更新憑證。如果因故無法更新，請考慮重新建立執行個體。

安全啟動憑證到期對 Shielded VM 有何影響

啟用後，Shielded VM 會使用 UEFI 韌體強制執行安全啟動，該韌體會維護一組信任的憑證 (位於 db 變數中)，用來驗證啟動序列二進位檔的簽章。舉例來說，如果作業系統更新將開機載入程式替換為僅由 Microsoft UEFI CA 2023 簽署的程式，而運算執行個體的韌體不信任這個憑證授權單位，安全啟動驗證就會失敗，安全啟動功能也會停止啟動程序。

如要進一步瞭解這項轉換作業，請參閱 Microsoft 和其他 OS 供應商的指南：

• Windows 安全啟動憑證到期和 CA 更新 - Microsoft 支援服務
• 2026 年安全啟動憑證異動：RHEL 環境指南 - Red Hat 客戶入口網站

作業系統影響

如果您在 2025 年 11 月 7 日前建立的 Shielded VM 執行個體上啟用安全啟動功能，建議您確認已安裝 2023 年的憑證，否則如果套用只含 Microsoft UEFI CA 2023 憑證 (未與 2011 年憑證雙重簽署) 的系統啟動載入程式更新，運算執行個體就會發生開機問題。如果未採取任何行動，您可能無法套用日後僅以 2023 年憑證簽署的系統啟動載入程式或核心更新。請注意，由於 OS 供應商預計在可預見的未來，會使用 2011 年和 2023 年的憑證，對系統啟動載入程式和 shim 更新進行雙重簽署，因此預計不會立即發生啟動失敗或更新遭封鎖的情況。2025 年 11 月 7 日前建立的運算執行個體：如果 Windows 客戶尚未套用憑證更新，系統事件記錄中可能會顯示事件 ID 1801 (「Secure Boot CA/keys need to be updated」)。

• Google 提供的公開映像檔：按照 KEK 和資料庫更新指南更新 DB 和 KEK 憑證。或者，您也可以考慮重新建立 2025 年 11 月 7 日前建立的任何長期執行的 VM。

• 自訂或匯入的映像檔：絕大多數自訂或匯入的映像檔都依賴預設的安全啟動憑證。如果您在建立映像檔時，未明確覆寫 db 或 KEK 安全啟動變數，映像檔會使用預設金鑰集，且不需要在映像檔層級採取任何動作。如果您從任何依賴這些預設值的映像檔建立執行個體，Compute Engine 會自動提供更新後的憑證。

  如果您在映像檔建構程序中，於映像檔中繼資料明確定義自訂 db 或 KEK 安全啟動變數 (例如，在預設 Microsoft 憑證旁加入第三方安全廠商的憑證)，才需要採取行動。由於指定自訂 db 或 KEK 變數會完全覆寫預設值 (且系統會忽略預設公開金鑰)，您的自訂變數可能缺少更新的「Microsoft UEFI CA 2023」或 2023 KEK 憑證。如果自訂映像檔設定排除這些更新的憑證，您必須重新建立或更新 Shielded 映像檔，才能納入這些憑證。如需操作說明，請參閱「建立自訂的 Shielded VM 映像檔」。

建議做法

如果您在 2025 年 11 月 7 日前建立的運算執行個體已啟用安全啟動功能，請先詳閱下列需求、限制和複雜因素，再規劃更新路徑：

• 更新前須符合下列條件：
  • 確認備援金鑰存取權：如果執行個體使用 FDE (包括 Windows 上的 BitLocker 或 Linux 上的 LUKS)，您必須確保在更新憑證或重建執行個體前，可以存取備援金鑰。修改 UEFI 變數會改變啟動測量結果，並觸發復原提示。
  • 管理 vTPM 密鑰：如果執行個體使用 vTPM 平台設定暫存器 (具體來說是 PCR7) 密封密鑰，您必須先解除密封或備份這些密鑰，再進行更新，以免永久無法存取。
• 複雜因素和界線：
  • 更新順序規定：為避免 CA 驗證失敗和系統啟動迴圈，您必須先安裝新的 db 和 KEK 憑證，才能套用新的核心或墊片更新。
  • 韌體回溯：將執行個體還原為 2025 年 11 月 7 日前擷取的舊版機器映像檔，會還原舊版韌體並移除 2023 年憑證的信任關係。如果復原，您必須重新套用憑證更新。

如需時間表、稽核步驟和遷移程序詳細資訊，請參閱下列操作說明。

對特定訪客設定的影響

只有在執行個體符合兩項必要條件 (建立時間早於 2025 年 11 月 7 日，且已啟用安全啟動) 時，才需要瞭解憑證到期對各項設定的影響：

• vTPM PCR 密封密碼：
  • 成為因素的情況：使用 vTPM 平台設定暫存器 (具體來說是 PCR7) 密封密碼，例如解密金鑰。
  • 影響：更新安全啟動憑證 (使用 KEK 和 db 更新指南或從磁碟快照重新建立執行個體) 會修改 UEFI 變數，進而變更下次啟動時的 PCR7 測量值。這項變更會防止客體 OS 或應用程式解除密封或解密這些密碼，除非您先解除密封或備份更新前的密碼，然後再將密碼重新密封至新的 PCR7 值。
  • 不受影響的情況：如果您在 2025 年 11 月 7 日當天或之後，從依預設憑證的映像檔建立 VM，則不需要更新憑證，PCR7 會維持不變，密碼密封作業也會正常運作。
• 使用 BitLocker 或虛擬安全模式 (VSM) 的 Windows Compute 執行個體：
  • 成為影響因素：當 Windows VM 使用 BitLocker 全磁碟加密或 VSM 時，這兩者都會信任 UEFI 安全啟動和 PCR7 來封存加密金鑰。
  • 影響：修改 UEFI 安全啟動憑證或從快照重建執行個體，都會變更 PCR7 開機測量結果。在後續重新啟動時，BitLocker 會偵測到設定變更，無法自動釋放金鑰，並啟動至 BitLocker 復原畫面，要求提供備援金鑰。
  • 修復：更新憑證或遷移執行個體前，請務必確認您有可用的 BitLocker 復原金鑰。接著，請按照「在 Windows 上更新資料庫和 KEK」一文的說明操作。
  • 不受影響的情況：如果 Windows 執行個體未啟用 BitLocker 或 VSM，或未啟用安全啟動功能，憑證到期就不會造成影響。
• 使用 FDE 的 Linux VM：
  • 成為影響因素的情況：當 Linux 執行個體使用 FDE (例如 LUKS) 時，您會將解密金鑰密封至 vTPM PCR (具體來說是 PCR7)。
  • 影響：更新安全啟動憑證或重新建立 VM 會變更 PCR7，導致開機磁碟區無法自動解密。系統會在啟動期間停止運作，並提示您輸入解密通關密語。
  • 補救措施：請先確認您有復原密碼或金鑰，再執行更新。更新前，請先從 TPM 解除繫結或密封 LUKS 金鑰，更新完成後，再重新繫結或密封至新的 PCR7 值。
  • 不受影響的情況：如果 Linux VM 未使用 FDE 或 vTPM 密封的 LUKS 解密，或是未啟用安全啟動，憑證到期就不會影響這些 VM。
• 復原至 2025 年 11 月前機器映像檔的執行個體：
  • 成為因素的時間：將 VM 還原或復原至 2025 年 11 月 7 日前擷取的機器映像檔，且已啟用安全啟動功能。
  • 影響：復原的執行個體會還原舊版 UEFI 韌體設定和憑證存放區，其中缺少 2023 年的憑證。這會導致執行個體在後續更新開機載入程式後，容易發生開機失敗問題，因此您必須重新套用憑證更新。
  • 不受影響的情況：如果您停用安全啟動，或是從依預設憑證的映像檔建立機器映像檔 (時間為 2025 年 11 月 7 日當天或之後)，則還原至機器映像檔不會影響執行個體。

找出受影響的運算執行個體並規劃更新

在 2026 年，建議您找出受影響的運算執行個體，並採取下列步驟為更新做準備：

1. 找出執行個體：您可以使用 gcloud compute instances list 指令，找出已啟用安全啟動功能，且是在截止日期前建立的執行個體：

   gcloud compute instances list \
   --filter="creationTimestamp < '2025-11-07' AND shieldedInstanceConfig.enableSecureBoot=true" \
   --format="table(name, zone, creationTimestamp, shieldedInstanceConfig.enableSecureBoot:label=SECURE_BOOT)"
   

2. 檢查自訂變數 (選用)：如果您使用自訂或匯入的映像檔，請確認這些映像檔是否明確定義自訂 db 或 KEK 安全啟動變數 (這會完全覆寫預設值)。如果使用預設憑證，則無須在映像檔層級採取任何行動：

   • 如要檢查 VM 執行個體，請執行：

     gcloud compute instances describe INSTANCE_NAME \
         --zone=ZONE \
         --format="yaml(shieldedInstanceInitialState)"
     

   • 如要檢查來源磁碟映像檔，請執行：

     gcloud compute images describe IMAGE_NAME \
         --format="yaml(shieldedInstanceInitialState)"
     

   如果輸出內容為空白或傳回 null，表示執行個體或映像檔使用預設憑證，因此無須在映像檔層級採取任何動作。

3. 確保資料完整性：進行任何變更前，請確認您有最近的資料備份，並可存取 FDE 或 BitLocker 復原金鑰。

4. 更新憑證：按照 KEK 和資料庫更新指南更新 DB 和 KEK 憑證。或者，您也可以按照「從磁碟快照重建運算執行個體」一文中的操作說明，遷移至 2025 年 11 月 7 日當天或之後建立的運算執行個體，其中包含 2023 年憑證 (前提是新執行個體使用的映像檔依賴預設憑證)。

透過磁碟快照重建運算執行個體

當您拍攝磁碟快照並從中建立新執行個體時，新的運算執行個體會沿用信任更新預設值的新韌體 (vTPM/NVRAM) 狀態，並清除舊憑證。

從快照還原運算執行個體前，請確保訪客 OS 已安裝所有必要更新 (例如 Windows 適用的 Microsoft KB，或 Linux 發行版本的最新 Shim)，以信任 2023 年憑證。

您可以使用下列 gcloud 指令序列管理這項遷移作業：

1. 找出開機磁碟：判斷附加至來源運算執行個體的開機磁碟名稱：

   SOURCE_DISK=$(gcloud compute instances describe SOURCE_INSTANCE_NAME \
       --zone=ZONE \
       --format="value(disks[0].source.basename())")
   

2. 建立磁碟快照：建立該開機磁碟的快照。為確保資料完整性，請先停止運算執行個體，再執行這項指令：

   gcloud compute disks snapshot $SOURCE_DISK \
       --snapshot-names="migration-snapshot-$(date +%s)" \
       --zone=ZONE \
       --storage-location=REGION
   

3. 建立新的運算執行個體：使用快照做為開機來源，佈建新的運算執行個體。如果來源執行個體已啟用安全啟動功能，請加入 --shielded-secure-boot 標記，在新執行個體上啟用安全啟動功能。

   gcloud compute instances create NEW_INSTANCE_NAME \
       --zone=ZONE \
       --machine-type=MACHINE_TYPE \
       --create-disk=name=NEW_DISK_NAME,source-snapshot=SNAPSHOT_NAME,boot=yes \
       --shielded-secure-boot
   

注意：使用這種方法佈建的執行個體會收到新的內部和外部 IP 位址，除非靜態分配並特別重新指派。系統不會自動複製執行個體層級的中繼資料、標記和服務帳戶，因此您必須在重新建立時明確設定。

驗證

更新運算執行個體的韌體和 OS 後，您可以確認是否已安裝 2023 年憑證。如果 KEK 和 db 變數都顯示 2023 年的憑證，表示您的執行個體已更新至最新版本，無須採取進一步行動。

Linux

在 Linux 上，您可以透過 efitools 套件的 efi-readvar 指令，或使用 mokutil (適用於 RHEL 8/9 等沒有 efitools 的發行版本)，驗證簽章資料庫。

方法 1：使用 efi-readvar

1. 如果沒有 efi-readvar，請安裝 efitools 套件。如要在 Linux 上安裝，請執行適合您發行版本的指令：

   Debian/Ubuntu

   sudo apt update && sudo apt install efitools
   

   RHEL/CentOS/Fedora (僅限 Fedora；RHEL/CentOS 存放區不提供 efitools)

   sudo yum install efitools
   

   SLES

   sudo zypper install efitools
   

2. 檢查 KEK 和 db 變數中的憑證：

   sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
   sudo efi-readvar -v db | grep "UEFI CA 2023"
   

方法 2：使用 mokutil

在 Red Hat Enterprise Linux (RHEL) 等發行版上，如果無法使用 efitools，請使用預設安裝的 mokutil 公用程式：

sudo mokutil --kek | grep "KEK 2K CA 2023"
sudo mokutil --db | grep "UEFI CA 2023"

Windows (PowerShell)

在系統管理員 PowerShell 提示字元中執行下列指令。每個指令都應傳回 True。

# Check for Microsoft KEK 2K CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

# Check for UEFI CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'UEFI CA 2023'

# Confirm general Secure Boot enrollment state
Confirm-SecureBootUEFI

疑難排解

如果執行個體在 2026 年 6 月後因安全啟動錯誤而無法啟動，請嘗試下列任一選項來復原：

• 暫時停用安全啟動功能：這樣您就能啟動執行個體來套用更新。

  注意：停用安全啟動會變更 PCR 值 (特別是 PCR7)，這可能會影響密碼封裝或磁碟加密功能。

  如要停用安全啟動，請執行下列指令：

  gcloud compute instances update INSTANCE_NAME --no-shielded-secure-boot
  

  對開機載入程式/shim 套用必要更新後，請重新啟用安全啟動：

  gcloud compute instances update INSTANCE_NAME --shielded-secure-boot
  

• 從備份還原：從開機問題發生前建立的機器映像檔還原執行個體。

• 重新建立執行個體：重新建立執行個體，並從快照還原資料。

如果仍遇到問題或需要協助，請與 Cloud Customer Care 團隊聯絡。

常見問題 (FAQ)

本節會解答有關 Microsoft 安全啟動憑證到期的常見問題。

安全啟動憑證何時到期？

Microsoft 的安全啟動憑證將於 2026 年到期。具體情況如下：

• 即將停用的兩個最重要憑證是 Microsoft Corporation UEFI CA 2011 (2026 年 6 月到期)，這個憑證會簽署第三方開機載入程式 (例如 Linux Shim)，以及 Microsoft Windows Production PCA 2011 (2026 年 10 月到期)，這個憑證會簽署 Windows 開機載入程式。

憑證過期會影響哪些使用者？

如果您的運算執行個體符合下列兩項必要條件，這項憑證到期日才會對您造成影響：

1. 您在 2025 年 11 月 7 日前建立執行個體，當時 Compute Engine 更新了 UEFI 韌體中的預設安全啟動憑證，但您尚未更新。
2. 您已在執行個體上啟用安全啟動功能。

只要您是從依預設憑證集建立的映像檔建立執行個體，2025 年 11 月 7 日當天或之後建立的執行個體就不會受到影響。

如果執行個體符合這兩項必要條件，在特定情況下，憑證到期會影響下列設定：

• vTPM PCR 密鑰封裝：如果執行個體使用虛擬信任平台模組 (vTPM) 平台設定暫存器 (具體來說是 PCR7) 封裝加密金鑰或密鑰。
• Windows BitLocker / VSM：如果 Windows 執行個體使用 BitLocker 磁碟加密或虛擬安全模式 (VSM) 與安全啟動。
• Linux FDE：如果 Linux 執行個體使用 FDE，且您將其密封至 vTPM PCR (具體來說是 PCR7)。
• 復原執行個體：如果將 VM 還原或復原至 2025 年 11 月 7 日前建立的機器映像檔。

如要詳細瞭解每項設定的影響和補救步驟，請參閱「對特定訪客設定的影響」。

哪些人不受憑證到期影響？

如果符合下列任一條件，憑證到期就不會影響您：

• 安全啟動已停用：如果 Shielded VM 執行個體未啟用安全啟動功能，就不會驗證或使用即將過期的 UEFI 憑證。安全啟動功能預設為停用。不過請注意，如果您使用 vTPM 平台設定暫存器 (具體來說是 PCR7) 密封密碼，即使停用安全啟動，更新 UEFI 變數或重建執行個體仍會改變 PCR7 測量值，但這種情況非常罕見。
• 2025 年 11 月 7 日當天或之後建立：您是在這個日期當天或之後建立執行個體，因此只要是從依預設憑證集建立的映像檔建立執行個體，韌體就會包含 2023 年更新的憑證。
• 執行 Container-Optimized OS (COS)：這些憑證更新不會影響 COS 環境。
• 自訂 PK、KEK 或 db 變數：如果您明確定義及管理自己的自訂安全啟動 PK、KEK 或 db 變數，而不使用預設的 Microsoft UEFI 憑證，預設憑證到期就不會影響您。不過，您必須負責更新及維護自己的憑證。

如果我不採取任何行動，會發生什麼狀況？

如果不採取任何行動，執行個體會繼續啟動，並使用現有二進位檔正常運作。不過，如果日後的系統啟動載入程式或核心更新只包含以 2023 年憑證簽署的二進位檔，您可能就無法套用。請注意，由於 OS 供應商會使用 2011 年和 2023 年的憑證，對開機載入程式和墊片更新進行雙重簽署，因此預期不會立即發生開機失敗或更新遭封鎖的情況。

如果未更新憑證，Windows 執行個體是否就無法啟動？

不會。如果未修正問題，Windows 系統仍可啟動。不過，您可能會在系統事件記錄中看到事件 ID 1801 (「Secure Boot CA/keys need to be updated」)，而且無法套用僅以 2023 年新憑證簽署的二進位檔，因此無法取得新的核心或開機載入程式安全性更新。

哪些特定情況會導致 Linux 無法啟動？

在特定情況下，Linux 可能會無法開機：

• 執行個體已啟用安全啟動功能。
• db UEFI 變數未更新，因此無法信任「Microsoft UEFI CA 2023」憑證。
• 作業系統更新的開機載入程式 (或墊片) 嚴格依賴該憑證 (且未以 2011 年憑證雙重簽署)。

如果您未套用參照新憑證的憑證更新或墊片更新，Linux 執行個體仍會繼續順利啟動。

如何判斷執行個體是否已更新憑證？

如要判斷執行個體的韌體是否包含新憑證，請參閱「驗證」一節中列出的指令。如果缺少憑證，請按照 KEK 和資料庫更新指南更新憑證，或重新建立執行個體。

重新啟動或重新開機受影響的執行個體是否能解決問題？

不會。重新啟動或重新開機運算執行個體不會更新其安全啟動憑證，但執行個體會繼續使用現有憑證正常啟動及運作，直到套用開機載入程式或核心更新，其中包含只以 2023 年憑證簽署的二進位檔為止。如果運算執行個體是在 2025 年 11 月 7 日前建立，重新啟動後會保留舊憑證。憑證是執行個體韌體 (vTPM/NVRAM) 的一部分。因此，您需要按照 KEK 和資料庫更新指南操作，或重新建立執行個體，才能套用新憑證。

如何為憑證到期做準備？

如要準備，請按照下列步驟操作：

• 找出：稽核您對受防護 VM、安全啟動、FDE、BitLocker 或任何依賴 vTPM PCR 的軟體的使用情況。
• 復原金鑰和備份：確保復原金鑰 (適用於 FDE/BitLocker) 和最新資料備份可立即使用。
• 管理映像檔：找出舊版自訂映像檔並停止使用，或確保這些映像檔包含新憑證。
• 更新或遷移：如要更新憑證，請參閱 KEK 和資料庫更新指南。或者，您也可以考慮重新建立 2025 年 11 月 7 日前建立的任何長期運作運算執行個體，因為新執行個體已包含必要憑證 (前提是您是從依預設憑證的映像檔建立新執行個體)。

重新建立或遷移受影響執行個體的建議方法為何？

標準磁碟快照是最可靠的方法。快照是磁碟的區塊層級副本，不含 UEFI 變數或執行個體層級中繼資料。如要使用快照還原，請按照下列步驟操作：

1. 建立執行個體開機磁碟的快照。
2. 建立新的運算執行個體，並選取快照做為開機磁碟的來源。

請勿使用機器映像檔、執行個體複製功能或備份和災難復原服務進行這項遷移作業，因為這些工具會複製執行個體韌體，並保留 2025 年 11 月 7 日前建立的所有來源運算執行個體舊憑證。

如果系統在 2026 年 6 月後停止啟動，該怎麼辦？

如果認為這個問題導致開機失敗，請參閱「疑難排解」。

如何 Google Cloud 處理 Microsoft 安全啟動憑證到期問題？

Google Cloud 在 2025 年 11 月 7 日之後建立的運算執行個體，會自動納入新憑證。只有想保留 2025 年 11 月 7 日前執行的運算執行個體的客戶，才可能需要套用日後的更新，但我們建議您遷移至 2025 年 11 月 7 日當天或之後建立的執行個體 (依預設憑證而定)。

後續步驟

• 進一步瞭解Shielded VM。
• 瞭解如何修改 Shielded VM 選項。
• 進一步瞭解安全啟動。