通过 SCEP 和 PKCS 的 Microsoft Intune WiFi 证书部署

执行摘要

对于企业场所——无论是繁忙的 酒店业 环境、多站点的 零售 运营，还是现代化的企业园区——依赖预共享密钥或基本的 Captive Portal 为员工 WiFi 提供服务会带来安全漏洞和运营瓶颈。现代网络架构要求使用 EAP-TLS 的 802.1X 身份验证，确保每台设备在访问网络之前都经过加密验证。

然而，挑战在于分发：如何在不使帮助台被大量的支持工单淹没的情况下，将唯一的客户端证书部署到数千台 Windows、iOS 和 Android 设备上？Microsoft Intune 通过自动化的证书生命周期管理解决了这个问题。通过利用 SCEP（简单证书注册协议）或 PKCS（公钥密码学标准）证书配置文件，IT 团队可以将受信任的根证书和客户端证书静默推送到受管理的终端设备上。

本指南为 Intune WiFi 证书部署提供了明确的架构蓝图和逐步实施策略。我们将探讨 SCEP 和 PKCS 之间的关键区别，详细说明成功部署所需的确切部署顺序，并概述实际的风险缓解策略，以确保您的 访客 WiFi 和企业网络保持安全和高性能。

收听配套的播客简报：

技术深入探讨：SCEP 与 PKCS

在设计您的 Intune WiFi 证书部署策略时，首要的架构决策是选择证书交付机制。Intune 同时支持 SCEP 和 PKCS，但它们的运行方式有着根本的不同。

SCEP（简单证书注册协议）

SCEP 是企业设备注册的行业标准。在 SCEP 工作流程中，Intune 服务指示终端设备生成自己的私钥/公钥对。然后，设备创建证书签名请求（CSR），并通过网络设备注册服务（NDES）服务器将其发送到您的证书颁发机构（CA）。CA 对请求进行签名，并将公共证书返回给设备。

SCEP 的关键安全优势在于私钥永远不会离开设备。它是在本地生成的，存储在设备的安全区域中（例如 Windows 上的 TPM 或 iOS 上的安全隔区），并且永远不会通过网络传输。这使得 SCEP 成为 802.1X 身份验证的强烈推荐方法。

PKCS（公钥密码学标准）

相反，使用 PKCS 时，证书颁发机构会集中生成公钥和私钥。然后，Microsoft Intune Certificate Connector 安全地导出此密钥对，并将其推送到目标设备。

虽然 PKCS 消除了部署和维护 NDES 服务器的需要——简化了基础设施占用——但它引入了理论上的安全风险，因为私钥通过网络传输。PKCS 通常更适合需要密钥托管的用例，例如 S/MIME 电子邮件加密，而不是网络身份验证。

实施指南：部署顺序

成功为 802.1X 配置 Intune WiFi 配置文件需要严格遵循特定的部署顺序。Intune 配置文件依赖性要求必须先建立信任，然后才能配置身份验证。

步骤 1：部署受信任的根证书配置文件

在任何设备可以请求客户端证书或信任您的 RADIUS 服务器之前，它必须信任颁发证书的证书颁发机构。

1. 将您的根 CA 证书（以及任何中间 CA 证书）导出为 .cer 文件。
2. 在 Microsoft Endpoint Manager 管理中心，导航到设备 > 配置文件 > 创建配置文件。
3. 选择目标平台（例如 Windows 10 及更高版本），并选择受信任的证书配置文件类型。
4. 上传 .cer 文件并将此配置文件部署到您的目标设备组。

经验法则：在所有相关配置文件中始终使用相同的组（用户或设备），以防止部署不匹配。

步骤 2：配置 SCEP 证书配置文件

一旦信任建立，配置 SCEP 配置文件以指示设备如何获取其客户端证书。

1. 创建一个新的配置文件，并选择 SCEP 证书。
2. 配置使用者名称格式。对于用户驱动的身份验证，CN={{UserPrincipalName}} 是标准的。对于设备身份验证，使用 CN={{AAD_Device_ID}}。
3. 将密钥用法设置为 数字签名 和 密钥加密。
4. 在扩展密钥用法下，指定 客户端验证（OID: 1.3.6.1.5.5.7.3.2）。
5. 将此配置文件链接到步骤 1 中创建的受信任的根证书配置文件。
6. 提供 NDES 服务器的外部 URL。

步骤 3：部署 802.1X WiFi 配置文件

最后一步是推送将证书绑定到网络 SSID 的 WiFi 配置。

1. 创建一个 Wi-Fi 配置文件。
2. 输入网络名称（SSID），与您的 无线接入点 广播的完全相同。
3. 选择 WPA2-Enterprise 或 WPA3-Enterprise 作为安全类型。
4. 将 EAP 类型设置为 EAP-TLS。
5. 在身份验证设置中，选择在步骤 2 中创建的 SCEP 证书配置文件作为客户端身份验证证书。
6. 指定用于服务器验证的受信任的根证书，以确保设备仅连接到您合法的 RADIUS 服务器。

最佳实践与行业标准

在实施 Intune WiFi 证书部署时，请遵循以下供应商中立的最佳实践，以确保合规性和可靠性。

NDES 服务器放置和安全性

NDES 服务器必须可从互联网访问，以允许远程设备在到达现场之前预配证书。但是，将内部服务器直接暴露到互联网是一个重大的安全风险。

建议： 使用 Azure AD 应用程序代理发布 NDES URL。这提供了安全的远程访问，而无需打开入站防火墙端口，并允许您对注册流应用条件访问策略。

RADIUS 和 CRL 检查

证书部署只是安全等式的一半；吊销同样至关重要。如果员工被解雇，禁用其 Active Directory 账户可能不会立即吊销其 WiFi 访问权限，如果其客户端证书仍然有效且 RADIUS 服务器没有严格检查证书吊销列表 (CRL)。

建议： 配置您的网络策略服务器 (NPS) 或 RADIUS 服务器以强制进行严格的 CRL 检查。确保您的 CRL 分发点 (CDP) 具有高可用性；如果 RADIUS 服务器无法访问 CRL，身份验证将失败，导致大范围的中断。

有关安全网络设计的更多见解，请考虑查看 现代企业的核心 SD WAN 优势 。

故障排除与风险缓解

即使经过精心规划，证书部署也可能会遇到问题。以下是常见的故障模式和缓解策略。

问题：WiFi 配置文件无法应用

症状： 设备收到了受信任的根证书和 SCEP 证书，但 WiFi 配置文件在 Intune 中显示为“错误”或“不适用”。

根本原因： 这几乎总是由组目标定位不匹配引起的。如果 SCEP 配置文件分配给用户组，但 WiFi 配置文件分配给设备组，Intune 就无法解析依赖关系。

缓解措施： 审核您的分配。确保受信任的根证书、SCEP 和 WiFi 配置文件都部署到完全相同的 Azure AD 组。

问题：NDES 403 禁止错误

症状： 设备无法检索 SCEP 证书，并且 NDES IIS 日志显示 HTTP 403 错误。

根本原因： Intune Certificate Connector 服务帐户缺乏对证书模板的必要权限，或者防火墙上的 URL 筛选阻止了 SCEP 使用的特定查询字符串参数。

缓解措施： 确认连接器帐户具有 CA 模板的“读取”和“注册”权限。检查防火墙日志，确保包含 ?operation=GetCACaps 的 URL 未被阻止。

投资回报率与业务影响

过渡到 Microsoft Intune 802.1X 证书部署可在安全性和运营方面带来可衡量的回报。

1. 减少帮助台工单： 基于密码的 WiFi 会产生大量支持工单（密码过期、锁定、拼写错误）。基于证书的身份验证对用户是不可见的，通常可减少 70-80% 的 WiFi 相关帮助台工单量。
2. 增强的安全态势： EAP-TLS 消除了凭证收集和中间人 (MitM) 攻击的风险。这对于遵守 PCI DSS 和 GDPR 等框架至关重要，尤其是在 医疗保健 和零售环境中。
3. 无缝入职： 对于同时管理 Windows 和大量 Apple 设备机群的组织来说，将 Intune 与现有的 MDM 工作流程集成（请参阅我们的指南： Jamf 和 RADIUS：为 Apple 设备机群提供基于证书的 WiFi 身份验证 ）可确保从第一天起就提供统一的、零接触的预配体验。