如何設定 SCEP 以實現安全企業 WiFi 與 BYOD 佈署
本技術指南說明如何設定簡單憑證註冊協定 (SCEP),以自動化安全的 802.1X 企業 WiFi 驗證與 BYOD 佈署。本指南為網路架構師與 IT 經理提供確切的部署順序、來自旅宿業與零售業的實際導入案例,以及降低風險的策略,以消除企業網路中易受攻擊的預先共用金鑰與 MAC 驗證繞過 (MAB)。
收聽此指南
查看播客逐字稿

執行摘要
對於在餐旅、零售和公共領域營運的企業場所而言,依賴預共用金鑰 (PSK) 或 MAC 驗證繞過 (MAB) 來提供員工和 BYOD WiFi 存取,是一項安全隱患。現代網路架構要求使用 EAP-TLS (可延伸驗證協定-傳輸層安全) 進行 802.1X 驗證,以確保每個裝置在存取網路之前都經過密碼學驗證。營運上的挑戰在於如何將唯一的用戶端憑證發派給數千台非託管裝置,而又不會讓您的 IT 服務台被支援工單淹沒。
RFC 8894 中定義的簡單憑證登錄協定 (SCEP),透過自動化的憑證生命週期管理解決了此發派問題。藉由利用 SCEP,IT 團隊可以將信任的根憑證和用戶端憑證推送到端點,確保私鑰永遠不會離開裝置。本指南為 SCEP WiFi 憑證部署提供了權威的架構藍圖和逐步實作策略。我們涵蓋了成功部署所需的關鍵部署順序、來自餐旅和零售業的真實世界案例,以及風險緩解策略,以確保您的 Guest WiFi 和企業網路保持安全且高效能。
技術深度解析:SCEP 架構
SCEP 是企業裝置登錄的業界標準,由 VeriSign 建立並於 1999 年作為 IETF 網際網路草案發佈。它在公開金鑰基礎建設 (PKI) 環境中自動發行 X.509 憑證,消除了大規模手動管理憑證的需求。

在 SCEP 工作流程中,裝置會在本地端產生自己的私鑰與公鑰對。它會建立一個憑證簽署要求 (CSR),並透過網路裝置註冊服務 (NDES) 伺服器傳送至您的憑證授權單位 (CA)。CA 會使用共用密鑰驗證該要求,並將已簽署的公開憑證傳回給裝置。其關鍵的安全優勢在於私鑰永遠不會離開裝置。它是在本地端產生,並儲存在裝置的硬體安全記憶區中——Windows 上的信賴平台模組 (TPM),或 iOS 上的 Secure Enclave。這使得 SCEP 成為 802.1X 驗證強烈推薦的方法,相較之下,PKCS (公開金鑰密碼學標準) 是由 CA 集中產生金鑰對並透過網路傳輸。
SCEP 憑證註冊的四個步驟如下:首先,裝置連線至由 NDES 伺服器託管的 SCEP 端點 URL。第二,裝置提供 SCEP 共用密鑰(靜態密碼或由 MDM 平台產生的動態挑戰),以驗證註冊要求。第三,裝置產生包含其公鑰和識別資訊的 CSR。第四,CA 驗證 CSR 並核發已簽署的 X.509 憑證,然後傳回給裝置。
SCEP 對比 PKCS:選擇合適的機制
在設計您的憑證部署策略時,選擇 SCEP 還是 PKCS 會直接影響安全性。下表摘要了關鍵差異。
| 屬性 | SCEP | PKCS |
|---|---|---|
| 私鑰產生 | 在裝置上 (安全記憶區) | 在 CA 伺服器上 |
| 私鑰傳輸 | 絕不傳輸 | 透過網路傳輸 |
| 基礎架構需求 | 需要 NDES 伺服器 | 不需要 NDES |
| 最佳適用場景 | WiFi 和 VPN 驗證 | S/MIME 電子郵件加密 |
| 802.1X 的安全態勢 | 推薦 | 不推薦 |
針對企業級 WiFi 的 SCEP,請務必選擇 SCEP。私鑰保留在裝置上是其根本的安全特性,這使得基於憑證的 802.1X 驗證優於任何基於憑證資訊的驗證方法。
BYOD 自助式上線流程
安全 BYOD 上線的基礎是從傳統驗證過渡到 EAP-TLS,而無需進行完整的行動裝置管理 (MDM) 註冊。強迫員工將個人智慧型手機註冊到企業 MDM 中會引發合理的隱私疑慮,並面臨強烈阻力。自助式上線入口網站解決了這個問題。
使用者將其個人裝置連線至專用的佈署 SSID,該 SSID 作為圍牆花園(walled garden),僅限制存取上線入口網站和身分識別提供者。使用者透過與 Microsoft Entra ID、Okta 或 Google Workspace 的 SAML 或 OAuth 整合進行驗證。驗證成功後,系統會透過 SCEP 產生一個唯一的、裝置專屬的用戶端憑證。設定描述檔(Apple 的 .mobileconfig 檔案或 Android Passpoint 描述檔)會被推送到該裝置。接著,裝置會使用 EAP-TLS 自動連線至安全的企業 SSID。使用者完全不需要了解任何關於憑證或 802.1X 的資訊。
實作指南:部署順序
成功為 802.1X 設定 SCEP 需要嚴格遵守特定的部署順序。在設定驗證之前,必須先建立信任關係。偏離此順序是部署失敗最常見的原因。
步驟 1:部署信任的根憑證。 在任何裝置可以要求用戶端憑證或信任您的 RADIUS 伺服器之前,它必須先信任發行的憑證授權單位(CA)。將您的根 CA 憑證(以及任何中間 CA 憑證)匯出為 .cer 檔案。透過您的 MDM 平台將此描述檔部署到您的目標裝置群組。此步驟是不可妥協的。
步驟 2:設定 SCEP 憑證描述檔。 這會指示裝置如何取得其用戶端憑證。設定主體名稱格式 — 對於使用者驅動的驗證,標準為 CN={{UserPrincipalName}};對於裝置驗證,請使用 CN={{AAD_Device_ID}}。將金鑰用途設定為 Digital signature(數位簽章)和 Key encipherment(金鑰加密)。在延伸金鑰用途下,指定 Client Authentication(用戶端驗證,OID: 1.3.6.1.5.5.7.3.2)。將此描述檔連結至步驟 1 中信任的根憑證描述檔。提供您 NDES 伺服器的外部 URL。
步驟 3:部署 802.1X WiFi 描述檔。 推送將憑證與網路 SSID 綁定的 WiFi 設定。輸入與您的存取點(AP)廣播完全相同的網路名稱。將安全性類型設定為 WPA2-Enterprise 或 WPA3-Enterprise。將 EAP 類型設定為 EAP-TLS。選擇 SCEP 憑證描述檔作為用戶端驗證憑證。指定用於伺服器驗證的信任根憑證,以確保裝置僅連線至您合法的 RADIUS 伺服器。
此順序適用於所有支援的硬體平台:Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。Purple 與硬體無關的雲端重疊網路(cloud overlay)可與所有這些平台整合,這意味著您的憑證基礎架構不會被綁定在單一硬體廠商上。
最佳實踐
透過 Azure AD Application Proxy 發佈 NDES。 NDES 伺服器必須可從網際網路存取,以便遠端裝置在抵達現場前進行憑證佈署。將內部伺服器直接暴露於網際網路會帶來重大的安全性風險。透過 Azure AD Application Proxy 進行發佈可提供安全的遠端存取,而無需開啟輸入防火牆連接埠,並允許您將條件式存取原則套用至註冊流程。
針對 BYOD 發行短期憑證。 由於 BYOD 裝置是未受管理的,因此受危害裝置留在網路上的風險較高。請發行有效期為 90 天而非數年的憑證。當憑證過期時,使用者必須透過上線入口網站重新進行驗證。這會自然地將過期的裝置從網路中清除,而無需手動的 IT 介入。
在 RADIUS 伺服器上強制執行嚴格的 CRL 檢查。 憑證部署僅是安全性方程式的一半。如果員工離職,即使其用戶端憑證仍然有效,停用其 Active Directory 帳戶也可能無法立即撤銷其 WiFi 存取權限。請設定您的 RADIUS 伺服器以強制執行嚴格的憑證撤銷清單 (CRL) 檢查。確保您的 CRL 發佈點 (CDP) 具有高可用性。如果 RADIUS 伺服器無法連線至 CRL,所有使用者的驗證都將失敗,這會導致大規模的停機。
將 BYOD 區隔至專屬的 VLAN。 BYOD 裝置是未受管理的。您無法控制其作業系統更新、防毒軟體狀態或已安裝的應用程式。請將 BYOD 裝置放置在專屬的 VLAN 上,該 VLAN 僅提供網際網路存取,並限制僅能存取該員工角色所需的特定內部應用程式。切勿將 BYOD 裝置與企業伺服器或受管理裝置放置在同一個 VLAN 上。

疑難排解與風險緩釋
WiFi 設定檔套用失敗。 裝置已接收到信任的根憑證與 SCEP 憑證,但 WiFi 設定檔在 MDM 主控台中顯示為「錯誤」。這幾乎總是由於群組目標不相符所致。如果 SCEP 設定檔指派給「使用者群組」,而 WiFi 設定檔指派給「裝置群組」,則 MDM 無法解析此相依性。請稽核您的指派,並確保信任的根憑證、SCEP 和 WiFi 設定檔全部都以完全相同的 Azure AD 群組為目標。
NDES 403 Forbidden 錯誤。 裝置無法擷取 SCEP 憑證,且 NDES IIS 記錄顯示 HTTP 403 錯誤。這很可能是因為連接器服務帳戶在憑證範本上缺乏必要的權限,或者您的防火牆封鎖了 SCEP 所使用的特定查詢字串參數。請驗證連接器帳戶在 CA 範本上是否具有「讀取」和「註冊」權限。檢查防火牆記錄以確保未封鎖包含 ?operation=GetCACaps 的 URL。
Android 碎片化。 Apple iOS 裝置處理 .mobileconfig 設定檔的方式非常一致。而 Android 則高度碎片化——不同的製造商和 OS 版本處理 WiFi 設定檔與憑證安裝的方式各不相同。請在引導入口網站上提供清晰且針對特定 OS 的說明。使用 Passpoint (Hotspot 2.0) 可以提供跨製造商一致的連線流程,進而顯著提升 Android 體驗。
憑證撤銷延遲。 當員工離職時,必須立即撤銷其存取權限。停用其 IdP 帳戶是第一步,但 RADIUS 伺服器也必須驗證憑證的狀態。請將您的 RADIUS 伺服器設定為除了 CRL 檢查之外,還使用線上憑證狀態協定 (OCSP)。OCSP 提供即時的撤銷狀態,而不是依賴定期更新的清單。
投資報酬率 (ROI) 與業務影響
過渡到 SCEP 802.1X 憑證部署,可在安全性和營運方面帶來可衡量的回報。基於密碼的 WiFi 會因密碼過期、鎖定和輸入錯誤而產生大量的客服工單。基於憑證的驗證對使用者而言是無感的——裝置會自動連線。這通常能減少 70% 與 WiFi 相關的客服工作量,讓 IT 人員得以專注於策略性工作。
EAP-TLS 消除了解析憑證和中間人 (MitM) 攻擊的風險。這對於 零售業 環境中的 PCI DSS 合規性以及所有產業的 GDPR 合規性至關重要。在 餐旅業 中,員工需要處理付款資料和顧客個人資訊,資料外洩的成本遠遠超過部署完善 PKI 基礎架構的成本。對於 交通運輸 營運商和 醫療保健 場所,同樣適用這些合規性驅動因素。
對於已經在使用 Purple 的 Guest WiFi 和 WiFi Analytics 平台的場所,將安全引導擴展到員工的 BYOD 裝置,可提供統一且強大的網路管理策略。Purple 在全球 80,000 多個實體場所營運,並在 2024 年處理了 4.4 億次登入(Purple 內部數據),並持有 ISO 27001、GDPR、CCPA 和 Cyber Essentials 認證。我們的 SecurePass 和 Shield 安全附加元件可直接與本指南中說明的基於憑證的驗證架構整合。
如需更廣泛的企業網路安全視角,請參閱我們的 企業 WiFi 安全:2026 年完整指南 。有關網路管理員特有的 GDPR 合規性考量,請參閱 網路管理員的 GDPR 與顧客資料隱私合規指南 。
關鍵定義
SCEP (Simple Certificate Enrollment Protocol)
RFC 8894 中定義的一種協定,可在 PKI 環境中自動向裝置核發 X.509 數位憑證。裝置會在本地端產生自己的私鑰,且該私鑰絕不會離開裝置。
用於大規模向企業和 BYOD 裝置部署 WiFi 驗證憑證,無需 IT 人員手動干預。為 802.1X 憑證佈署的業界標準。
802.1X
一項用於基於連接埠之網路存取控制的 IEEE 標準 (IEEE Std 802.1X-2020)。它為希望在獲准存取網路資源之前連接到 LAN 或 WLAN 的裝置提供驗證機制。
安全企業 WiFi 的基石,取代了易受攻擊的預先共用金鑰。需要 RADIUS 伺服器、用戶端裝置上的 Supplicant(請求端)以及存取點(Access Point)上的 Authenticator(驗證端)。
EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)
一種驗證架構,要求伺服器和用戶端皆須出示有效的數位憑證。提供雙向驗證,確保裝置信任網路,且網路也信任該裝置。
802.1X 驗證最安全的方法。可消除憑證竊取和中間人(Man-in-the-Middle)攻擊。為 SCEP 憑證部署旨在實現的目標驗證協定。
NDES (Network Device Enrollment Service)
一項 Microsoft Windows Server 角色,充當橋樑角色,允許沒有網域認證的裝置透過 SCEP 從 Active Directory 憑證服務 CA 取得憑證。
搭配 Microsoft Intune 實作 SCEP 時所需的基礎架構元件。應透過 Azure AD Application Proxy 發佈,以允許安全的遠端憑證佈署。
BYOD (Bring Your Own Device)
允許員工使用其個人智慧型手機、平板電腦或筆記型電腦存取企業網路和應用程式的作法。
需要仔細的網路分割和安全上網引導,以防止未受管理的裝置危害企業網路。由於隱私考量,對個人裝置進行完整的 MDM 註冊通常不切實際。
CRL (Certificate Revocation List)
由憑證授權單位(CA)發佈的清單,其中包含在到期日之前已被撤銷的憑證序號。
RADIUS 伺服器在每次驗證嘗試期間都必須檢查此清單,以確保離職員工或遭入侵的裝置無法存取網路。CRL 發佈點必須具備高可用性。
CSR (Certificate Signing Request)
由裝置產生並發送到憑證授權單位(CA)以申請數位身分憑證的訊息。包含裝置的公鑰和身分資訊。
在 SCEP 過程中由裝置產生。用於簽署 CSR 的私鑰保留在裝置上,絕不傳輸。
RADIUS (Remote Authentication Dial-In User Service)
一種網路協定,為連接到網路的使用者和裝置提供集中化的驗證、授權和計費 (AAA) 管理。
在 802.1X 驗證期間驗證用戶端憑證並授予或拒絕網路存取的伺服器。必須設定為執行嚴格的 CRL 或 OCSP 檢查。
PKCS (Public Key Cryptography Standards)
一組標準,其中公鑰和私鑰皆由憑證授權單位(CA)產生,然後安全地傳遞到終端裝置。
與 SCEP 相比,較不適合用於 WiFi 驗證,因為私鑰會透過網路傳輸。更適合用於需要金鑰託管的 S/MIME 電子郵件加密。
OCSP (Online Certificate Status Protocol)
一種提供即時憑證撤銷狀態的協定,作為定期更新 CRL 的替代方案。
在高安全性環境中比 CRL 更受青睞,因為它能提供即時的撤銷狀態,而不是依賴可能已過期數小時的清單。
範例
一間擁有 200 間客房的飯店需要為 50 名房務人員提供安全的 WiFi 存取,讓他們使用個人智慧型手機 (BYOD) 存取房務排班應用程式。IT 經理希望避免進行完整的 MDM 註冊以尊重員工隱私,但需要確保在員工離職時能立即撤銷其存取權限。
該飯店部署了與 Microsoft Entra ID 整合的自助式上網入口網頁。員工連線到開放的佈署 SSID,使用其 Entra ID 認證進行驗證,並下載 SCEP 設定檔。SCEP 伺服器直接向該裝置核發 30 天效期的用戶端憑證,且私鑰在智慧型手機的安全晶片 (Secure Enclave) 中本機產生並儲存。裝置會使用 EAP-TLS 自動連線到「Staff_WiFi」SSID。RADIUS 伺服器將這些裝置分配到受限制的 VLAN,僅允許存取排班應用程式和網際網路。當員工離職時,其 Entra ID 帳戶會被停用。設定為嚴格 CRL 檢查的 RADIUS 伺服器會在下一次驗證嘗試時拒絕其網路存取。30 天的憑證有效期可確保即使 CRL 檢查有所延遲,存取權限也會在一個月內失效。
一家擁有 500 家門市的連線零售商需要為執行 Windows 的企業專用銷售點 (POS) 平板電腦部署安全的 WiFi。網路架構師必須確保即使平板電腦被盜,也無法提取網路認證並用於從其他裝置存取企業網路。必須符合 PCI DSS 合規性。
網路架構師設定 Microsoft Intune 以透過 SCEP 部署憑證。Intune 將信任的根憑證推送到「POS Devices」群組,接著推送 SCEP 設定檔,指示每台平板電腦在 Windows TPM 中產生自己的私鑰。平板電腦向 NDES 伺服器提交 CSR,接收用戶端憑證,並使用 WPA3-Enterprise 和 EAP-TLS 連線到「Retail_POS」SSID。RADIUS 伺服器驗證憑證並將裝置置於隔離的 POS VLAN 中,該 VLAN 僅允許流量傳輸至付款處理器和庫存管理系統。所有三個 Intune 設定檔(信任的根憑證、SCEP 和 WiFi)都分配給同一個「POS Devices」裝置群組,以防止相依性失敗。NDES 透過 Azure AD Application Proxy 發佈,以便在不需要平板電腦位於現場的情況下進行憑證更新。
練習題
Q1. 您正在透過 Intune 向 Windows 筆記型電腦群組部署 SCEP 設定檔。裝置已成功接收「受信任的根憑證」,但 WiFi 設定檔套用失敗,並在 Intune 主控台中顯示為「錯誤」。SCEP 設定檔已指派給「All Users」Azure AD 群組,而 WiFi 設定檔則指派給「Corporate Laptops」裝置群組。導致此失敗的原因是什麼?您該如何解決?
提示:考慮設定檔之間的相依性,以及當一個設定檔相依於另一個設定檔時,Intune 如何解析群組目標定位。
查看標準答案
此失敗是由群組目標定位不相符所引起的。Intune 無法解析 SCEP 設定檔與 WiFi 設定檔之間的相依性,因為它們定位於不同的群組類型:一個定位於使用者,另一個定位於裝置。若要解決此問題,請稽核所有三個設定檔的指派,並確保「受信任的根憑證」、SCEP 和 WiFi 設定檔都部署到完全相同的 Azure AD 群組。請在所有設定檔中一致地選擇使用者目標定位或裝置目標定位。
Q2. 某零售場所希望保護其 POS 平板電腦的安全。IT 主管建議使用 PKCS 代替 SCEP,因為這樣可以省去 NDES 伺服器,從而簡化基礎架構。作為網路架構師,您為什麼應該推薦將 SCEP 用於 802.1X WiFi 驗證?在什麼情況下 PKCS 才是正確的選擇?
提示:思考私鑰在這兩種協定中是在何處產生與儲存的,並考慮其對網路驗證與電子郵件加密的安全影響。
查看標準答案
推薦將 SCEP 用於 802.1X WiFi 驗證,因為私鑰是在裝置本機上產生並儲存在其硬體安全記憶區(secure enclave)中。私鑰永遠不會離開裝置,也絕不會透過網路傳輸。如果平板電腦被盜,憑證也無法被提取並在其他裝置上使用。而使用 PKCS 時,CA 會集中產生金鑰組並將其傳輸到裝置,這會引入網路驗證所無法接受的傳輸風險。只有在需要金鑰託管以在原始裝置遺失時仍能解密加密電子郵件的 S/MIME 電子郵件加密案例中,PKCS 才是正確的選擇。
Q3. 您正在為一家擁有 500 張床位的醫院設計 BYOD 登入入口網頁(Captive Portal)。臨床工作人員將使用他們的個人智慧型手機存取非關鍵的內部應用程式,例如排班表和內部通訊。您需要降低員工離職後過期裝置仍留在網路上的風險,且無需 IT 人員針對每次離職進行手動干預。您應該實施什麼特定的憑證設定?
提示:考慮憑證的生命週期,以及如何強制裝置定期重新驗證,而無需 IT 人員手動撤銷每個憑證。
查看標準答案
實施有效期為 30 到 90 天的短期憑證。當憑證過期時,BYOD 裝置將被迫透過 Captive Portal,使用該員工的企業 IdP 認證資料重新進行驗證。如果該員工已離職且其 IdP 帳戶已被停用,他們將無法完成重新驗證,也無法取得新憑證。這會自然地從網路中清除過期裝置,而無需 IT 人員手動撤銷個別憑證。將此方法與 RADIUS 伺服器上的 OCSP 檢查相結合,以確保在帳戶停用時立即撤銷,從而在憑證過期週期之間提供深度防禦。
Q4. 您的 NDES 伺服器針對所有 SCEP 憑證要求傳回 HTTP 403 Forbidden 錯誤。該 NDES 伺服器可透過 Azure AD Application Proxy 從網際網路存取。導致此錯誤的兩個最可能原因是什麼?您該如何診斷這兩個原因?
提示:同時考慮憑證範本上的權限,以及裝置與 NDES 伺服器之間的網路路徑。
查看標準答案
兩個最可能的原因是:第一,Intune Certificate Connector 服務帳戶在 CA 憑證範本上缺乏必要的權限。請在 CA 主控台中驗證該服務帳戶對該範本是否擁有「讀取」和「註冊」權限。第二,防火牆或 Application Proxy 封鎖了 SCEP 所使用的特定查詢字串參數。請檢查防火牆和 Application Proxy 記錄,查看是否含有包含「?operation=GetCACaps」或「?operation=PKIOperation」等參數的要求。這些是必須允許的標準 SCEP 作業。如果 Application Proxy 正在剝離查詢字串,請調整預先驗證設定以允許 NDES URL 路徑的透傳(pass-through)。
繼續閱讀本系列
如何設定 SCEP 以實現自動化企業級 WiFi 憑證註冊
本指南說明如何設定 SCEP(簡單憑證註冊協定)以實現自動化企業級 WiFi 憑證註冊,涵蓋從 PKI 和 NDES 到 MDM 設定檔部署以及 RADIUS 驗證的完整架構。本指南專為飯店、零售連鎖店、體育場館、會議中心和公共部門組織的 IT 經理、網路架構師和 CTO 所設計,旨在協助他們淘汰預先共用金鑰,並實作具擴充性、基於身分識別的 802.1X EAP-TLS 驗證。Purple 獨立於硬體的雲端重疊平台可直接與此架構整合,提供與憑證驗證員工網路並行的訪客和 BYOD WiFi 層。
企業 SCEP 指南:部署簡單憑證登錄協定以實現自動化校園 WiFi 安全
本技術參考指南為使用 SCEP 的企業 WiFi 憑證部署提供了權威的架構藍圖和逐步實施策略。內容涵蓋 SCEP 與 PKCS 之間的核心差異、成功部署所需的確切順序,以及 IT 主管的實際風險緩釋策略。
如何實施 SCEP 以實現自動化 WiFi 憑證登錄
本指南說明如何在企業場域中實施 SCEP(簡單憑證登錄協定)以實現自動化 WiFi 憑證登錄。內容涵蓋完整的架構藍圖——從 PKI 設計和 MDM 整合到強制性的三步驟部署流程——並向 IT 主管和網路架構師展示如何消除共享認證、自動化憑證生命週期管理,以及大規模滿足 PCI DSS 和 GDPR 的要求。