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

執行摘要

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

答案就是 SCEP - 簡單憑證登冊通訊協定（Simple Certificate Enrolment Protocol）。SCEP 於 2020 年由 IETF 正式確立為 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 Networks 或 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）部署的必要條件。對於任何涉及持卡人資料處理範圍內的無線網路 - 零售收銀點（POS）、飯店櫃檯、體育場售票處 - EAP-TLS 都是正確的選擇。

如需深入了解 安全 WiFi 架構以及基於憑證的驗證如何融入更廣泛的安全防護，請參閱我們的基礎指南。

-

實作指南

部署順序是不容妥協的。Intune 和 Jamf 會依序解析設定檔的相依性：WiFi 設定檔相依於 SCEP 設定檔，而 SCEP 設定檔又相依於受信任根憑證（Trusted Root）設定檔。若未按順序部署，WiFi 設定檔將無法成功套用。

步驟 1：設計您的 PKI

在您動手操作 MDM 主控台之前，請先設計好您的憑證階層。標準做法是採用雙層 PKI：一個離線根 CA 與一個線上發行 CA。根 CA 的私鑰是您整個憑證基礎架構的核心信任錨 - 請務必使其保持實體隔離（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 應用程式 Proxy（或同等的反向代理）將 NDES URL 發布至外部。這可讓遠端裝置在抵達現場之前完成登錄，而無需開啟輸入防火牆連接埠。
• NDES 服務帳戶需要對 CA 憑證範本具備「讀取」與「登錄」權限。
• 設定憑證範本，將「金鑰用途」設定為「數位簽章」與「金鑰加密」，並將「延伸金鑰用途」設定為「用戶端驗證」（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。

**基本原則：**在所有三個相關的設定檔中，務必一律鎖定相同的 Microsoft Entra ID 群組（使用者或裝置）。這裡的配置不一致，是導致 WiFi 設定檔部署失敗最常見的單一原因。

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

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

• **主體名稱格式：**對於使用者驅動的驗證，使用 CN={{UserPrincipalName}}。對於裝置驗證（建議用於共用裝置與 IoT），使用 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。如果 CRL 無法使用 - 因為無法存取 CDP（CRL 散發點） - 大多數 RADIUS 伺服器預設會放行通過，這會帶來安全性風險。請確保您的 CDP 具有高可用性，並且將您的 RADIUS 伺服器設定為在無法取得 CRL 時預設為拒絕連線。

如需即時廢止，除了 CRL 之外，還可以設定 OCSP（線上憑證狀態協定）。OCSP 可提供單一憑證的狀態回應，而無需 RADIUS 伺服器下載並解析整個 CRL。

將裝置憑證用於共用與 IoT 裝置

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

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

自動化憑證更新

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

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

依憑證屬性進行網路區隔

RADIUS 伺服器可以讀取憑證屬性 - 主體、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。

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

投資報酬率與商業效益

採用 SCEP 憑證註冊的商業理由非常簡單。使用密碼的 WiFi 會產生預期中的支援服務台工單量：密碼過期、鎖定、員工與訪客共用憑證，以及新進員工的入職摩擦。而憑證驗證對終端使用者來說是完全無感的，裝置會自動連線。沒有會過期、共用或忘記的密碼。

從使用密碼的 WiFi 轉移到搭配 SCEP 的 EAP-TLS 的企業組織，通常會減少 70 - 80% 的 WiFi 相關支援服務台工單（Purple 內部數據，2024 年，基於餐旅和零售業物業部署）。單是支援服務台節省的成本，通常在第一年內就足以證明實施成本的合理性。

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

對於 交通運輸 營運商 - 鐵路特許經營商、機場營運商、巴士網路 - 員工裝置上的憑證驗證可確保承載安全關鍵數據的營運網路與乘客 WiFi 隔離，並防止遭受基於憑證的攻擊。

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

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