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 啟動程序只會執行可信任的軟體和韌體。為支援各種作業系統的「安全啟動」，Microsoft 會管理 UEFI 憑證，並將其儲存在執行個體韌體內的金鑰交換金鑰 (KEK) 和允許的簽章資料庫 (db) 變數中。

備份和災難復原服務使用者注意事項

由於備份和災難復原服務是代管服務，因此會自動管理設備的基礎作業系統和安全啟動憑證更新。 Google Cloud 您不必採取任何行動：現有設備會繼續正常啟動及運作，而您部署的新設備會自動納入更新的「安全啟動」憑證。

安全啟動憑證和到期日

Microsoft 會管理 UEFI 安全啟動憑證，用於在 VM 啟動程序期間驗證啟動載入程式簽章。以下各節列出即將於 2011 年到期的憑證，以及取代這些憑證的 2023 年新憑證。

即將到期的憑證

下表說明舊版安全啟動憑證的最終到期日：

憑證名稱	角色	到期日
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 日

新憑證

下表說明新安全啟動憑證的最終到期日：

憑證名稱	角色	到期日
Microsoft UEFI CA 2023	簽署第三方啟動載入程式，例如 Linux Shim	2038 年 6 月 13 日
Windows UEFI CA 2023	簽署 Windows 啟動載入程式	2035 年 6 月 13 日
Microsoft Corporation KEK 2K CA 2023	用於更新 DB 和 DBX	2038 年 3 月 2 日
Microsoft Option ROM UEFI CA 2023	簽署 UEFI 驅動程式和選項 ROM	2038 年 10 月 26 日

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

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 或 db)，且系統啟動載入程式是使用您自己的自訂憑證簽署，而非即將到期的 Microsoft Corporation UEFI CA 2011。如果您使用自訂金鑰，但仍依賴即將到期的 Microsoft CA 簽署開機載入程式，請參閱「使用自訂 PK 或 KEK 設定的執行個體」一節，瞭解金鑰更新規定。
• Google Cloud 備份和災難復原設備。這些是受管理的裝置。憑證到期不會影響裝置運作，您也不必手動更新。 Google Cloud會自動管理所有憑證更新。

如果是在 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 日前建立的受保護 VM 執行個體上啟用安全啟動功能，建議您確認已安裝 2023 年憑證；否則，如果您套用僅由 Microsoft UEFI CA 2023 年憑證簽署 (且未與 2011 年憑證雙重簽署) 的開機載入程式更新，運算執行個體就會發生啟動問題。如果沒有採取任何行動，您可能無法套用日後僅以 2023 年憑證簽署的系統啟動載入程式或核心更新。請注意，在可預見的未來，OS 供應商會使用 2011 年和 2023 年的憑證，對開機載入程式和墊片更新進行雙重簽署，因此預計不會立即發生開機失敗或更新遭封鎖的情況。如果是 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。
• 具有自訂 PK 或 KEK 設定的執行個體：
  • 成為因素的情況：當執行個體在系統上使用自訂安全啟動變數 (例如自訂 PK 或 KEK)，但仍依賴資料庫中的標準 Microsoft 憑證 (db) 簽署開機載入程式時。
  • 影響：必須更新標準 db 憑證，才能啟動後續的啟動載入程式更新，這些更新僅由 Microsoft UEFI CA 2023 簽署。不過，由於您使用自訂金鑰，因此 Google 指南中提供的標準更新檔案 (DBUpdate3P2023.bin 或 kek2023update.bin) 無法套用。UEFI 韌體會檢查簽章，並要求更新必須由系統上 KEK (或 PK) 的私密金鑰簽署。
  • 補救措施：您必須先使用與自訂 PK 或 KEK 相關聯的私密金鑰簽署憑證更新檔案，再套用這些檔案，或是透過自訂憑證授權單位管理這些更新。
  • 不受影響的情況：如果開機載入程式是使用您自己的自訂憑證授權單位或金鑰簽署 (例如自訂 db 憑證，而非即將到期的 Microsoft Corporation UEFI CA 2011)，Microsoft 預設憑證到期就不會影響您，您也不需要執行任何更新。
• 復原至 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 和資料庫更新指南更新資料庫和 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 年憑證，表示您的執行個體已更新至最新版本，不需要採取進一步行動。

無論使用哪種工具套用更新 (例如 fwupd、efitools 或 sbsigntool)，憑證都會儲存在執行個體的 UEFI NVRAM 變數中。您可以直接從訪客作業系統驗證這些值。

Linux

您可以在 Linux 上使用 mokutil (建議使用，大多數發行版預設提供) 或 efi-readvar (來自 efitools 套件) 驗證簽章資料庫。

方法 1：使用 mokutil (建議)

在支援 UEFI 安全啟動的大部分 Linux 發行版本 (包括 Debian、Ubuntu、RHEL、CentOS、Rocky Linux、AlmaLinux、SLES、openSUSE 和 Fedora) 中，mokutil 預設會安裝。

檢查 KEK 和 db 變數中的 2023 年憑證：

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

如要查看完整憑證詳細資料 (例如簽發者、主體和到期日)，請執行 sudo mokutil --kek 或 sudo mokutil --db，不要進行篩選。

方法 2：使用 efi-readvar

如果您偏好使用 efi-readvar，請確認已安裝 efitools 套件：

• Debian 或 Ubuntu

  sudo apt update && sudo apt install efitools -y
  

• Fedora (標準 RHEL/CentOS 存放區中沒有 efitools)

  sudo yum install efitools -y
  

• SLES 或 openSUSE

  sudo zypper install efitools -y
  

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

sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
sudo efi-readvar -v 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
  

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

  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 憑證 (例如，如果您的開機載入程式是使用自己的自訂 db 憑證簽署，而非使用即將到期的 Microsoft Corporation UEFI CA 2011)，預設憑證到期就不會影響您。

  如果您的自訂設定仍依賴即將到期的 Microsoft 憑證簽署啟動載入程式，就會受到影響。不過，由於您使用自訂的 PK 或 KEK，因此本指南提供的標準更新檔案 (DBUpdate3P2023.bin 或 kek2023update.bin) 會失敗，因為 UEFI 必須使用系統上 KEK (或 PK) 的私密金鑰簽署更新。您必須使用自訂 PK 或 KEK 的私密金鑰簽署憑證更新檔案，才能套用這些檔案。

這項期限是否會影響 Managed Service for Apache Spark (舊稱 Dataproc)、Dataflow 或 Vertex AI Workbench 執行個體？

這項憑證到期不會影響 Dataflow，因為 Dataflow 執行個體預設會在 Container-Optimized OS (COS) 上執行。這些憑證更新不會影響 COS 環境。

如果是 Managed Service for Apache Spark (舊稱 Dataproc) 和 Vertex AI Workbench 執行個體，只有在執行個體符合下列兩項必要條件時，這項期限才會對您造成影響：

1. 您在 2025 年 11 月 7 日前建立執行個體。
2. 您已在執行個體上啟用安全啟動功能。這些服務預設不會啟用安全啟動。

如果執行個體符合這兩項必要條件，憑證到期就會影響執行個體。不過，作業系統供應商計畫在可預見的未來，為系統啟動載入程式和 shim 更新進行雙重簽署，因此不會立即造成影響。除非您安裝日後僅以 2023 年憑證簽署的更新，否則執行個體不會受到影響。

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

如果您不採取任何行動，執行個體會繼續啟動，並使用現有二進位檔正常運作。不過，如果日後的開機載入程式或核心更新只包含以 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 選項。
• 進一步瞭解安全啟動。