企业级 SCEP 设置指南：适用于高等教育与大型网络且基于证书的 Wi-Fi 身份验证

企业级 SCEP 设置指南：适用于高等教育与大型网络且基于证书的 WiFi 身份验证 Purple 技术简报 - 播客脚本（约 10 分钟） --- 介绍与背景 - 约 1 分钟 欢迎收听 Purple 技术简报系列。今天我要探讨一个经常出现在许多 IT 收件箱中但很少得到直接解答的话题：如何在大规模网络中（无论是大学校园、多站点酒店集团还是大型公共部门资产）使用 SCEP 实际部署基于证书的 WiFi 身份验证？ 我们将全面介绍。包括 SCEP 的实际作用、它如何融入 802.1X 架构、大多数团队都会搞错的部署顺序、两个真实的实施场景，以及如果您不提前规划，将会耗费您整个周末时间的陷阱。 这是一份顾问简报，而不是教程。我假设您知道什么是 RADIUS 服务器，并且您可能已经决定需要放弃预共享密钥。您现在需要的是实施路线图。 让我们开始吧。 --- 技术深挖 - 约 5 分钟 首先，基本原理。SCEP 代表简单证书注册协议。它于 2020 年被 IETF 正式确立为 RFC 8894，尽管在此之前它已经在企业中广泛使用了十多年。它的工作很简单：自动将数字证书获取到托管设备上，而无需人工干预每台机器。 在 WiFi 身份验证的背景下，SCEP 是传输机制。您所针对的实际身份验证协议是 EAP-TLS（带有传输层安全的可扩展身份验证协议），它位于 802.1X 框架内。EAP-TLS 被广泛认为是企业无线网络最安全的身份验证方法，因为它要求客户端设备和 RADIUS 服务器都出示有效的证书。在没有密码学证明的情况下，双方互不信任。这种双向身份验证可以保护您免受“邪恶双胞胎”攻击（即攻击者建立流氓接入点来收集凭据）。 以下是完整链条的工作原理。托管设备（例如学生笔记本电脑、员工手机、酒店销售点终端）需要加入企业无线网络。您的 MDM 平台（可能是 Microsoft Intune 或 Jamf）向该设备推送 SCEP 负载。该负载包含两样东西：指向您的 NDES 服务器或云 SCEP 网关的 SCEP URL，以及挑战密码或共享密钥。设备在本地生成自己的公钥和私钥对。这至关重要。私钥永远不会离开设备。它在设备上生成，存储在安全飞地或 TPM 中，并且永远不会在网络上传输。设备然后创建一个证书签名请求 (CSR) 并将其发送到 SCEP 网关。网关验证挑战，将 CSR 转发给您的证书颁发机构 (CA)，CA 对其进行签名并将公用证书返回给设备。从那时起，当设备连接到您的 WiFi SSID 时，它会将该证书出示给 RADIUS 服务器。RADIUS 服务器根据您的 CA 信任链验证证书，检查证书吊销列表以确认证书未被吊销，如果一切正常，则向接入点发送接受消息。设备便连接到了网络。整个过程对用户是不可见的。 现在，让我们谈谈 SCEP 相对于另一种选择（即 PKCS）所处的位置。PKCS（公钥加密标准）是 Intune 等平台支持的另一种证书交付方法。使用 PKCS，CA 在集中端生成公钥和私钥，然后证书连接器将密钥对推送到设备。这意味着私钥在网络上传输，这引入了理论上的攻击面。PKCS 适用于诸如 S/MIME 电子邮件加密等实际上需要密钥托管的用例。对于 WiFi 身份验证，SCEP 是正确的选择。私钥保留在设备上，仅此而已。 现在是硬件层。SCEP 和 EAP-TLS 是与厂商无关的标准，这意味着它们适用于 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 接入点。您的 RADIUS 配置（无论是 Windows NPS、FreeRADIUS 还是云 RADIUS 服务）是您定义证书验证策略的地方，而且至关重要的是，也是您配置动态 VLAN 分配的地方。动态 VLAN 是您按身份对网络进行分段的方式。学生设备分配到 VLAN 20（仅限互联网访问）。教职工设备分配到 VLAN 10（访问内部研究系统）。设施管理设备分配到 VLAN 30（访问建筑管理系统）。所有这些都由证书属性和 RADIUS 策略驱动，无需对每台设备进行人工干预。 对于身份提供商集成，SCEP 证书属性（特别是使用者替代名称）可以携带来自 Microsoft Entra ID、Okta 或 Google Workspace 的用户主体名称。这会将证书绑定到特定身份，这意味着当您在 Entra ID 中禁用帐户且 MDM 注销设备时，证书会被吊销，WiFi 访问权限也会自动切断。这是预共享密钥根本无法实现的吊销机制。 --- 实施建议与陷阱 - 约 2 分钟 好的，让我们谈谈部署顺序，因为这是大多数团队容易出错的地方。 该顺序是不可妥协的：首先是受信任根证书，其次是 SCEP 证书配置文件，第三是 WiFi 配置文件。Intune 和 Jamf 都强制执行配置文件依赖关系。如果您的 WiFi 配置文件引用了尚未部署到设备的 SCEP 证书，则 WiFi 配置文件将失败，并显示一个看似配置错误但实际上只是时间问题的隐晦错误。 第二个陷阱是组定位。所有三个配置文件（受信任根、SCEP 和 WiFi）必须部署到完全相同的 Azure AD 或 Jamf 组。如果 SCEP 配置文件针对用户组，而 WiFi 配置文件针对设备组，则 Intune 无法解析依赖关系，WiFi 配置文件将显示为“不适用”。这经常让团队防不胜防。 第三：NDES 服务器的可访问性。您的 NDES 服务器需要能够从互联网访问，以便设备在到达现场之前进行注册。正确的方法是通过 Azure AD 应用代理，而不是在防火墙上打孔。应用代理为您提供无需入站端口的安全远程访问，并允许您将条件访问策略应用于注册流程。 第四：CRL 可用性。您的 RADIUS 服务器在每次设备进行身份验证时都会检查证书吊销列表。如果您的 CRL 分发点不可用（因为服务器宕机或 URL 已更改），网络上所有设备的身份验证将同时失败。这将导致全校范围的网络中断。确保您的 CRL 端点高度可用，并在上线前测试吊销功能。 对于大型网络（任何超过 500 台设备的网络），请考虑使用云 SCEP 网关，而不是本地 NDES。云网关消除了 NDES 单点故障，可水平扩展，并且通常直接与云 RADIUS 服务集成，从而消除了另一个基础设施依赖项。 --- 快速问答 - 约 1 分钟 SCEP 能否处理未在 MDM 中注册的 BYOD 设备？不能直接处理。SCEP 需要 MDM 注册才能推送证书负载。对于未托管的 BYOD，您需要采用不同的方法——要么使用自我服务引导门户，要么使用带有身份验证的 Captive Portal 的独立 SSID。Purple 的平台可以干净地处理该访客和 BYOD 层，与您基于证书进行身份验证的员工网络并存。 iOS 和 Android 呢？这两个平台都原生支持 SCEP。iOS 自 iOS 4 起就支持 SCEP。Android Enterprise 通过 Intune 和其他 MDM 支持 SCEP。每个平台的配置略有不同，但底层协议是完全相同的。 EAP-TLS 是否适用于 WPA3？是的。WPA3-Enterprise 强制要求在敏感环境中使用 192 位安全模式，并且 EAP-TLS 完全兼容。事实上，带有 EAP-TLS 的 WPA3-Enterprise 是 Wi-Fi 联盟针对政府和金融网络推荐的组合。 --- 总结与后续步骤 - 约 1 分钟 总结一下。对于任何拥有超过 50 台托管设备的网络，基于 SCEP 证书的 WiFi 身份验证都是正确的架构。它消除了共享凭据，为您提供每台设备的身份，实现动态 VLAN 分段，并直接与您的身份提供商集成以实现自动吊销。部署顺序（受信任根，然后是 SCEP 配置文件，最后是 WiFi 配置文件）是固定的。组定位必须保持一致。CRL 可用性是必不可少的。 特别是对于高等教育，将适用于教职工设备的 SCEP 与适用于学生个人设备的独立访客 WiFi 层相结合，既能保证安全性，又能提供绝佳的用户体验，两全其美。 如果您想深入了解，Purple 关于在没有 Active Directory 或本地服务器的情况下进行企业 WiFi 身份验证的指南涵盖了云原生路径。如果您正在考虑员工离职时会发生什么，我们关于吊销 WiFi 访问权限的指南将带您了解完整的吊销工作流程。 感谢您的收听。我是来自 Purple 技术团队的成员，我们下期简报再见。 --- 脚本结束