如何實施 SCEP 以實現自動化 WiFi 憑證登錄

執行摘要

對於在飯店、零售物業、體育場館和會議中心運營 Guest WiFi 的場所營運商而言，依靠預先共用金鑰或基本 Captive Portal 來進行員工網路存取是一項安全性隱憂。現代網路架構要求使用 EAP-TLS（可延伸驗證通訊協定 - 傳輸層安全性）進行 802.1X 驗證，以確保每個裝置在接觸網路之前都經過密碼學驗證。挑戰在於分發：如何在不拖垮技術支援團隊的情況下，將唯一的用戶端憑證部署到數千台 Windows、iOS 和 Android 裝置上？

答案就是 SCEP — 簡易憑證登錄協定。IETF 於 2020 年將 SCEP 正式確立為 RFC 8894，它能自動化託管裝置群的憑證登錄。當與 Microsoft Intune 或 Jamf 等 MDM 平台整合時，SCEP 可實現零接觸憑證佈署：裝置無需任何 IT 人員介入，即可自行請求、接收和更新其專屬憑證。私密金鑰在裝置本機端產生且絕不在網路中傳輸 — 與基於 PKCS 的分發相比，這具有根本性的安全優勢。

本指南將逐步介紹完整的 SCEP 實作工作流程：PKI 架構、NDES 閘道設定、強制性的 MDM 三步驟部署程序，以及決定部署成功或停滯的營運控制（特別是 CRL 檢查和群組定位）。兩個真實案例將說明在餐旅和零售環境中的應用方法。Purple 的營運範圍涵蓋 80,000 多個實體場所和 3.5 億不重複使用者；此處描述的模式反映了在此等規模下行之有效的解決方案。

技術深度剖析

SCEP 的實際運作方式

SCEP 介於您的 MDM 平台和憑證授權單位 (CA) 之間。它提供了一種標準化且基於 HTTP 的機制，讓裝置能夠請求、接收和更新 X.509 憑證，而不需要加入網域的認證或手動的管理員參與。該協定最初於 2000 年代初期開發，並在 IETF 於 2020 年正式將其發布為 RFC 8894 之前，已在企業 MDM 環境中獲得廣泛採用。

六步驟的註冊流程如下：第一，受管理裝置連線至其 MDM 設定檔中預先設定的 SCEP 閘道器 URL。第二，裝置在本機產生私鑰/公鑰對，並建立憑證簽署要求 (CSR)。第三，SCEP 閘道器使用內嵌於 MDM 原則中的挑戰密碼或 OTP 來驗證裝置的授權。第四，閘道器將驗證過的 CSR 轉發給 CA。第五，CA 簽署憑證並將其傳回閘道器。第六，閘道器將簽署後的憑證傳遞給裝置。未來的更新流程也遵循相同的自動化路徑：裝置在過期前重新註冊，無需任何使用者或管理員的操作。

SCEP 對決 PKCS：至關重要的抉擇

Microsoft Intune 與大多數 MDM 平台支援兩種憑證傳遞機制：SCEP 與 PKCS。兩者的差異在於架構，而非僅是形式。

採用 SCEP 時，私鑰在裝置上產生並保留在該處，CA 永遠不會接觸到它。裝置的 TPM（Windows 系統）或 Secure Enclave（iOS/macOS 系統）會在硬體層級保護該金鑰。而採用 PKCS 時，CA 會集中產生金鑰對，並透過網路將其傳輸到裝置。CA 會保留一份備份以支援金鑰託管——這對 S/MIME 電子郵件加密很有幫助，但對網路驗證而言則引入了不必要的風險。

針對 802.1X WiFi 驗證，請使用 SCEP。私鑰絕不離開裝置，這是基本原則。

802.1X 與 EAP-TLS：驗證架構

IEEE 802.1X 是奠定企業級 WiFi 安全基礎的連接埠型網路存取控制標準。它定義了三種角色：要求端（用戶端裝置）、驗證器（無線基地台，例如 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 或 Fortinet），以及驗證伺服器（RADIUS 伺服器，例如 Microsoft NPS、FreeRADIUS 或 Cisco ISE）。

EAP-TLS 是 802.1X 中最安全的 EAP 方法。雙方均需出示憑證：RADIUS 伺服器向用戶端出示其憑證，而用戶端則向 RADIUS 伺服器出示其透過 SCEP 配置的憑證。在沒有來自受信任 CA 階層架構且有效、未經撤銷的憑證情況下，任何一方都無法冒充另一方。這種雙向驗證模式透過單一架構決策，徹底消除了憑證竊取、邪惡雙生仔（Evil Twin）攻擊以及惡意存取點的風險。

EAP-TLS 符合 PCI DSS 4.0 規範 8.6 中關於網路層多因素驗證的要求。它是 WPA3 Enterprise 192 位元 (Suite B) 部署的必要條件。對於處理持卡人資料之範圍內的所有無線網路（例如零售收銀點、飯店櫃檯、體育場售票處），EAP-TLS 都是正確的選擇。

若想深入瞭解 安全 WiFi 架構以及憑證式驗證如何融入更廣泛的安全防護體系，請參閱我們的基本指南。

實作指南

部署順序不可調整。Intune 和 Jamf 會按順序解析設定檔相依性：WiFi 設定檔取決於 SCEP 設定檔，而 SCEP 設定檔又取決於受信任根（Trusted Root）設定檔。若未按順序部署，WiFi 設定檔將無法成功套用。

步驟 1：設計您的 PKI

在您操作 MDM 主控台之前，請先設計好您的憑證階層架構。雙層 PKI 是標準做法：包含一部離線根 CA 與一部線上發行 CA。根 CA 的私鑰是您整個憑證基礎架構的核心信任起點（Master Trust Anchor），請務必保持實體隔離（Air-gapped）。發行 CA 則負責處理日常的憑證簽發，並發佈憑證撤銷清單 (CRL) 及 OCSP 回應程式。

對於大多數企業場域的部署，在 Windows Server 上執行的 Microsoft Active Directory 憑證服務 (AD CS) 可提供發行 CA。來自 SCEPman 或 SecureW2 等供應商的雲端代管 PKI 服務可完全消除對地端基礎架構的需求，非常值得連鎖飯店、零售連鎖店或多據點公共部門組織等分散式資產部署進行評估。

步驟 2：部署 NDES 伺服器（或雲端 SCEP 閘道）

NDES（網路裝置註冊服務）是 Microsoft Windows Server 的角色，可作為 MDM 與 CA 之間的 SCEP 閘道。關鍵組態要求包括：

• 透過 Azure AD Application Proxy（或同等的反向代理）將 NDES URL 發佈至外部。這可讓遠端裝置在抵達現場之前完成註冊，而無需開啟連入的防火牆連接埠。
• NDES 服務帳戶需要對 CA 憑證範本擁有「讀取」與「註冊」權限。
• 設定憑證範本，將金鑰用途（Key Usage）設為「數位簽章」與「金鑰加密」，並將延伸金鑰用途（Extended Key Usage）設為「用戶端驗證」（OID: 1.3.6.1.5.5.7.3.2）。
• 設定適當的憑證有效期。用戶端憑證標準為一年；對於穩定裝置群中的裝置憑證，兩年是可以接受的。 如果您希望避免在內部部署 NDES 基礎架構，雲端 SCEP 閘道可以直接透過 API 與 Intune 及您的 CA 進行整合，從而完全免除對 IIS 的依賴。

步驟 3：部署信任的根憑證設定檔

在您的 MDM 平台中，建立一個「信任的憑證」設定檔，並將您的根 CA 憑證（以及任何中介 CA 憑證）以 .cer 檔案格式上傳。請在部署任何其他憑證或 WiFi 設定檔之前，先將此設定檔部署到您的目標裝置群組。若少了此步驟，裝置在 EAP-TLS 握手期間將無法驗證 RADIUS 伺服器的憑證，且在要求自身的 SCEP 憑證時也無法信任發行 CA。

經驗法則： 在所有三個相關的設定檔中，務必一律鎖定相同的 Azure AD 群組（使用者或裝置）。此處的配置不一致是導致 WiFi 設定檔部署失敗最常見的單一原因。

步驟 4：設定 SCEP 憑證設定檔

在您的 MDM 中建立 SCEP 憑證組態設定檔：

• 主體名稱格式： 針對使用者驅動的驗證，使用 CN={{UserPrincipalName}}。針對裝置驗證（建議用於共用裝置與物聯網），使用 CN={{AAD_Device_ID}}。
• 金鑰用途： 數位簽章（Digital Signature）、金鑰加密（Key Encipherment）。
• 延伸金鑰用途： 用戶端驗證（Client Authentication，OID: 1.3.6.1.5.5.7.3.2）。
• SCEP 伺服器 URL： 外部發佈的 NDES URL。
• 根憑證： 連結至步驟 3 中信任的根憑證設定檔。
• 憑證有效期： 與 CA 上設定的範本保持一致。

步驟 5：部署 802.1X WiFi 設定檔

建立 WiFi 組態設定檔：

• SSID： 輸入與您的存取點所廣播完全相同的網路名稱。
• 安全性類型： WPA2-Enterprise 或 WPA3-Enterprise。
• EAP 類型： EAP-TLS。
• 用戶端驗證憑證： 選取步驟 4 中的 SCEP 憑證設定檔。
• 伺服器驗證： 指定步驟 3 中信任的根憑證，並輸入預期的 RADIUS 伺服器名稱。這可防止裝置連線到呈現詐騙憑證的惡意存取點。

最佳實踐

在您的 RADIUS 伺服器上強制執行嚴格的 CRL 檢查

憑證撤銷是一項維運管理控制措施，用以消除「停用帳戶」與「封鎖網路存取」之間的時間差。當裝置遺失、遭竊或員工離職時，請停用 AD 帳戶並在 CA 撤銷該憑證。您的 RADIUS 伺服器必須設定為在每次驗證嘗試時皆檢查 CRL。如果因無法連線到 CDP（CRL 分發點）而導致 CRL 無法使用，大多數 RADIUS 伺服器預設會採取「允許通行（Fail-open）」，這會帶來安全風險。請確保您的 CDP 具備高可用性，且您的 RADIUS 伺服器設定為在無法取得 CRL 時採取「預設阻止（Fail-closed）」。

如需即時撤銷，除了 CRL 之外，亦可設定 OCSP（線上憑證狀態協定）。OCSP 可提供單一憑證的狀態回應，而無需 RADIUS 伺服器下載並剖析整個 CRL。### 針對共用與 IoT 裝置使用裝置憑證

對於共用裝置 — 飯店房務平板電腦、零售 POS 終端機、體育場門禁讀卡機 — 請使用裝置憑證而非使用者憑證。裝置憑證與機器身分綁定，而非使用者帳戶。這表示無論哪位使用者登入，裝置都能進行驗證，且撤銷作業是與裝置記錄綁定，而非員工的離職。

對於 零售 部署，POS 硬體上的裝置憑證也符合 PCI DSS 對網路層裝置身分的要求，而不會在銷售點引入複雜的使用者憑證。

自動化憑證更新

SCEP 支援自動更新：MDM 會在憑證過期前指示裝置重新註冊。請將您的 SCEP 設定檔配置為在憑證剩餘有效期為 20% 時觸發更新。對於一年期的憑證，更新大約會在過期前 73 天開始。這個時間窗口提供了足夠的時間來解決任何更新失敗，避免憑證過期導致裝置失去網路連線。

憑證過期導致大規模驗證失敗是 802.1X 部署中常見的維運事件。透過 SCEP 進行自動化更新可以完全消除此風險。

按憑證屬性進行網路區隔

RADIUS 伺服器可以讀取憑證屬性 — 主體（Subject）、SAN 或自訂 OID — 並使用它們將裝置動態分配到 VLAN。從 HousekeepingDevices 範本發行憑證的房務平板電腦會進入房務 VLAN。從 RetailPOS 範本發行憑證的 POS 終端機則會進入 PCI 範圍內的 VLAN。這是透過密碼學強制執行的網路區隔 — 比基於 SSID 或 MAC 的方法可靠得多。

對於在同一實體基礎架構上同時運行 Guest WiFi 與 Staff WiFi 的 旅宿業 業者而言，透過憑證屬性進行 VLAN 分配可確保賓客和員工始終處於獨立的網路區段，無論裝置連接到哪個 SSID。

疑難排解與風險緩釋

WiFi 設定檔在 Intune 中顯示「錯誤」或「不適用」

根本原因： 群組定位不符。SCEP 設定檔指派給了與 WiFi 設定檔不同的群組。Intune 無法解析憑證相依性。

解決方法： 稽核所有三個設定檔（信任的根、SCEP、WiFi）。確保它們都指派給完全相同的 Azure AD 群組。如果您是部署到「使用者」，這三個設定檔都必須定位到「使用者」群組。如果是部署到「裝置」，則三個都必須定位到「裝置」群組。

NDES 傳回 HTTP 403 錯誤

根本原因： Intune Certificate Connector 服務帳戶對 CA 憑證範本缺少「讀取」或「註冊」權限，或者防火牆 URL 篩選封鎖了 SCEP 查詢字串。

**修正方法：**驗證連接器帳戶在 CA 主控台的範本上具有「讀取」與「註冊」權限。檢查防火牆記錄，確認是否有包含 ?operation=GetCACaps 或 ?operation=PKIOperation 的請求遭到封鎖。這些查詢字串必須在未經修改的情況下通過。

裝置在憑證過期前無法更新

**根本原因：**SCEP 更新窗口太短，或是在更新時無法連線至 NDES 伺服器。

**修正方法：**將更新閾值設定為憑證有效期的 20%。確保 NDES URL 已透過高可用性的反向代理發佈。監控 NDES IIS 記錄以尋找更新請求失敗，並主動對其發出警報。

RADIUS 拒絕有效的憑證

**根本原因：**RADIUS 伺服器的受信任 CA 存放區不包含核發 CA 的憑證，或者 CRL 已過期。

**修正方法：**將完整的 CA 鏈（根 CA + 核發 CA）匯入 RADIUS 伺服器的受信任存放區。驗證是否已成功提取 CRL，且可從 RADIUS 伺服器連線至 CDP URL。檢查 CRL 的下一次更新時間戳記 - 如果已經過期，CA 則需要發佈新的 CRL。

如需同時考慮更廣泛的網路效能與安全性，請參閱我們的 頻寬管理指南 。

ROI 與商業效益

採用基於 SCEP 的憑證註冊之商業案例非常明確。基於密碼的 WiFi 會產生可預測的技術支援工單量：密碼過期、鎖定、員工與訪客共用憑證，以及新進員工的入職摩擦。而基於憑證的驗證對終端使用者而言是完全無感的。裝置會自動連線。沒有密碼會過期、共用或遺忘。

從基於密碼的 WiFi 遷移到採用 SCEP 的 EAP-TLS 的企業組織，通常會報告 WiFi 相關技術支援工單減少了 70-80%（Purple 內部數據，2024 年，基於餐旅與零售物業的部署情況）。光是技術支援服務省下的成本，通常在第一年內就能攤平實施成本。

合規性方面的影響同樣具體。EAP-TLS 符合 PCI DSS 4.0 規範 8.6 中關於網路層多因素驗證的要求。對於 醫療保健 環境，它符合 HIPAA 對於無線網路存取的技術安全防護要求。對於公共部門組織，它支援 NCSC Cyber Essentials Plus 網路存取控制的認證要求。

對於 交通運輸 營運商（鐵路特許經營商、機場營運商、公車路網）而言，在員工裝置上使用基於憑證的驗證，可確保傳輸安全關鍵資料的營運網路與乘客 WiFi 隔離，並免受基於憑證的攻擊。

Purple 的 WiFi Analytics 平台與 802.1X 安全網路整合，在不損及底層基礎架構安全狀況的情況下，提供第一方數據洞察。在 Purple 網路中收集的 290 億個數據點證明，安全與分析是互補而非競爭的目標。

如需在部署安全網路的同時進行回饋與體驗管理，請參閱我們的 場域回饋攻略 。