企业级 SCEP 指南：部署简单证书注册协议以实现自动化园区 WiFi 安全

早上好。如果您正在管理酒店集团、零售物业、体育场馆或大学校园的 WiFi 基础设施，那么本次简报非常适合您。我们将探讨 SCEP（简单证书注册协议），特别是它如何解决企业 WiFi 中最顽固的难题之一：自动将证书分发到数千台设备上，而不会让您的技术支持部门淹没在工单中。 [short pause] 让我来分析一下背景。您已经（正确地）做出了决定，即预共享密钥对于员工 WiFi 来说不再安全。单个密码泄露就会使您的整个网络段暴露。您已经或正在转向 802.1X 认证。这是 IEEE 标准，要求每台设备在获取网络访问权限之前证明其身份。802.1X 最安全的一种形式是 EAP-TLS（使用传输层安全协议的可扩展身份验证协议），它使用数字证书而不是密码。每个设备的证书在密码学上都是唯一的，无法共享，并且如果设备丢失或员工离职，可以立即撤销。 [short pause] 到目前为止，一切顺利。问题在于分发。您如何将唯一的证书安装到您资产中的每台笔记本电脑、每部手机和每台平板电脑上（涵盖 Windows、iOS、Android 和 macOS），而无需技术人员逐一操作设备？这正是 SCEP 所解决的痛点。 [medium pause] SCEP 由互联网工程任务组在 2020 年的 RFC 8894 中正式确立，尽管自 21 世纪初以来它就已在企业环境中使用。该协议允许托管设备使用预先配置的 URL 和质询密码，直接向您的证书颁发机构申请其自身的证书。这里最关键的安全点是：私钥是在设备本身上生成的，存储在设备的安全领地中（即 Windows 设备上的 TPM 芯片或 Apple 硬件上的 Secure Enclave），并且它绝不会在网络上传输。设备会生成一个证书签名请求并发送给 SCEP 网关，网关验证该质询，将请求转发给您的证书颁发机构，证书颁发机构对其进行签名，然后将已签名的证书返回给设备。整个过程对最终用户是完全无感的。 [short pause] 现在，在 Microsoft 环境中，SCEP 网关通常是 NDES（网络设备注册服务），这是一个 Windows Server 角色，充当您的 MDM 平台与您的证书颁发机构之间的中介。Microsoft Intune 将 SCEP 配置配置文件推送到托管设备，告诉它们 NDES URL 和质询密码。设备会自动完成剩下的工作。 [medium pause] 让我为您详细介绍一个真实的部署案例。以一家拥有 150 家分店的酒店集团为例（类似于 Premier Inn 的规模）。他们的前台员工使用 Windows 笔记本电脑，客房主管使用 iOS 设备，餐厅收银点（POS）则使用 Android 平平板电脑。在引入 SCEP 之前，他们运行的是 WPA2-Personal 模式，并使用每季度轮换一次的共享密码。每次密码轮换都会引发大量的服务台求助电话。通过结合使用 SCEP 和 Intune，他们按顺序部署了三个配置文件。首先是“受信任的根证书”配置文件（Trusted Root Certificate profile），这让每台设备都信任公司的证书颁发机构（CA）。其次是“SCEP 证书”配置文件（SCEP Certificate profile），这会指示设备去获取其唯一的客户端证书。第三是“WiFi 配置文件”，用于配置 SSID，将安全类型设置为 WPA2-Enterprise 或 WPA3-Enterprise，并指向用于身份验证的 SCEP 证书。将这三个配置文件部署到 Intune 中的同一个设备组后，每台受管设备都会自动连接到企业 SSID，拥有唯一的证书，且无需任何用户交互。 [short pause] RADIUS 服务器（通常是 Microsoft NPS 或云 RADIUS 服务）接收到 EAP-TLS 身份验证请求，向 CA 验证该证书，检查证书吊销列表，然后授予或拒绝访问权限。如果员工离职，您只需在 CA 中吊销其证书。他们的设备在下一次身份验证周期时就会失去 WiFi 访问权限。无需重置密码，也无需等待季度密码轮换。 [medium pause] 现在，人们经常会问起 SCEP 和 PKCS（公钥加密标准）之间的区别。两者都可以与 Intune 配合工作。关键的区别在于私钥生成的位置。使用 SCEP 时，私钥是在设备本地生成的。而使用 PKCS 时，CA 会在中央生成这两个密钥，并将私钥推送到设备上。这意味着私钥需要在网络上进行传输，从而带来了理论上的拦截风险。PKCS 有其适用场景 - 它更适合需要密钥托管的 S/MIME 邮件加密。而对于 WiFi 身份验证，SCEP 始终是正确的选择。每一次都是如此。 [short pause] 让我给您举第二个场景的例子 - 零售物业。想象一家在全英拥有 200 家门店的时尚零售商，每家门店都运行着 Cisco Meraki 接入点。他们的收银系统基于 Windows 系统，并通过 Intune 进行管理。他们需要满足 PCI-DSS 合规性要求，这意味着对任何处理持卡人数据的设备都需要进行网络隔离和强身份验证。基于 SCEP 的 EAP-TLS 为他们在员工 SSID 上提供了设备级的身份验证，并通过 RADIUS 策略驱动 VLAN 分配。POS 终端会自动落入 PCI 范围内的 VLAN。而访客 WiFi 则通过像 Purple 这样的平台进行独立处理，运行在完全隔离的 SSID 上，并拥有自己的身份验证流程。这两个网络互不干扰。审计人员很满意，安全团队也能睡个安稳觉。 [medium pause] 好，接下来让我们聊聊那些容易让人踩坑的陷阱，因为确实有几个常见问题会让团队措手不及。 [short pause] 最常见的故障模式是 Intune 中的组目标不匹配。您的受信任根配置文件、SCEP 配置文件和 WiFi 配置文件必须都指向同一个 Azure AD 组。如果 SCEP 配置文件指向用户组，而 WiFi 配置文件指向设备组，Intune 则无法解析依赖关系，WiFi 配置文件会显示错误。请先检查您的分配 - 这几乎总是罪魁祸首。 [short pause] 第二个陷阱：NDES 服务器可用性。您的 NDES 服务器需要能够从互联网访问，以便远程设备在到达现场之前进行注册。实现此目的的安全方式是通过 Azure AD 应用程序代理，它可以在不打开入站防火墙端口的情况下为您提供远程访问。切勿将 NDES 直接暴露给互联网。 [short pause] 第三：CRL 可用性。您的 RADIUS 服务器在每次设备身份验证时都会检查证书撤销列表。如果 CRL 分发点无法访问 - 可能是服务器宕机，或者防火墙规则发生了变化 - 所有人都会身份验证失败。请确保您的 CRL 端点具有高可用性，并定期进行测试。 [short pause] 第四：证书模板权限。如果您的 NDES 连接器服务帐户在证书模板上没有读取和注册权限，设备在尝试获取其证书时会遇到 HTTP 403 错误。这是一个简单的权限修复，但在初始设置中很容易被忽略。 [medium pause] 现在进入快速问答环节。 [short pause] SCEP 能否与非微软 MDM 协同工作？是的 - 适用于 Apple 设备群的 Jamf、VMware Workspace ONE 以及大多数企业级 MDM 平台都支持 SCEP 配置文件。该协议是厂商中立的。 [short pause] SCEP 能否与云 PKI 协同工作？是的。Intune Suite 中微软自己的云 PKI 完全消除了对本地 NDES 服务器的需求。SecureW2 和 Keyfactor 等第三方云 PKI 提供商也提供云 SCEP 端点。 [short pause] WPA3-Enterprise 呢？WPA3-Enterprise 使用相同的 802.1X 和 EAP-TLS 身份验证堆栈。SCEP 颁发的证书工作原理完全相同。升级是在无线协议层，而不是证书层。 [short pause] 证书的有效期有多长？通常为一年，但您可以配置更短的有效期。Intune 会在过期前处理自动更新，因此用户永远不会遇到中断。 [medium pause] 总结一下。SCEP 实现了大规模证书分发的自动化，消除了在大型设备群中部署 PKI 的手动开销。私钥保留在设备上 - 这是 EAP-TLS 的安全基石。请按顺序部署：首先是受信任根，其次是 SCEP 配置文件，第三是 WiFi 配置文件，且全部指向同一个组。通过应用程序代理安全地发布您的 NDES 端点。保持您的 CRL 端点高可用。如果您是刚开始构建，请评估云 PKI 以完全消除对本地 NDES 的依赖。 [short pause] 对于访客 WiFi（面向访客的独立网络），基于证书的身份验证并不是合适的模式。访客拥有的并不是受管理设备。这正是 Purple 平台发挥作用的地方，它负责处理身份验证流程：Captive Portal、社交媒体登录、电子邮件捕获或短信验证，所有这些都将接入您的营销团队可以实际使用的第一方数据层。这两种方法相辅相成：对受管理的员工设备使用 SCEP，对您的访客网络使用 Purple。两者运行在相同的硬件上，通过 VLAN 进行干净的隔离。 [稍作停顿] 以上就是关于 SCEP 企业级 WiFi 准入配置的简要介绍。完整的书面指南（包含架构图、分步 Intune 配置和实际示例）已在 Purple 官方网站发布。感谢您的收听。