安全啟動憑證更新：給 IT 專業人士與組織的指引

安全啟動憑證到期

憑證授權中心 (CAs) （也稱為憑證）的配置，由Microsoft作為安全啟動基礎設施的一部分，自Windows 8年及Windows Server 2012年起一直保持不變。 這些憑證儲存在 Signature Database (DB) 和 Key Exchange Key (KEK) 變數中。 Microsoft 在原始設備製造商 (OEM) 生態系統中提供了相同的三張憑證，納入裝置韌體中。 這些憑證支援 Windows 的安全開機，也被第三方作業系統 (作業系統) 使用。 以下憑證由 Microsoft 提供：

• Microsoft Corporation KEK CA 2011

• Microsoft Windows 生產版 PCA 2011

• Microsoft Corporation UEFI CA 2011

有什麼改變？

目前Microsoft安全開機憑證 (Microsoft公司 KEK CA 2011、Microsoft Windows Production PCA 2011、Microsoft Corporation UEFI CA 2011) 將於 2026 年 6 月開始到期，並將於 2026 年 10 月到期。 

2023 年新憑證正陸續推出，以維護安全啟動的安全性與連續性。 裝置必須在 2011 年憑證到期前更新至 2023 年憑證，否則將不符合安全規範並面臨風險。  

自 2012 年起生產的 Windows 裝置可能擁有過期的憑證版本，必須更新。 

術語

憑證

驗證您的車隊安全開機狀態：安全開機是否啟用？ 

自 2012 年起製造的大多數裝置都支援安全開機，且出廠時已啟用安全開機。 要確認裝置是否啟用安全開機，請執行以下其中一項： 

• 圖形介面方法： 前往開始 > 設定 > 隱私 & 安全 > Windows 安全性> 裝置安全。 在裝置安全中，安全開機區塊應該會顯示安全開機已開啟。

• 命令列方法： 在 PowerShell 的升降命令提示字元，輸入 Confirm-SecureBootUEFI，然後按下 Enter。 指令應該會回傳 True，表示安全開機已開啟。

在大規模部署一組設備時，IT 專業人員使用的管理軟體需要檢查安全啟動啟用。 

例如，檢查 Microsoft Intune 管理裝置安全開機狀態的方法是建立並部署 Intune 自訂合規腳本。 Intune 合規設定詳見 Use custom comply settings for Linux and Windows with Microsoft Intune 一覽。  

如果沒有啟用安全開機，你可以跳過以下更新步驟，因為它們不適用。

更新的部署方式

有多種方式可以針對裝置進行安全開機憑證更新。 部署細節，包括設定與事件，將於本文後面討論。 當你鎖定裝置進行更新時，會設定該裝置開始套用新憑證的流程。 裝置每 12 小時會執行一個排程任務，並偵測該裝置已被鎖定為更新目標。 任務的概要如下：

1. Windows UEFI CA 2023 被套用到資料庫。

2. 若裝置資料庫中有 Microsoft Corporation UEFI CA 2011，則任務會套用 Microsoft Option ROM UEFI CA 2023 及 Microsoft UEFI CA 2023 於資料庫。

3. 接著，這項任務還會加入 Microsoft Corporation KEK 2K CA 2023。

4. 最後，排程任務會將 Windows 開機管理員更新為由 Windows UEFI CA 2023 簽署的版本。 Windows 會偵測到需要重新啟動，才能套用開機管理器。 開機管理器的更新會被延遲，直到重新啟動自然發生，例如) 月度更新 (，然後 Windows 才會再次嘗試套用開機管理器更新。

上述每一個步驟都必須成功完成，排程任務才會進入下一步驟。 在此過程中，將提供事件日誌及其他狀態，以協助監控部署。 以下提供更多關於監測與事件記錄的細節。  

更新安全開機憑證可讓未來更新 2023 開機管理器更安全。 Boot Manager 的具體更新將在未來版本中推出。

部署步驟 

• 準備：盤點與測試裝置。

• 韌體考量

• 監控：確認監控功能並為您的車隊建立基準。

• 部署：針對裝置進行更新，從小部分子集開始，並根據成功測試逐步擴展。

• 修復：利用日誌和廠商支援調查並解決任何問題。

準備 

庫存硬體和韌體。 根據系統製造商、系統型號、BIOS 版本/日期、基板產品版本等，建立具代表性的裝置範例，並在廣泛部署前測試這些裝置的更新。  這些參數常見於系統資訊 (MSINFO32) 中。 使用附帶的範例 PowerShell 指令來檢查安全開機更新狀態，並盤點組織內的裝置。

注意：若啟用安全開機狀態，這些指令會生效。 

注意：這些指令中許多需要管理員權限才能運作。

安全啟動庫存資料收集腳本範例

複製貼上此範例腳本，並依照您的環境進行修改：Sample Secure Boot Inventory Data Collection 腳本。

啟用安全啟動後，第一步是檢查是否有近期已更新或正在更新安全啟動憑證的待處理事件。 特別值得關注的是1801年和1808年發生的最近事件。 

這些事件在安全開機資料庫與 DBX 變數更新事件中有詳細描述。 請也查看監控與部署區塊，了解事件如何顯示待更新狀態。  

待處理事件 1801 和 1808 的最新狀態可透過以下範例 PowerShell 指令捕捉： 

下一步是盤點整個組織的裝置。 請用 PowerShell 指令收集以下細節，建立具代表性的範例： 

韌體考量

部署新的安全開機憑證到您的裝置群時，必須讓裝置韌體在完成更新時扮演角色。 雖然 Microsoft 預期大多數裝置韌體都能正常運作，但在部署新憑證前仍需謹慎測試。

檢視你的硬體庫存，並根據以下獨特標準建立一個小型且具代表性的裝置樣本，例如： 

• 製造商

• 型號

• 韌體版本

• 原廠底板版本等等。

在廣泛部署至車隊中的裝置前，我們建議您先測試代表性範例裝置的憑證更新， (依製造商、型號、韌體版本) 等因素定義，以確保更新能順利處理。 建議針對每個獨特類別測試的樣本裝置數量為4個或以上。

這將有助於建立部署過程的信心，並避免對整體機隊造成意外影響。 

在某些情況下，可能需要韌體更新才能成功更新安全開機憑證。 在這種情況下，我們建議你向你的裝置原廠確認是否有更新的韌體可用。

虛擬化環境中的視窗

對於在虛擬環境中運行的 Windows，有兩種方法可以將新憑證加入安全開機韌體變數：  

• 虛擬環境的創建者 (AWS、Azure、Hyper-V、VMware 等 ) 可以提供環境更新，並將新憑證納入虛擬化韌體中。 這適用於新的虛擬化裝置。

• 對於長期在虛擬機中運行的 Windows，更新可以透過 Windows 套用，就像其他裝置一樣，前提是虛擬化韌體支援安全開機更新。

監控與部署 

我們建議您在部署前就開始設備監控，以確保監控運作正常，並事先掌握車隊狀況。 以下將討論監測選項。 

Microsoft 提供多種部署與監控安全開機憑證更新的方法。

自動部署輔助 

Microsoft 提供兩項部署協助。 這些協助有助於將新證書部署到您的車隊。 這兩種輔助都需要診斷資料。

• 可選擇累積更新，並設定信心桶： Microsoft 可能會自動在每月更新中包含高信心裝置群組，基於迄今分享的診斷資料，以惠及無法共享診斷資料的系統與組織。 此步驟不需要啟用診斷資料。

  • 對於能共享診斷資料的組織與系統而言，這讓 Microsoft 能有可視性與信心，確保裝置能成功部署憑證。 關於啟用診斷資料的更多資訊，請參閱： 在您的組織中配置 Windows 診斷資料。 我們為每個獨特裝置建立「桶」， (依據屬性定義，包括製造商、主機板版本、韌體製造商、韌體版本及額外資料點) 。 針對每個桶，我們會監控多個裝置的成功證據。 一旦我們看到足夠多的成功更新且無失敗，我們會將該分類視為「高信心」，並將該數據納入每月累積更新中。 當高信心分類的裝置被套用每月更新時，Windows 會自動將憑證套用到韌體中的 UEFI 安全開機變數。

  • 高信心桶包含正在正確處理更新的裝置。 當然，並非所有裝置都能提供診斷資料，這可能會限制 Microsoft 對裝置正確處理更新能力的信心。

  • 此輔助預設為高信心裝置啟用，並可依裝置設定關閉。 更多資訊將於未來的 Windows 版本中分享。

• 受控功能推出 (CFR) ：  若啟用診斷資料，請選擇裝置加入 Microsoft 管理部署。

  • 受控功能推出 (CFR) 可用於組織車隊中的用戶端裝置。 這需要裝置將所需的診斷資料傳送給 Microsoft，並已表示該裝置選擇允許裝置使用 CFR。 關於如何選擇加入的詳細資訊如下。

  • Microsoft 將管理這些新憑證在 Windows 裝置上的更新流程，這些憑證在有診斷資料且設備參與 CFR) 受控功能推廣 (的裝置上。 雖然 CFR 可能協助部署新憑證，但組織無法依賴 CFR 來修復其車隊問題——這需要依照本文件中「部署方法」部分所列步驟，這些方法 未被自動化協助涵蓋。

  • 限制： CFR 可能在你的環境中無法運作，有幾個原因。 例如：

    • 目前沒有診斷資料可用，或該診斷資料無法作為 CFR 部署的一部分使用。

    • 裝置未使用支援的客戶端版本Windows 11，且Windows 10 ESU) (擴充安全更新。

自動協助未涵蓋的部署方法

選擇適合你環境的方法。 避免在同一裝置上混合方法： 

• 登錄檔金鑰：控制部署並監控結果。
  有多個登錄鍵可用來控制憑證部署的行為並監控結果。 此外，選擇加入或退出上述部署輔助工具有兩個關鍵。 欲了解更多登錄檔金鑰的資訊，請參閱《安全開機登錄金鑰匯報——帶有 IT 管理更新的 Windows 裝置。

• 群組原則 (GPO) 物件：管理設定;透過登錄檔與事件日誌監控。
  Microsoft 將在未來更新中提供支援，協助管理安全開機更新，使用群組原則。 請注意，由於群組原則是用於設定，監控裝置狀態需要使用其他方法，包括監控登錄檔金鑰和事件日誌條目。

• WinCS (Windows 組態系統) CLI：使用命令列工具處理已加入網域的用戶端。
  網域管理員也可以利用 Windows 作業系統更新中包含的 Windows 組態系統 (WinCS) ，在已加入網域的 Windows 用戶端與伺服器間部署安全開機更新。 它由一系列命令列工具組成， (傳統執行檔與 PowerShell 模組，) 用來查詢並套用安全開機設定到機器本地。 欲了解更多資訊，請參閱 Windows 組態系統 (WinCS) 安全開機 API。

• Microsoft Intune/Configuration Manager： 部署 PowerShell 腳本。 未來更新中將提供組態服務提供者 (CSP) ，以允許使用 Intune 部署。

監控事件日誌

目前提供兩個新事件以協助部署安全啟動憑證更新。 這些事件在安全啟動資料庫（Secure Boot DB）與 DBX 變數更新事件中有詳細描述： 

• 事件編號：1801
  此事件為錯誤事件，表示更新後的憑證尚未套用於裝置。 此事件提供裝置特定細節，包括裝置屬性，有助於判斷哪些裝置仍需更新。

• 事件編號：1808
  此事件為資訊事件，表示裝置韌體已套用所需的新安全開機憑證。

部署策略 

為了降低風險，建議分階段部署安全啟動更新，而非一次全部部署。 從一小部分裝置開始，驗證結果，然後擴展到更多群組。 我們建議你先從裝置子集開始，隨著對這些部署有信心，再增加更多裝置子集。 可考慮多種因素來決定子集包含哪些內容，包括樣本裝置的測試結果及組織結構等。 

選擇部署哪些裝置由你決定。 以下列出一些可能的策略。 

• 大型設備群： 首先依靠上述輔助工具，針對你管理的常用設備。 同時，專注於貴組織管理的較少見裝置。 測試小型樣本裝置，若測試成功，則部署至同類型其他裝置。 若測試產生問題，請調查問題原因並決定補救步驟。 你也可以考慮在車隊中價值較高的裝置類別，並開始測試與部署，確保這些裝置及早具備更新的防護措施。

• 小型車隊，種類繁多： 如果你管理的車隊中有大量機器，單機測試會變得困難，建議大量依賴上述兩種輔助工具，尤其是對於市場上可能很常見的設備。 一開始專注於對日常運作至關重要的裝置，測試並部署。 繼續往高優先度裝置清單向下推進，測試與部署，同時監控車隊，確認輔助是否能協助其他設備。

注意事項 

• 注意舊款裝置，尤其是製造商已不再支援的裝置。 雖然韌體應該能正確執行更新操作，但有些韌體可能不會。 若韌體無法正常運作，且裝置不再支援，請考慮更換裝置以確保整個車隊的安全開機保護。

• 過去 1-2 年內製造的新裝置可能已經有更新的憑證，但系統可能沒有套用 Windows UEFI CA 2023 簽署的開機管理器。 套用此開機管理器是每個裝置部署中關鍵的最後一步。

• 一旦裝置被選定進行更新，更新完成可能需要一段時間。 估計需要48小時，並需重新開始一次或多次，證書才會生效。

常見問題與建議

本指南詳細說明安全開機憑證更新流程，並提出若部署到裝置時遇到問題時的故障排除步驟。 本節的匯報將視需要補充。

安全啟動憑證部署支援 

為了支援安全開機憑證更新，Windows 維護一個排程任務，每 12 小時執行一次。 該任務會尋找 AvailableUpdates 登錄檔鍵中需要處理的位元。 用於部署憑證的重點資料如下表所示。 順序欄位表示位元處理的順序。

每個位元依照上表所示順序由排程事件處理。

這些部分的進展應該是這樣： 

1. 開始時間：0x5944

2. 0x0040 → 0x5904 (成功套用 Windows UEFI CA 2023)

3. 0x0800 → 0x5104 (如果需要，Microsoft選項 ROM UEFI CA 2023)

4. 0x1000 → 0x4104 (如果需要，Microsoft UEFI CA 2023)

5. 0x0004 → 0x4100 (申請 Microsoft Corporation KEK 2K CA 2023)

6. 0x0100 → 0x4000 (套用了 Windows UEFI CA 2023 簽署的開機管理器)

注意事項

• 當與某位元相關的操作成功完成後，該位元會從 AvailableUpdates 鍵中清除。

• 若其中一項操作失敗，則會記錄事件，並在下一次排程任務執行時重試該操作。

• 如果位元0x4000被設定，則不會被清除。 在所有其他位元處理完畢後，AvailableUpdates 登錄檔金鑰會被設定為 0x4000。

問題 1：KEK 更新失敗：裝置將憑證更新至 Secure Boot 資料庫，但未進行超過 部署新 Key Exchange Key 憑證至 Secure Boot KEK。 

附註： 目前當此問題發生時，會記錄 事件 ID：1796 ， (查看安全開機資料庫及 DBX 變數更新事件) 。 稍後版本將提供新事件以說明此特定問題。 

裝置上的 AvailableUpdates 登錄檔金鑰設定為 0x4104，即使多次重啟且過了相當長的時間，也不會清除該0x0004位元。 

問題可能是 OEM 的 PK 並沒有為該裝置簽署 KEK。 OEM 控制裝置的 PK，並負責簽署新的 Microsoft KEK 憑證並將其退還給 Microsoft，以便納入每月累積更新中。 

如果你遇到這個錯誤，請向你的 OEM 確認他們是否遵循了 Windows 安全開機金鑰建立與管理指引中所列的步驟。  

問題 2：韌體錯誤：在套用憑證更新時，憑證會交給韌體，讓其套用到 Secure Boot DB 或 KEK 變數。 有時韌體會回傳錯誤。 

當此問題發生時，安全開機會記錄 事件 ID：1795。 有關此事件的資訊，請參閱 安全開機資料庫與 DBX 變數更新事件。 

我們建議你向原廠確認是否有韌體更新可以解決這個問題。