如何配置 SCEP 以实现安全的 BYOD 和 802.1X 网络身份验证

您好，欢迎观看 Purple 的本次技术简报。我是您的主持人，今天我们将深入探讨 SCEP（简单证书注册协议）的细节，以及如何正确配置它以实现安全的 BYOD 和 802.1X 网络身份验证。 如果您是负责酒店集团、零售物业、体育场馆或公共部门组织内 WiFi 基础设施的 IT 经理、网络架构师或 CTO，那么本期内容与您切身相关。今天我们不讲理论，我们只谈架构和决策。 让我们开始吧。 [SECTION: Introduction and Context - approximately 1 minute] 您可能正面临这样的问题：员工设备、承包商笔记本电脑和个人手机都需要访问网络。您的基础设施中可能混合了托管设备和非托管设备。而且在您的基础设施的某个角落，仍然使用着一个共享的 WPA2 预共享密钥，有 12 个人知道这个密钥，其中 3 个人去年就已经离职了。 这不叫安全态势。这叫安全隐患。 解决方案是 802.1X——用于基于端口的网络访问控制的 IEEE 标准。它确保在设备通过显式身份验证之前不会传输任何流量。但 802.1X 仅仅是一个框架。真正的问题是它内部采用什么身份验证方法。对于大规模的 BYOD 而言，答案是结合通过 SCEP 调度的证书来使用 EAP-TLS。 这就是我们今天要去剖析的内容。 [SECTION: Technical Deep-Dive - approximately 5 minutes] 让我们先从 SCEP 的实际作用说起。 SCEP（Simple Certificate Enrollment Protocol，简单证书注册协议）最初由 VeriSign 创建，并于 1999 年由 IETF 作为互联网草案发布。后来它被正式确立为 RFC 8894。它的任务非常直接：在大规模场景下，自动向设备颁发 X.509 数字证书，而无需人工手动生成和安装每一个证书。 以下是它的四个步骤流程。 第一步：设备连接到 SCEP 端点——这是一个托管在本地（通过名为 NDES，即网络设备注册服务的 Windows Server 角色）或通过云 PKI 提供商托管的 URL。这个 URL 就是通往您的证书颁发机构（CA）的门户。 第二步：设备提交一个 SCEP 挑战（Challenge）——一个用于证明其有权请求证书的共享密钥。在像 Microsoft Intune 这样的 MDM 托管环境中，这个挑战是动态生成的，且每个设备都是唯一的，这比在所有设备上共享静态密码要安全得多。 第三步：设备在本地生成自己的私钥和公钥对。它使用公钥创建证书签名请求（CSR）并发送给 SCEP 服务器。这里有一个关键的安全点：私钥永远不会离开设备。它在本地生成，存储在设备的安全区域中（即 Windows 上的 TPM 或 iOS 上的 Secure Enclave），并且绝不进行传输。这就是为什么对于网络身份验证而言，SCEP 是正确的选择，而不是 PKCS，因为在 PKCS 中，CA 是集中生成密钥并必须将其推送到设备上的。 第四步：证书颁发机构验证 CSR，使用 CA 的私钥对其进行签名，并将签名后的 X.509 证书返回给设备。此时，该设备就拥有了唯一的加密身份。 那么，该证书是如何用于 802.1X 认证的呢？ 当设备连接到您的 WiFi SSID 时，接入点（无论是 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist 还是 Ubiquiti UniFi）将充当认证器。它本身并不做出认证决策，而是将 EAP 交互转发给您的 RADIUS 服务器。该服务器可以是 Microsoft NPS、Cisco ISE 或 Aruba ClearPass。 RADIUS 服务器启动 EAP-TLS 握手。设备出示其通过 SCEP 配置的客户端证书。RADIUS 服务器会验证三件事：指向受信任根 CA 的证书链、证书到期日期，以及证书是否已被吊销——通过证书吊销列表（CRL）或通过在线证书状态协议（OCSP）进行检查。 如果这三项检查均通过，RADIUS 服务器将发送 EAP-Success 消息，接入点随即打开端口。设备便成功接入网络。 这就是双向认证。设备同样会验证 RADIUS 服务器的证书。如果有人设置了流氓接入点，设备将拒绝连接，因为该服务器证书无法通过受信任 CA 的验证。这就是您防御双面恶魔（Evil Twin）攻击的保护机制。 现在我们来谈谈 Microsoft Intune 中的部署顺序，因为这是我们在企业环境中见到的最常见的 MDM 平台。 您需要严格按照顺序部署三个 Intune 配置配置文件。首先是“受信任的根证书”配置文件——这会将您的根 CA 证书推送到每台设备，以便它们信任您的 PKI。其次是“SCEP 证书”配置文件——这会告知设备 SCEP URL、使用者名称格式、密钥用法以及用于客户端认证的扩展密钥用法。用于客户端认证的 OID 为 1.3.6.1.5.5.7.3.2。第三是“WiFi”配置文件——这会指定 SSID，将安全类型设置为 WPA2-Enterprise 或 WPA3-Enterprise，将 EAP 类型设置为 EAP-TLS，并链接到 SCEP 证书配置文件。 顺序至关重要。WiFi 配置文件依赖于 SCEP 配置文件，而 SCEP 配置文件又依赖于受信任的根配置文件。如果部署顺序颠倒，您将会遇到错误。 您需要做出的一个架构决策是何处托管 NDES 服务器。它需要能从互联网访问，以便设备在到达现场之前进行注册。安全的实现方式是通过 Microsoft Entra ID Application Proxy 发布 NDES URL。这样可以避免打开入站防火墙端口，并允许您将条件访问策略应用于注册流程。 对于希望彻底消除本地基础设施的主办方，云 PKI 提供商（Microsoft 在 Intune 中自带的 Cloud PKI，或第三方方案）可以完全免除对 NDES 的依赖。 [SECTION: 实施建议与常见陷阱 - 约 2 分钟] 让我向您介绍我们最常遇到的三种故障模式。 故障模式一：组目标不匹配。这是 Intune 中 WiFi 配置文件部署失败最常见的原因。如果您的受信任根证书（Trusted Root）配置文件分配给了一个“用户”组，您的 SCEP 配置文件分配给了一个“设备”组，而您的 WiFi 配置文件分配给了另一个“用户”组，Intune 将无法解析依赖链。这三个配置文件必须指向完全相同的 Azure AD 组——要么全部是“用户”组，要么全部是“设备”组。选择其中一个并保持一致。 故障模式二：CRL 可用性。您的 RADIUS 服务器会检查 CRL 以验证证书是否已被吊销。如果 CRL 分发点（即证书中嵌入的 CDP URL）无法访问，所有设备的身份验证都会失败。这是网络变更后导致大规模断网的常见原因。请确保您的 CDP 具有高可用性，最好同时发布到内部 URL 和针对远程设备的外部 URL。考虑将 OCSP 作为比 CRL 检查更具弹性的替代方案。 故障模式三：未在客户端上强制执行服务器证书验证。这是 802.1X 部署中影响最大的单项配置错误。如果通过 MDM 部署的 WiFi 配置文件没有指定受信任的 CA 和期望的 RADIUS 服务器名称，设备将连接到任何呈现任何证书的服务器。这就失去了 EAP-TLS 的全部意义。务必在您的 WiFi 配置文件中配置服务器验证。 [SECTION: 快速问答 - 约 1 分钟] 我们来进行几个快速问答。 问：我们需要 WPA3 吗？是的。请迁移到 WPA3-Enterprise。它强制执行受保护的管理帧（PMF），从而阻止去身份验证攻击。来自 Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 的所有硬件都支持它。 问：那些不支持 802.1X 的设备（如 IoT 传感器或老式打印机）该怎么办？使用 MAC 地址认证绕过（MAB）作为备用方案，但要将这些设备放入受到严格限制、无法访问企业资源的 VLAN 中。 问：Purple 在其中扮演什么角色？Purple 的 Guest WiFi 平台处理访客和来宾访问层——包括 Captive Portal、数据捕获和分析。您的 802.1X 和 SCEP 基础设施则处理员工和受管设备的访问。它们运行在不同的 SSID 和不同的 VLAN 上。Purple 与 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 无缝集成——因此您的硬件投资可以得到保障。 [SECTION: 总结与后续步骤 - 约 1 分钟] 总结一下。 SCEP 实现了大规模证书自动颁发。私钥保留在设备上——这就是相比于 PKCS 的安全优势。通过 MDM 严格按以下顺序部署：受信任的根证书、SCEP 配置文件、WiFi 配置文件，且全部指向同一个组。通过应用程序代理（Application Proxy）发布 NDES，或迁移到云端 PKI。在您的 RADIUS 服务器上强制执行 CRL 或 OCSP 检查。并且务必在客户端请求方上配置服务器证书验证。 如果您仍在使用共享预共享密钥作为员工 WiFi，这就是本季度需要做出的改变。证书基础设施的前期工作量较大，但它能消除整整一类基于凭证的攻击，且一旦部署，通常能减少 70% 至 80% 的 WiFi 相关服务台工单。 如需获取完整技术指南、架构图和实践案例，请访问 purple dot ai。感谢收听。