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 中正式确立，尽管自 2000 年代初以来它就已在企业环境中使用。它是一种允许托管设备使用预先配置的 URL 和质询密码，直接向您的证书颁发机构请求其自身证书的协议。这里关键的安全点在于：私钥是在设备本身上生成的，存储在设备的安全区域中（即 Windows 设备上的 TPM 芯片，或 Apple 硬件上的 Secure Enclave），并且它绝不会在网络上传输。设备生成证书签名请求，将其发送到 SCEP 网关，网关验证质询，将请求转发给您的证书颁发机构，CA 对其进行签名，然后签名后的证书返回到设备。整个过程对最终用户是不可见的。 [short pause] 现在，在 Microsoft 环境中，SCEP 网关通常是 NDES（网络设备注册服务），这是一个 Windows Server 角色，充当您的 MDM 平台和 CA 之间的中介。Microsoft Intune 将 SCEP 配置文件推送到托管设备，告知它们 NDES URL 和质询密码。设备会自动完成其余操作。 [medium pause] 让我为您详细介绍一下实际部署的流程。以一家拥有 150 家分店的酒店集团为例——想象一下 Premier Inn 的规模。他们混合使用了供前台员工使用的 Windows 笔记本电脑、供客房主管使用的 iOS 设备以及餐厅收银台（POS）的 Android 平板电脑。在引入 SCEP 之前，他们运行的是 WPA2-Personal，使用每季度更换一次的共享密码。每次密码更换都会引发大量的服务台求助电话。通过 SCEP 和 Intune，他们依次部署了三个配置文件。首先是“受信任的根证书”配置文件——这会告知每台设备信任公司的证书颁发机构（CA）。其次是“SCEP 证书”配置文件——这会指示设备去获取其唯一的客户端证书。第三是“WiFi”配置文件——这会配置 SSID，将安全类型设置为 WPA2-Enterprise 或 WPA3-Enterprise，并指向用于身份验证的 SCEP 证书。将这三个配置文件部署到 Intune 中的同一个设备组，每台受管设备就会自动连接到企业 SSID，并使用唯一的证书，无需任何用户交互。 [short pause] RADIUS 服务器（通常是 Microsoft NPS 或云 RADIUS 服务）接收 EAP-TLS 身份验证请求，对照 CA 验证证书，检查证书吊销列表（CRL），然后批准或拒绝访问。如果员工离职，您只需在 CA 中吊销其证书。他们的设备在下一次身份验证周期时就会失去 WiFi 访问权限。无需重置密码，也无需等待每季度的密码轮换。 [medium pause] 现在，人们经常会问起 SCEP 和 PKCS（公钥加密标准）之间的区别。两者都可以与 Intune 配合使用。关键区别在于私钥是在哪里生成的。使用 SCEP，私钥是在设备上生成的。而使用 PKCS，CA 会在集中端生成这两个密钥，并将私钥推送到设备上。这意味着私钥会在网络上传输，从而引入了理论上的拦截风险。PKCS 有其适用场景——它更适合需要密钥托管的 S/MIME 邮件加密。而对于 WiFi 身份验证，SCEP 每次都是最正确的选择。 [short pause] 让我给您举第二个场景——零售物业。想象一家在英国拥有 200 家门店的时尚零售商，每家门店都运行着 Cisco Meraki 接入点。他们的收银系统（POS）基于 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 Application Proxy，它可以在不打开入站防火墙端口的情况下为您提供远程访问。切勿将 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 配置文件，且全部定位到同一个组。通过 Application Proxy 安全地发布您的 NDES 端点。保持您的 CRL 端点高可用。如果您是全新开始，请评估云 PKI 以完全消除对本地 NDES 的依赖。 [short pause] 对于宾客 WiFi（面向访客的独立网络）而言，基于证书的身份验证并不是合适的模式。访客并没有受管理的设备。这正是像 Purple 这样的平台发挥作用的地方，它负责处理身份验证流程：Captive Portal、社交媒体登录、电子邮件捕获或短信验证，所有这些都会汇入营销团队可以实际使用的第一方数据层。这两种方法相辅相成：SCEP 用于您受管理的员工设备，Purple 用于您的宾客网络。两者运行在相同的硬件上，通过 VLAN 进行干净的隔离。 [短暂顿挫] 以上就是关于 SCEP 企业级 WiFi 准入的简报。包含架构图、分步 Intune 配置以及实际案例的完整书面指南，已在 Purple 网站上提供。感谢收听。