跳至主要内容
简体中文

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

本指南为通过 Microsoft Intune 使用 SCEP 和 PKCS 部署 WiFi 身份验证证书提供了分步技术参考。它专为实施无密码 802.1X WiFi 的 IT 经理和网络架构师而设计，以确保在企业环境中实现无缝、安全的连接。

作者：Iain Jewitt发布于
📖 6 分钟阅读313 字2 应用实例3 练习题8 关键定义

核心系列的一部分：Enterprise WiFi Security Guide →

Interactive Architecture Tool802.1X EAP-TLS Profile Sizer

Microsoft Intune WiFi certificate profile and architecture advisor

Model your enterprise 802.1X certificate deployment. Compare SCEP vs PKCS vs Microsoft Cloud PKI, validate OS-specific key storage parameters, eliminate group targeting conflicts (error 0x87D1FDE8), and generate deployment profiles.

Architecture Score
95/100
Strong architecture

Certificate Enrollment Specifications

  • Protocol: Simple Certificate Enrollment Protocol (RFC 8894)
  • Key Security: Generated on client device (TPM / Secure Enclave) - never leaves endpoint
  • Key Length: RSA 2048-bit (SHA-256 Signature Hash)
  • Hardware Provider: TPM KSP (Microsoft Platform Crypto Provider) if present, fallback to Software KSP
  • Subject Name Format: CN={{UserName}},OU=WiFi Users,DC=corp,DC=internal
  • Subject Alternative Name (SAN): User Principal Name (UPN) = {{UserPrincipalName}}
  • Renewal Threshold: 20% (Trigger certificate renewal at 80% of validity period)

AAA & RADIUS Integration Details

  • RADIUS Engine: Purple Cloud RADIUS (Recommended)
  • Architecture Mode: 100% Cloud Native AAA
  • RadSec (RFC 6614): Supported (Encrypted TLS Tunnel)
  • Directory Lookup: Direct REST API integration with Microsoft Entra ID for dynamic role mapping & group sync
  • CRL & OCSP Validation: Real-time OCSP & Automated CRL distribution point polling
  • Operating System Best Practice: Configure Identity Certificate reference in WiFi profile to avoid manual user certificate prompts.

Remove on-premises NPS and NDES with Purple Cloud RADIUS

Authenticate Microsoft Entra ID and Intune-enrolled devices natively with zero on-premises servers. Get dynamic role-based VLAN steering, RadSec encryption, and automated certificate revocation.

Useful? Link to this tool

通过 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 电子邮件加密，而不是网络身份验证。

通过 SCEP 和 PKCS 的 Microsoft Intune WiFi 证书部署 - scep vs pkcs comparison

对您的具体配置有疑问吗？

我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话，我们将为您展示同行是如何解决类似问题的。

实施指南：部署顺序

成功为 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 服务器。

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

最佳实践与行业标准

在实施 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 身份验证）可确保从第一天起就提供统一的、零接触的预配体验。

关键定义

SCEP (Simple Certificate Enrollment Protocol)

一种允许设备从证书颁发机构请求数字证书的协议，其中私钥在设备本身上生成并安全存储。

由于其高安全性和可扩展性，它是部署 WiFi 身份验证证书的推荐方法。

PKCS (Public Key Cryptography Standards)

一组标准，其中公钥和私钥均由证书颁发机构生成，然后安全地交付给终端。

通常用于 S/MIME 电子邮件加密，但由于私钥的网络传输，对于 WiFi 来说不太理想。

NDES (Network Device Enrollment Service)

一个 Microsoft Windows Server 角色，充当桥梁，允许没有域凭据的设备通过 SCEP 获取证书。

在使用 Microsoft Intune 实施 SCEP 证书部署时必需的基础设施组件。

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

最安全的 802.1X 身份验证方法，要求服务器和客户端都出示有效的数字证书。

Intune WiFi 和证书配置文件旨在启用的目标身份验证协议。

CRL (Certificate Revocation List)

由证书颁发机构发布的列表，包含在到期日期之前已被吊销的证书的序列号。

对安全性至关重要；RADIUS 服务器必须检查 CRL，以确保被解雇的员工无法使用其他有效的证书访问 WiFi。

Intune Certificate Connector

安装在本地 Windows Server 上的软件代理，在 Microsoft Intune 和内部证书颁发机构之间代理请求。

SCEP（用于验证请求）和 PKCS（用于导出密钥）部署都需要。

Subject Alternative Name (SAN)

数字证书的扩展，允许将多个值（如 UPN、电子邮件或 MAC 地址）与证书关联。

在 Intune SCEP 配置文件中配置，以确保 RADIUS 服务器能够准确识别用户或设备。

Azure AD Application Proxy

一项功能，可为本地 Web 应用程序提供安全的远程访问，无需 VPN 或打开入站防火墙端口。

将内部 NDES 服务器 URL 安全地发布到互联网以进行远程设备注册的最佳实践方法。

应用实例

一家拥有 500 个门店的全国性零售连锁店正在将其门店员工平板电脑（Android Enterprise 专用设备）从 WPA2-Personal（预共享密钥）迁移到 WPA3-Enterprise。他们使用 Intune 进行 MDM。他们应该如何构建证书部署架构？

  1. 部署通过 Azure AD 应用程序代理发布的 NDES 服务器。
  2. 在 Intune 中创建基于设备的 SCEP 证书配置文件，因为这些是专用（自助服务终端）设备，不与特定用户关联。使用 CN={{AAD_Device_ID}} 作为使用者名称。
  3. 将根 CA 配置文件部署到“所有门店平板电脑”Azure AD 设备组。
  4. 将 SCEP 配置文件部署到相同的“所有门店平板电脑”组。
  5. 创建一个配置了 WPA3-Enterprise、EAP-TLS 的 WiFi 配置文件，引用 SCEP 配置文件，并将其部署到相同的组。
  6. 配置中央 RADIUS 服务器，以根据 Active Directory 计算机对象对设备证书进行身份验证。
考官评语： 这种方法正确地识别出专用设备需要基于设备（而非基于用户）的证书。通过在所有三个配置文件中一致地定位设备组，架构师避免了最常见的 Intune 部署失败。使用 Azure AD 应用程序代理作为 NDES 可确保平板电脑无需 VPN 即可安全地续订证书。

一个大型会议中心使用 Purple 作为其 [WiFi 分析](/products/wifi-analytics) 和访客 WiFi，但需要保护其内部员工网络。员工使用公司拥有的 Windows 笔记本电脑和 BYOD iOS 设备的混合。他们如何处理 BYOD 设备的 Intune 部署？

  1. 要求 BYOD 用户通过 Intune 用户注册（创建安全的工作分区）注册其 iOS 设备。
  2. 使用 CN={{UserPrincipalName}} 创建基于用户的 SCEP 证书配置文件。
  3. 将根 CA、SCEP 和 WiFi 配置文件部署到 Azure AD 用户组（例如“所有员工”）。
  4. 当用户注册其个人设备时，Intune 会将配置文件专门推送到受管理的工作分区。
  5. 设备使用用户的身份连接到员工 SSID，从而允许 RADIUS 服务器根据其 AD 组成员身份应用基于角色的访问控制（VLAN 分配）。
考官评语： 此解决方案正确地应用了用户注册以实现保护隐私的 BYOD 管理。通过定位用户组，证书会跟随员工，无论他们注册了哪台设备。通过 RADIUS 集成基于角色的访问控制展示了先进的网络设计。

练习题

Q1. 您已将根 CA、SCEP 和 WiFi 配置文件部署到您的 Windows 10 设备。证书安装成功，但 WiFi 配置文件无法应用，在 Intune 控制台中显示“错误”。最可能的原因是什么？

提示：检查配置文件如何分配给 Azure AD 组。

查看标准答案

最可能的原因是组目标定位不匹配。如果 SCEP 配置文件分配给用户组，但 WiFi 配置文件分配给设备组，Intune 无法解析它们之间的依赖关系。所有三个配置文件（根、SCEP、WiFi）必须定位到完全相同的组类型。

Q2. 您的安全团队要求私钥绝不能通过网络传输，即使经过加密也不行。您必须在 Intune 中使用哪种证书部署方法，并且需要哪些额外的基础设施服务器？

提示：考虑密钥对是在哪里生成的。

查看标准答案

您必须使用 SCEP（简单证书注册协议）。因为 SCEP 指示终端设备在本地生成私钥，它永远不会经过网络。此部署需要一个网络设备注册服务 (NDES) 服务器，作为连接到证书颁发机构的桥梁。

Q3. 一名远程员工通过 Windows Autopilot 在家配置一台新笔记本电脑。Intune 配置文件部署成功，但设备未能获取 SCEP 证书。可能缺少哪些基础设施配置？

提示：设备如何从互联网访问内部 CA？

查看标准答案

NDES 服务器可能尚未发布到互联网。为了使远程设备在到达公司办公室之前能够请求证书，NDES URL 必须是外部可访问的，最好通过 Azure AD 应用程序代理安全发布。

常见问题

What is the difference between SCEP and PKCS for Intune WiFi certificates?

SCEP (Simple Certificate Enrollment Protocol, RFC 8894) generates the private key directly on the endpoint hardware (TPM or Secure Enclave) through a one-time challenge password; the private key never leaves the client device. PKCS #12 generates the private key on the certificate authority (AD CS) and transfers the encrypted PFX file over TLS to the device. SCEP is strongly recommended for Zero-Trust enterprise 802.1X WiFi.

What on-premises infrastructure is required for SCEP deployment with Intune?

A standard SCEP deployment requires an Active Directory Certificate Services (AD CS) Enterprise Certificate Authority, the Network Device Enrollment Service (NDES) server role, the Microsoft Intune Certificate Connector, and an external publishing mechanism such as Microsoft Entra Application Proxy or a reverse proxy with valid public SSL certificates.

How does Microsoft Cloud PKI simplify 802.1X WiFi certificate management?

Microsoft Cloud PKI (included in Intune Suite) eliminates all on-premises Windows Servers, NDES roles, and connector agents by hosting the issuing and root certificate authorities entirely in the Microsoft cloud. Intune handles SCEP certificate requests natively, slashing maintenance overhead while supporting multi-platform 802.1X authentication.

In what order must Intune configuration profiles be assigned to endpoints?

Profiles must be assigned in a strict three-tier dependency sequence: first, the Trusted Root Certificate Profile containing the CA chain; second, the SCEP or PKCS Client Certificate Profile targeting user or device authentication; and third, the 802.1X WiFi Configuration Profile configured with WPA3-Enterprise and referencing the client certificate.

How does Purple integrate with Microsoft Intune and Entra ID for enterprise WiFi?

Purple provides a hardware-agnostic Cloud RADIUS AAA service with native Microsoft Entra ID and Intune integration. Purple validates SCEP and Cloud PKI X.509 certificates with automated revocation checking (CRL/OCSP), applies real-time directory-driven dynamic VLAN assignments, and isolates corporate and visitor traffic across all major enterprise access point vendors.

继续阅读本系列

Sophos 防火墙与访客 WiFi：配合 Purple 设置 Captive Portal

详细了解 Purple 的云访客 WiFi 如何通过标准外部 Captive Portal 和 RADIUS 配合 Sophos 防火墙及其接入点工作，以及在哪里查看支持和查找设置步骤。

阅读指南 →

Aruba Central与Purple WiFi：云端管理集成

一份全面的技术参考指南，用于将Aruba Central与Purple的云端托管访客WiFi智能平台集成。本指南涵盖架构、外部强制门户和RADIUS的分步配置，以及为企业IT团队提供的多站点部署策略。

阅读指南 →

Microsoft Entra ID (Azure AD) WiFi 身份验证：企业集成指南

本技术指南为网络工程师、IT 架构师和系统管理员提供了将 Microsoft Entra ID（前称 Azure AD）与企业级 802.1X WiFi 基础设施集成的权威蓝图。了解如何淘汰本地 RADIUS 服务器、通过 Microsoft Intune SCEP 和云 PKI 部署无密码 EAP-TLS 证书，以及如何使用 Entra ID 安全组自动进行动态 VLAN 分配。

阅读指南 →

对您的具体配置有疑问吗？

我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话，我们将为您展示同行是如何解决类似问题的。