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

您好，欢迎收看来自 Purple 的本次技术简报。我是您的主持人，今天我们将深入探讨 SCEP（简单证书注册协议）的细节，以及如何正确配置它以实现安全的 BYOD 和 802.1X 网络身份验证。 如果您是负责酒店集团、零售物业、体育场馆或公共部门组织 WiFi 基础设施的 IT 经理、网络架构师或 CTO，这与您息息相关。今天我们不讲理论，而是专注于架构和决策。 让我们开始吧。 [第 1 部分：引言与背景 - 约 1 分钟] 这就是您可能面临的问题。您的员工设备、承包商笔记本电脑和个人手机都需要访问网络。您的设备中可能既有托管设备，也有非托管设备。在您的基础设施中的某个地方，仍然有一个共享的 WPA2 预共享密钥，有 12 个人知道，其中 3 个人在去年已经离职。 这不是一种安全姿态，而是一个隐患。 解决方案是 802.1X - IEEE 基于端口的网络访问控制标准。它确保在通过明确的身份验证之前，没有任何设备可以传输流量。但 802.1X 只是一个框架。真正的问题是其中运行什么身份验证方法。对于大规模的 BYOD，答案是使用通过 SCEP 调配的证书进行 EAP-TLS 身份验证。 这就是我们今天要做的工作。 [第 2 部分：技术深入探讨 - 约 5 分钟] 让我们先从 SCEP 的实际作用开始。 SCEP - 简单证书注册协议 - 最初由 VeriSign 创建，于 1999 年作为 IETF 的 Internet 草案发布。它被正式确定为 RFC 8894。其工作很简单：在大规模情况下，自动向设备颁发 X.509 数字证书，而无需人工手动生成和安装每个证书。 以下是这四个步骤的流程。 第一步：设备连接到 SCEP 端点 - 一个通过名为 NDES（网络设备注册服务）的 Windows Server 角色在本地托管，或者通过云 PKI 提供商托管的 URL。该 URL 是通往证书颁发机构的网关。 第二步：设备提交一个 SCEP 质询 - 一个证明其有权请求证书的共享密钥。在 Microsoft Intune 等 MDM 托管的环境中，这种质询是动态且针对每个设备唯一提供的，这比在所有设备之间共享静态密码要安全得多。 第三步：设备在本地生成自己的私钥和公钥对。它使用公钥创建证书签名请求 (CSR)，并将其发送到 SCEP 服务器。这是关键的安全点：私钥永远不会离开设备。它是在本地生成、存储在设备的安全模块中（即 Windows 上的 TPM 或 iOS 上的 Secure Enclave），并且绝不会被传输。这就是为什么 SCEP 是网络身份验证的正确选择，而不是 PKCS，因为在 PKCS 中，CA 集中生成密钥并必须将其推送到设备上。 第四步：证书颁发机构（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 Entra ID 中的部署顺序，因为这是我们在企业环境中见到的最常见的 MDM 平台。 您需要严格按照顺序部署三个 Intune 配置配置文件。第一，受信任的根证书配置文件 - 这会将您的根 CA 证书推送到每台设备，以便它们信任您的 PKI。第二，SCEP 证书配置文件 - 这会告诉设备 SCEP URL、使用者名称格式、密钥用途以及用于客户端认证的扩展密钥用途。用于客户端认证的 OID 为 1.3.6.1.5.5.7.3.2。第三，WiFi 配置文件 - 这会指定 SSID，将安全类型设置为 WPA2 企业级或 WPA3 企业级，将 EAP 类型设置为 EAP-TLS，并链接到 SCEP 证书配置文件。 顺序至关重要。WiFi 配置文件依赖于 SCEP 配置文件，而 SCEP 配置文件又依赖于受信任根配置文件。如果部署顺序混乱，您将会遇到错误。 您需要做出的一个架构决策是把 NDES 服务器托管在哪里。它需要能够从互联网访问，以便设备在到达现场之前进行注册。安全的做法是通过 Microsoft Entra ID Application Proxy 发布 NDES URL。这可以避免打开入站防火墙端口，并允许您将条件访问策略应用于注册流程。 对于希望完全消除本地基础设施的组织，云 PKI 提供商 - 微软在 Intune 中自带的云 PKI 或第三方方案 - 可以完全消除对 NDES 的依赖。 [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] 让我向您介绍我们最常见的三种故障模式。 故障模式一：组目标不匹配。这是 Intune 中 WiFi 配置文件部署失败最常见的原因。如果您的受信任根配置文件分配给用户组，您的 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。它强制执行受保护的管理帧，从而阻止去身份验证攻击。来自 Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 的所有硬件都支持它。 问题：对于无法支持 802.1X 的设备（例如 IoT 传感器或旧式打印机）该怎么办？使用 MAC 身份验证绕过作为后备方案，但将这些设备放置在高度受限且无法访问企业资源的 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 配置文件，全部针对相同的组。通过应用代理发布 NDES 或迁移到云 PKI。在您的 RADIUS 服务器上强制执行 CRL 或 OCSP 检查。并始终在客户端请求者上配置服务器证书验证。 如果您仍在使用共享预共享密钥作为员工 WiFi，这就是本季度需要做出的改变。证书基础设施的前期工作较多，但它消除了一整类基于凭据的攻击，并且在部署后通常能减少 70% 至 80% 的 WiFi 相关服务台工单。 如需完整的技术指南、架构图和实用示例，请访问 purple.ai。感谢您的收听。