跳至主要內容

管理 EAP-TLS WiFi 驗證的數位憑證

本技術參考指南詳細說明了 EAP-TLS WiFi 驗證數位憑證的生命週期管理。它提供了實用的策略,以便在使用 SCEP 和 MDM 整合的大型企業網路中部署、更新和撤銷憑證。

📖 4 分鐘閱讀📝 892 字數🔧 2 範例3 練習題📚 8 關鍵定義

收聽此指南

查看播客逐字稿
請以自信、權威且口語化的英國英語口氣發言——就像資深顧問向客戶進行簡報一樣。節奏沉穩、咬字清晰、溫暖而直接。偶爾自然停頓以示強調: 歡迎收看 Purple 技術簡報系列。今天我們要討論的是 EAP-TLS 憑證管理——具體來說,是如何大規模運行憑證型 WiFi 驗證計劃,而不會使其成為全職的維運負擔。 [medium pause] 如果您負責跨多個據點的公司或員工 WiFi——無論是飯店集團、零售物業、大學校園還是公共部門資產——這場簡報都非常適合您。我們將涵蓋完整的憑證生命週期:從建立您的 CA 階層架構,到透過 SCEP 和 MDM 進行自動化部署,再到更新與撤銷。我們還會探討哪些地方容易出錯(因為確實會出錯),以及如何避免最常見的陷阱。 [medium pause] 讓我們從基本原理開始。EAP-TLS(即具有傳輸層安全性的可延伸驗證協定)是 802.1X WiFi 驗證的金科玉律。與依賴使用者名稱和密碼的 PEAP 不同,EAP-TLS 使用雙向憑證型驗證。裝置使用用戶端憑證證明其身分。RADIUS 伺服器使用伺服器憑證證明其身分。雙方互相驗證。沒有密碼會被釣魚。沒有憑證會被竊取。這就是為什麼 PCI DSS 4.0 和 NCSC 的零信任指引都指向針對員工網路採用憑證型驗證的原因。 [medium pause] 接著是架構。要讓 EAP-TLS 運作,您需要三樣東西。第一,公鑰基礎建設(PKI)——即您的 CA 階層架構。第二,將憑證部署到裝置上的機制——也就是 SCEP 或您的 MDM 平台。第三,一個信任您的 CA 且能即時驗證用戶端憑證的 RADIUS 伺服器。 [medium pause] CA 階層架構是大多數組織早期最容易遇到麻煩的地方。正確的模式是三層模型。最頂層是根憑證授權單位(Root CA)——這應該是離線且實體隔離(air-gapped)的,只有在需要為您的中介憑證授權單位(Intermediate CA)憑證簽章時才會連線。中介憑證授權單位(有時稱為簽發憑證授權單位 Issuing CA)是實際簽發日常憑證的單位。它處於連線狀態,但其私鑰受到妥善保護。在此之下,您會簽發兩種類型的憑證:用於 RADIUS 基礎建設的伺服器憑證,以及用於裝置和使用者的用戶端憑證。 [medium pause] 為什麼這很重要?因為如果您的 Root CA 遭到入侵,您就必須從頭開始重建整個 PKI,並重新註冊每台裝置。保持其離線狀態可以消除這種風險。中介 CA 可以在不影響 Root CA 的情況下進行更換。這就是三層模型在維運韌性上的優勢。 [medium pause] 我們來談談憑證有效期限。業界在這方面發生了重大轉變。Apple、Google 和 Mozilla 都已開始強制縮短憑證的最長生命週期。對於 TLS 伺服器憑證,目前最長期限為 398 天。對於企業 WiFi 中的用戶端憑證,您擁有更大的彈性——通常是一到兩年——但目前的趨勢是縮短生命週期並採用自動更新,而非手動管理長期憑證。原因很簡單:縮短生命週期可以限制憑證遭到破解時的暴露期。 [medium pause] 這帶領我們走向自動化。手動憑證管理無法擴充規模。如果您有 500 台裝置,您勉強還可以手動管理更新。但如果您在 50 個據點擁有 5,000 台裝置,這就變得不可能了。您需要 SCEP(簡單憑證註冊協定)或其現代繼承者 EST。SCEP 直接與 MDM 平台整合,包括 Microsoft Intune、Jamf Pro 和 VMware Workspace ONE。MDM 會將 SCEP 設定設定檔推送到裝置。裝置產生金鑰組,向您的 SCEP 伺服器傳送憑證簽署要求,並接收回傳的已簽署憑證——這一切完全不需要任何使用者互動。 [medium pause] 對於 Active Directory 環境中的 Windows 裝置,您有另一種選擇:透過 Active Directory 憑證服務進行群組原則驅動的自動註冊。裝置向網域進行驗證,憑證授權單位(CA)會自動核發憑證,且憑證在過期前會自動更新,無需任何手動介入。對於大量使用 Windows 的環境,這是最無縫的途徑。 [medium pause] 接著是撤銷。這是組織最常投資不足的部分,但也是出問題時最重要的環節。如果裝置遺失、遭竊或員工離職,您需要立即撤銷其憑證。有兩種機制:CRL(憑證撤銷清單)和 OCSP(線上憑證狀態協定)。 [medium pause] CRL 是較舊的機制。您的 CA 會在已知的 URL 發布已撤銷憑證序號的清單。RADIUS 伺服器會定期下載此清單並進行比對。CRL 的問題在於延遲——如果您的 CRL 有 24 小時的有效期限,已撤銷的憑證在撤銷後最多仍可在 24 小時內進行驗證。 [medium pause] OCSP 則是即時的替代方案。針對每次驗證嘗試,RADIUS 伺服器都會向 OCSP 回應程式傳送查詢,並取得即時的有效或已撤銷回應。妥協之處在於,您的 OCSP 回應程式會成為關鍵依賴——如果它無法使用,您需要決定是要「失敗開啟」還是「失敗關閉」。對於高安全性環境,「失敗關閉」是正確的答案。對於著重可用性的營運環境,您可以設定短暫的 OCSP 寬限期。 [medium pause] 讓我給您兩個具體的情境,使其更加具體。 [medium pause] 首先:一家擁有 150 家物業的飯店集團。他們原本針對員工 WiFi 運行 PEAP 並使用共用密碼。密碼每季輪替一次,這意味著每季會有兩週的窗口期,期間員工會被鎖定或使用舊密碼。他們改用 EAP-TLS,並使用 Microsoft Intune 進行憑證部署。SCEP 設定檔被推送到所有 Windows 和 iOS 裝置。以 Active Directory 憑證服務作為 CA。結果是:零密碼輪替事件、憑證在過期前 30 天自動處理更新,且當員工離職時,在其帳戶於 Microsoft Entra ID 中停用後的幾分鐘內,其憑證就會在 MDM 中被撤銷。IT 團隊估計,他們每季在密碼重設和支援服務工單方面節省了約 40 個小時。 [medium pause] 第二:一家在 200 家門市中擁有 3,000 台員工裝置的多據點零售連鎖店。這裡的挑戰在於裝置的多樣性——混合了 Windows 筆記型電腦、Android 手持裝置和 iOS 裝置。他們針對 Apple 裝置使用 Jamf Pro,針對 Windows 和 Android 使用 Microsoft Intune,兩者都指向同一個由 Microsoft ADCS 中介 CA 支援的 SCEP 伺服器。WiFi 基礎架構為 Cisco Meraki,並透過與 Purple 整合的雲端託管 RADIUS 服務來處理 RADIUS 驗證。關鍵的設計決策是核發有效期為 12 個月的憑證,並設定在過期前 60 天自動更新。這提供了一個充裕的更新窗口,且不會增加營運開銷。 [medium pause] 現在來談談陷阱。我經常看到以下四個陷阱。 [medium pause] 第一:未測試撤銷。企業組織建立了自己的 PKI、部署了憑證,卻從未實際測試撤銷機制是否能端到端正常運作。請務必測試。撤銷一張測試憑證,確認 RADIUS 伺服器在您預期的窗口期內偵測到該撤銷,並確認該裝置被拒絕存取。 [medium pause] 第二:過期懸崖。如果您在同一時間核發所有具有相同有效期的憑證,它們將在同一時間全部過期。請錯開您的核發時間,或者至少錯開您的更新觸發時間。在 5,000 台裝置上同時發生 10% 的更新失敗率是一起重大事件。 [medium pause] 第三:在部署 EAP-TLS 之前,未將根 CA 憑證分發到所有裝置。如果裝置不信任您的根 CA,它將拒絕 RADIUS 伺服器的憑證,進而導致驗證失敗。這聽起來很顯而易見,但當組織擁有未註冊到 MDM 中的 BYOD 裝置或外包商筆記型電腦時,往往會因此出錯。 [medium pause] 第四:OCSP 回應程式的可用性。如果您的 OCSP 回應程式當機,且您的 RADIUS 伺服器設定為在發生 OCSP 錯誤時採取「預設關閉」(fail closed),則您的整個 WiFi 網路環境都將停止運作。請為您的 OCSP 基礎架構建立備援,或設定一段帶有適當監控的簡短寬限期。 [medium pause] 好的,接下來是快速問答。 [medium pause] 我可以使用公開 CA 來處理 EAP-TLS 用戶端憑證嗎?技術上可以,但實際上不行。公開 CA 不會為任意裝置核發用戶端憑證。您需要擁有自己的 CA 來處理用戶端憑證。至於 RADIUS 伺服器憑證,使用公開 CA 是可行的,且能簡化信任發布。 [medium pause] 那 BYOD 呢?BYOD 是個棘手的案例。您無法透過 MDM 將憑證推送到非託管裝置。解決方案包括使用網路存取控制入口網站,在使用者驗證後核發短期憑證,或者直接將 BYOD 保留在使用不同驗證方式的獨立 SSID 上。 [medium pause] 這與 WPA3 如何互動?WPA3-Enterprise 針對敏感環境強制要求 192 位元安全性模式,這需要特定的加密套件。EAP-TLS 與 WPA3-Enterprise 完全相容,且實際上是建議的驗證方法。 [medium pause] 總結來說。EAP-TLS 憑證管理並不簡單,但如果您從一開始就規劃好正確的架構,它是可以管理的。三層式 CA 階層。透過 SCEP 或 MDM 進行自動化登冊。縮短憑證效期並進行自動更新。透過 OCSP 進行即時撤銷。測試所有環節,特別是撤銷功能。並將您的憑證生命週期與您的身分識別提供者(Microsoft Entra ID、Okta 或 Google Workspace)整合,以便在帳戶停用時自動觸發憑證撤銷。 [medium pause] 如果您正在執行與 Purple 連結的 RADIUS 伺服器,整合點即為您的 SCEP 伺服器 URL、您的 RADIUS 伺服器憑證以及您的 CRL 或 OCSP 端點。Purple 與硬體無關的架構意味著這適用於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist 以及其他標準硬體清單——您不會被鎖定在單一廠商的 PKI 工具中。 [medium pause] 後續步驟:稽核您目前的憑證清單。如果您不知道自己擁有多少張憑證、何時過期以及由誰核發,這就是首要解決的問題。從那裡開始,邁向完全自動化的道路就非常明確了。感謝您的收聽。

header_image.png

執行摘要

管理用於 EAP-TLS WiFi 驗證的數位憑證,對企業 IT 團隊而言是一項重大的營運挑戰。隨著企業組織逐步淘汰憑證型驗證(credential-based authentication)以符合零信任規範,營運負擔也從密碼重設轉移到憑證生命週期管理。本指南詳細介紹了在複雜的資產環境中,大規模部署、更新和撤銷用戶端憑證所需的架構模式。

對於技術長(CTO)和網路架構師而言,目標非常明確:實施強健的公開金鑰基礎建設(PKI),並與現有的行動裝置管理(MDM)平台無縫整合。透過簡單憑證註冊協定(SCEP)自動發放憑證,並執行即時撤銷,即可消除人工干預。此方法能確保網路邊界安全,滿足包括 PCI DSS 4.0 在內的合規框架,並確保運行企業硬體的 80,000 多個實體場域持續保持連線。

技術深入探討

EAP-TLS(可延伸驗證協定與傳輸層安全)代表了 802.1X 網路存取控制的最高標準。它強制執行雙向驗證。RADIUS 伺服器出示憑證以向用戶端證明其身分,而用戶端則出示憑證以向網路證明其身分。

三層式 PKI 架構

扁平式的 PKI 層級結構會引入無法接受的風險。推薦的模式是三層式架構:

  1. 根憑證授權單位 (Root CA):最終的信任根源。此伺服器保持離線並與網路隔離(air-gapped)。其唯一功能是簽署中間 CA 憑證。
  2. 中間 CA (發放 CA):此伺服器保持在線,負責日常用戶端與伺服器憑證的簽署工作。如果遭到破解,可由 Root CA 予以撤銷,而無需重建整個信任基礎建設。
  3. 終端實體憑證 (End-Entity Certificates):這些是實際部署到 RADIUS 伺服器和用戶端裝置的憑證。

pki_trust_chain_diagram.png

憑證效期與密碼學標準

業界正強制縮短憑證壽命,以限制金鑰遭破解時的暴露空窗期。雖然公開的 TLS 憑證上限為 398 天,但用於 WiFi 驗證的內部用戶端憑證通常使用 365 天的有效期。

密碼學要求強制使用至少 2048 位元的 RSA 金鑰,或使用 P-256 曲線的橢圓曲線密碼學 (ECC)。WPA3-Enterprise 192 位元模式需要特定的加密套件,而 EAP-TLS 是唯一能完全滿足這些要求的驗證方法。

實作指南

在分散式場域中部署 EAP-TLS 需要您的身分識別提供者、MDM 平台與網路硬體之間進行緊密整合。Purple 的雲端重疊(cloud overlay)可與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 整合。

步驟 1:建立信任鏈

在任何裝置進行驗證之前,它必須信任 RADIUS 伺服器。請透過您的 MDM 將根憑證授權機構(Root CA)憑證部署到所有託管裝置。對於非託管裝置,您必須提供一個引導註冊入口網頁(onboarding portal)來安裝信任設定檔。

步驟 2:透過 SCEP 自動化核發

手動產生憑證是行不通的。請實作 SCEP 以將此工作流程自動化:

  1. MDM(例如 Microsoft Intune)將 SCEP 負載推送到裝置。
  2. 裝置在本地端產生私鑰。
  3. 裝置向 SCEP 伺服器提交憑證簽署請求(CSR)。
  4. CA 核發憑證,裝置並將其安裝在硬體備份的金鑰庫中。

步驟 3:設定 RADIUS 原則

將您的 RADIUS 伺服器設定為需要 EAP-TLS。確保伺服器會比對您的身分識別目錄(Microsoft Entra ID、Okta 或 Google Workspace)驗證用戶端憑證的主體別名(SAN),以確認該使用者帳戶仍處於啟用狀態。

certificate_lifecycle_infographic.png

最佳實踐

  • 儘早自動續期:設定 MDM 設定檔,使其在憑證到期前至少 30 天觸發憑證續期。這可以防止整個場域內突然發生驗證失敗。
  • 強制執行硬體金鑰庫:要求私鑰必須在裝置的信賴平台模組(TPM)或安全隔離區(Secure Enclave)中產生並儲存。金鑰必須設定為不可匯出。
  • 實作即時撤銷:依賴靜態憑證撤銷清單(CRL)會產生延遲。請實作線上憑證狀態協定(OCSP),以便 RADIUS 伺服器能在驗證期間即時確認憑證狀態。

疑難排解與風險緩釋

EAP-TLS 部署中最常見的失敗模式與信任和時間有關。

信任錨點失敗

如果用戶端裝置拒絕 RADIUS 伺服器憑證,驗證將會無聲無息地失敗。當裝置的信任庫中遺失根 CA 憑證時,就會發生這種情況。請驗證 MDM 部署記錄,確保信任設定檔在 WiFi 設定檔之前套用。如需連線問題的進一步診斷,請參閱 Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures

到期懸崖

同時核發數千張憑證會造成續期高峰期的懸崖效應。如果 SCEP 伺服器在此期間發生停機,裝置將會斷開網路。請交錯進行初始部署,以分攤續期負載。

OCSP 逾時

如果 RADIUS 伺服器無法連線至 OCSP 回應程式,它必須決定是要預設開放(fail open)還是預設關閉(fail closed)。對於企業網路,預設關閉是標準做法。請確保您的 OCSP 基礎架構具備高可用性且呈地理分佈。

投資報酬率與業務影響

過渡到 EAP-TLS 需要前期投入工程心力,但營運回報非常顯著。一個擁有 5,000 名使用者的組織,通常每月要花費 40 小時來處理因 PEAP 密碼輪替而導致的密碼重設與 RADIUS 鎖定問題。

透過自動化憑證生命週期,您可以消除這些支援工單。此外,您還能滿足 ISO 27001 和 PCI DSS 嚴格的存取控制要求,從而減少稽核開銷。當與 Guest WiFiWiFi Analytics 整合時,Purple 可針對所有使用者類型提供統一的網路存取檢視,簡化分散式場域的合規性報告。

關鍵定義

EAP-TLS

具有傳輸層安全性的可延伸驗證通訊協定(Extensible Authentication Protocol with Transport Layer Security)。一種要求用戶端和伺服器雙方使用數位憑證來證明其身分的驗證架構。

確保企業 WiFi 網路安全且無需依賴易受攻擊之密碼的業界標準。

SCEP

簡單憑證註冊協定(Simple Certificate Enrolment Protocol)。MDM 平台用於在裝置上安全地自動要求與安裝數位憑證的協定。

藉由消除手動憑證處理,這對於擴展數十台裝置以上的 EAP-TLS 部署至關重要。

RADIUS

遠端用戶撥入驗證服務(Remote Authentication Dial-In User Service)。提供集中式驗證、授權和記帳管理的網路協定。

驗證用戶端憑證並指示存取點授與網路存取權限的伺服器元件。

OCSP

線上憑證狀態協定(Online Certificate Status Protocol)。一種網際網路協定,用於即時取得 X.509 數位憑證的撤銷狀態。

取代靜態 CRL,以確保已撤銷的憑證立即被網路阻擋。

Root CA

根憑證授權單位(Root Certificate Authority)。公開金鑰基礎建設(PKI)中的頂級密碼編譯授權單位,用於簽署附屬 CA。

必須保持高度安全且處於離線狀態,以保護組織的整個信任鏈。

SAN

主體別名(Subject Alternative Name)。X.509 的延伸,允許將各種值(例如電子郵件地址或 UPN)與安全性憑證關聯。

RADIUS 伺服器用來將憑證對應到身分識別目錄中特定使用者帳戶的欄位。

MDM

行動裝置管理。IT 部門用於監控、管理和保護員工行動裝置的軟體。

將 SCEP 配置和 WiFi 設定檔推送到終端使用者裝置的傳遞機制。

CRL

憑證撤銷清單。由發行 CA 在其預定到期日之前撤銷的數位憑證清單。

與 OCSP 相比,這是一種傳統的憑證有效性檢查方法,存在延遲問題。

範例

一家擁有 150 家分店的飯店集團需要確保 3,000 台裝置的員工存取安全。他們目前使用 PEAP 搭配每季更換一次的共用密碼,這導致了大量的客服支援需求。他們應該如何實作 EAP-TLS?

部署 Microsoft Intune 來管理所有企業裝置。建立一個 Microsoft ADCS 中介 CA,並透過 Intune Certificate Connector 與 Intune 整合。將 Root CA 憑證推送到所有裝置,接著推送一個 SCEP 設定檔,要求有效期為 365 天的用戶端憑證。將 WiFi 設定檔配置為使用 EAP-TLS,並指向與 Purple 連結的 RADIUS 伺服器。將 SCEP 設定檔設定為在剩餘壽命 20%(73 天)時自動更新。

考官評語: 這種方法完全免除了每季更換密碼的需求。藉由設定提早更新的觸發條件,IT 團隊可以避免憑證到期的過渡危機。直接與 Intune 整合可確保當員工離職且其 Entra ID 帳戶被停用時,MDM 會自動撤銷憑證並抹除 WiFi 設定檔。

一家零售連鎖店在 200 個據點需要為銷售點(POS)手持裝置提供安全的 WiFi。這些裝置運行 Android 系統,且經常與中央管理伺服器中斷連線。您如何處理憑證撤銷?

在 RADIUS 伺服器層級實作 OCSP,以進行即時撤銷檢查。配置 RADIUS 伺服器在每次驗證嘗試時查詢 OCSP 回應程式。如果報告手持裝置遺失,安全團隊會在 CA 中撤銷該憑證。下次裝置嘗試與存取點關聯時,RADIUS 伺服器會從 OCSP 收到「已撤銷」的回應,並立即拒絕存取。

考官評語: 如果遺失的裝置處於離線狀態或被屏蔽,僅依賴 MDM 來抹除裝置是不夠的。藉由透過 OCSP 在網路邊緣強制執行撤銷檢查,RADIUS 伺服器可作為強制執行點,確保即使 MDM 無法連線至裝置本身,受損的憑證也無法被使用。

練習題

Q1. 您正在為 2,000 台企業筆記型電腦部署 EAP-TLS。SCEP 基礎架構已設定,但在測試期間,筆記型電腦無法連接到 WiFi。RADIUS 記錄顯示「未知的 CA」。最可能的原因是什麼?

提示:考慮部署信任設定檔與驗證設定檔時的操作順序。

查看標準答案

筆記型電腦的受信任根儲存庫中未安裝根 CA 憑證。必須設定 MDM,在發送 SCEP 負載或 EAP-TLS WiFi 設定檔之前,先將根 CA 憑證負載推送到裝置。如果沒有根 CA,用戶端會拒絕 RADIUS 伺服器的憑證。

Q2. 一部遭入侵的裝置回報遺失。IT 小組已從 MDM 中刪除該裝置,並在 CA 中撤銷了憑證。然而,測試顯示該裝置在最長 12 小時內仍可連接到網路。您該如何解決此問題?

提示:查看 RADIUS 伺服器如何驗證憑證狀態。

查看標準答案

RADIUS 伺服器可能依賴每 12 到 24 小時才發布或下載一次的憑證撤銷清單 (CRL)。若要解決此問題,請實作線上憑證狀態協定 (OCSP),並將 RADIUS 伺服器設定為在每次驗證嘗試期間向 OCSP 回應程式進行查詢,以進行即時驗證。

Q3. 您正在設計憑證生命週期策略。安全性小組希望將憑證有效期設為 30 天以將風險降至最低,但網路小組擔心 SCEP 伺服器的負載和連線中斷。建議的平衡方案是什麼?

提示:考慮公共網頁憑證與內部受管理 PKI 之間的差異。

查看標準答案

365 天的有效期,並在到期前 60 或 90 天觸發自動更新,可提供最佳平衡。如果裝置在短暫的更新窗口期內處於離線狀態,30 天有效期的 WiFi 憑證會帶來過高的營運風險。安全性應透過強大、即時的 OCSP 撤銷來維護,而不是採用極短的有效期。