用于 WiFi 的 Microsoft Cloud PKI：结合 Intune 和 Entra ID 的 EAP-TLS 证书部署

是的。Microsoft Cloud PKI 是 Intune Suite 中的托管证书颁发机构，可以向 Intune 管理的设备颁发 EAP-TLS WiFi 证书。SCEP 证书配置文件可直接请求这些证书，因此您无需 NDES 服务器、证书连接器或本地 CA。您的 RADIUS 服务器信任导入的 Cloud PKI 根，并根据该服务发布的 CRL 检查每个证书。

Microsoft Cloud PKI 在 WiFi 身份验证中扮演什么角色？

EAP-TLS（可扩展身份验证协议 - 传输层安全性）是一种 802.1X 方法，在此方法中，双方均使用证书证明自己的身份。IEEE 802.1X 是 WPA2-Enterprise 和 WPA3-Enterprise 背后基于端口的访问控制标准。无线接入点将每次连接尝试传递给 RADIUS 服务器（即接受或拒绝设备的身份验证服务器）。使用 EAP-TLS 时，既没有可用于网络钓鱼的密码，也没有可泄漏的共享密钥。每台设备都持有自己的私钥和证书。

最困难的部分始终是其背后的 PKI（公钥基础设施）。传统上，将证书部署到 Intune 管理的设备上需要四样东西：

• Active Directory 证书服务 (AD CS) 颁发 CA
• NDES（网络设备注册服务）服务器
• Intune 证书连接器
• 用于将 NDES 发布到互联网的反向代理或 Microsoft Entra 应用程序代理

其中每项都需要打补丁、备份和监控。

Microsoft Cloud PKI 用托管在 Intune 租户中的证书颁发机构取代了该技术栈。设备通过 SCEP（简单证书注册协议）请求证书，而 Cloud PKI 会自行响应这些请求。它会根据 Intune 验证每个请求，签署证书并将其返回。设备会在本地生成其私钥，且私钥永远不会离开设备。

对于已加入 Entra ID 的设备群，这消除了证书链中最后的本地依赖项。从未见过域控制器的设备仍然可以获得 WiFi 证书。

Cloud PKI CA 层级结构的工作原理

Cloud PKI 使用两层层级结构。根 CA 签署一个或多个颁发 CA，而颁发 CA 签署设备证书。Microsoft 将 CA 签名密钥存放在硬件安全模块 (HSM) 中，因此您无需管理密钥材料。

您可以选择以下两种锚点之一：

• Cloud PKI 根。 Microsoft 在您的租户中同时托管根 CA 和颁发 CA。这是全新的 Entra ID 环境中最简单的选项。
• 自带 CA (BYOCA)。 您创建一个 Cloud PKI 颁发 CA，下载其证书签名请求，并使用现有的私有根（例如 AD CS 根）对其进行签名。随后，任何已经信任该根的设备都会信任新颁发 CA 的证书链。

您在创建每个 CA 时设置增强型密钥用法 (EKU)。WiFi 客户端证书需要“客户端身份验证”EKU，因此请在两个层级中都包含它。请仔细规划这一点，因为 EKU 在创建 CA 时就已经固定。

设计时需要注意一个界限。Cloud PKI 通过 SCEP 向 Intune 管理的设备颁发证书。它并非旨在颁发 RADIUS 服务器自身的证书，因此该证书通常来自公共 CA 或您现有的 PKI。

Cloud PKI 与采用 NDES 和 PKCS 的 SCEP 的对比

	Cloud PKI (SCEP)	采用 NDES 的 SCEP	PKCS
CA 托管	由 Microsoft 在您的 Intune 租户中托管	您的 AD CS 或第三方 CA	您的 AD CS 或第三方 CA
本地服务器	无	颁发 CA、NDES 服务器、连接器主机	颁发 CA、连接器主机
互联网发布组件	无	NDES，通过反向代理或应用程序代理	无
私钥生成位置	在设备上	在设备上	在 CA 端生成，作为 PFX 交付至设备
适用于纯 Microsoft Entra ID 舰队	原生支持	可用，但保留本地依赖项	可用，但保留本地依赖项
吊销	在 Intune 管理中心吊销，通过 CRL 发布	通过连接器和您的 CA 的 CRL	通过连接器和您的 CA 的 CRL
许可模型	Intune Suite 或 Cloud PKI 附加组件，按席位计费	Windows Server 许可加上 Intune	Windows Server 许可加上 Intune
适用对象	淘汰本地 PKI 的云优先企业	拥有成熟 AD CS 团队和长期 CA 路线图的企业	需要在多个平台上使用相同密钥的场景，例如 S/MIME

我们关于采用 SCEP 和 PKCS 的 Intune 证书部署的独立指南深入探讨了这两种本地路径。

在为 EAP-TLS 部署 Cloud PKI 之前您需要准备什么？

在创建任何内容之前，请检查这六个项目。每一项都对应下文故障排除章节中的某个故障。

• 许可。 一个 Intune Plan 1 订阅，加上 Microsoft Intune Suite 或独立的 Cloud PKI 附加组件。
• 权限。 Intune Administrator 角色，或具有 Cloud PKI 权限的自定义角色。
• 已注册设备。 已在 Intune 中注册的 Windows、macOS、iOS/iPadOS 或 Android 设备，并已在 Microsoft Entra ID 安全组中分组。
• 支持 EAP-TLS 的 RADIUS 服务器。 它必须允许您导入 CA 证书，通过 HTTP 访问 Cloud PKI CRL，并将证书身份映射到 Entra ID 对象。Microsoft NPS (Network Policy Server) 会在本地 Active Directory 中查找账户，因此纯云端设备在该步骤会失败。
• RADIUS 服务器证书。 您还需要颁发该证书的根证书和任何中间证书，因为设备必须验证服务器。
• 支持 802.1X 的接入点。 这些接入点必须广播指向您的 RADIUS 服务器的 WPA2-Enterprise 或 WPA3-Enterprise SSID。

在接入点端，所有主流平台均支持 802.1X。其中包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。有关特定厂商的操作指南，请参阅 在 Juniper Mist 上使用云 RADIUS 配置 802.1X。

如何为 WiFi 设置云 PKI 证书？

以下流程概括了具体的构建步骤。请参阅 Microsoft Learn 上的微软云 PKI 文档以获取最新的界面和逐字段步骤，因为管理中心布局可能会因版本不同而发生变化。

第 1 步：创建根 CA，或使用您现有的根 CA

在 Intune 管理中心，在租户管理下创建一个根 CA。选择密钥大小、有效期和 EKU（包含客户端身份验证）。

对于 BYOCA（自带 CA），请跳过根 CA 步骤。将颁发 CA 创建为 BYOCA 类型并导出其证书签名请求。使用包含客户端身份验证的模板在您的私有 CA 上对请求进行签名，然后上传已签名的证书及其证书链。

第 2 步：创建颁发 CA

创建一个锚定到第 1 步中根 CA 的颁发 CA。其 EKU 必须包含客户端身份验证。创建完成后，其属性页面会显示后续所需的三个要素：

• SCEP URI
• CA 证书下载
• CRL 分发点

第 3 步：部署受信任的证书配置文件

下载根 CA 和颁发 CA 证书。针对每个平台，分别为两者各自创建一个受信任的证书配置文件。将其分配给将接收 SCEP 和 WiFi 配置文件相同的组。

设备需要此证书链才能成功应用 SCEP 配置文件。如果设备尚未信任向您的 RADIUS 服务器证书颁发证书的 CA，请为其另外创建一个受信任的证书配置文件。

第 4 步：创建 SCEP 证书配置文件

按平台创建 SCEP 证书配置文件并将其指向云 PKI。以下是关键决策点：

• SCEP 服务器 URL。 严格按显示内容粘贴颁发 CA 中的 SCEP URI。保持其占位符文本不变，因为 Intune 会在颁发时对其进行解析。
• 根证书。 选择云 PKI 根 CA 的受信任证书配置文件，而不是颁发 CA 的配置文件。
• 证书类型。 针对前台平板电脑或门店手持设备等共享设备，选择设备证书。针对员工携带个人电脑且您希望将策略与个人绑定的场景，选择按人分配的证书。
• 主题和主题替代名称 (SAN)。 包含一个您的 RADIUS 服务器可以映射到 Microsoft Entra ID 的标识符。例如 Entra 设备 ID 变量 {{AAD_Device_ID}} 或 UPN 变量 {{UserPrincipalName}}。
• 密钥用法和 EKU。 设置数字签名和密钥加密，并包含客户端身份验证。
• Windows 上的密钥存储。 注册至 TPM（可信平台模块）密钥存储提供程序，以使私钥绑定到硬件且不可导出。
• 续订阈值。 设置 Intune 自动续订证书的剩余有效时间百分比，确保证书永远不会在无察觉的情况下过期。

第 5 步：让 RADIUS 服务器信任 Cloud PKI

将 Cloud PKI 根 CA 和颁发 CA 证书导入到 RADIUS 服务器的受信任 CA 存储中。仅导入根证书是导致“未知 CA”拒绝的最常见原因。

启用 CRL 检查，并允许 RADIUS 服务器对每个证书中列出的 CRL 分发点具有出站 HTTP 访问权限。使用 BYOCA 时，RADIUS 服务器可能已经信任您的根证书，因此您只需添加新的颁发 CA 证书。

如果 Purple 的云端 RADIUS 为您的员工 WiFi 提供身份验证，您的 Purple 客户团队将确认如何为您的租户加载 Cloud PKI 链。

第 6 步：构建 WiFi 配置文件

创建一个具有企业级安全性并将 EAP-TLS 作为 EAP 类型的 Intune WiFi 配置文件。设置三个字段：

• 客户端身份验证证书。 选择第 4 步中的 SCEP 配置文件。
• 用于服务器验证的根证书。 为 RADIUS 服务器的颁发根选择受信任的证书配置文件。
• 证书服务器名称。 输入与 RADIUS 服务器证书完全匹配的名称。

将配置文件分配给与 SCEP 和受信任证书配置文件相同的组。

吊销功能在 Cloud PKI 中是如何工作的？

您可以直接在 Intune 管理中心从颁发 CA 吊销 Cloud PKI 证书。打开已颁发证书的列表，选择设备的证书并将其吊销。随后，Cloud PKI 会将更改发布到其 CRL（证书吊销列表），该列表位于其颁发的每个证书中嵌有的 HTTP 分发点处。

执行吊销的是您的 RADIUS 服务器，而不是 Intune。它会下载 CRL 并拒绝序列号出现在列表中的任何证书。

大多数 RADIUS 服务器会缓存 CRL，直到其下一次更新时间。因此，已吊销的设备可能会继续连接，直到 RADIUS 服务器获取到最新的列表。您可以通过以下三种方式缩短此窗口期：

1. 显式吊销。 不要依赖于删除配置文件分配或删除设备记录。在入职、调岗、离职（JML）流程中，请直接吊销证书本身。
2. 将吊销与身份检查相结合。 如果您的 RADIUS 服务在每次身份验证时都会检查 Entra ID 账户或设备状态，那么禁用该账户可以在 CRL 刷新之前就阻止访问。
3. 监控 CRL 检索。 对下载失败的 CRL 发出警报。持有过期 CRL 的 RADIUS 服务器要么继续放行已吊销的设备，要么拒绝所有设备，具体取决于其失败策略。

如何检查 Cloud PKI WiFi 身份验证是否正常工作？

使用您支持的每个平台上的 5 到 10 台设备组成的测试组进行试点。确认以下五点：

1. 配置文件状态。 受信任证书、SCEP 和 WiFi 配置文件在 Intune 设备配置报告中均显示成功。
2. 设备上的证书。 在 Windows 上，证书会出现在个人存储区中，并包含预期的主题、SAN 和客户端身份验证 EKU。其证书链应能构建到 Cloud PKI 根证书。
3. 颁发记录。 证书出现在 Intune 管理中心颁发 CA 的已颁发证书列表中。
4. RADIUS 日志。 身份验证日志显示 EAP-TLS 成功、预期的身份以及有效的证书链。
5. 吊销测试。 吊销一张测试证书。一旦 RADIUS 服务器获取到新的 CRL，确认该设备被拒绝连接。

在正式上线前运行吊销测试。这是证明您的 RADIUS 服务器能够访问 CRL 的唯一检查方式。

Cloud PKI EAP-TLS 会出现什么问题，如何修复？

症状	可能的原因	解决方法
SCEP 配置文件卡在错误或挂起状态	受信任的证书配置文件未分配给同一个组，或者 SCEP 配置文件引用了颁发 CA 而非根 CA	将根 CA 和颁发受信任配置文件分配给相同的组，并在 SCEP 配置文件中选择根 CA
证书已颁发，RADIUS 拒绝并提示“未知 CA”	仅将根 CA 导入了 RADIUS	同时导入颁发 CA 证书
上线后所有设备都被拒绝	RADIUS 无法访问 CRL 分发点并导致默认拒绝	允许从 RADIUS 到 CRL 主机的出站 HTTP 流量
Android 设备拒绝连接	未设置服务器验证；Android 11 及更高版本需要此设置	将 RADIUS 服务器的根 CA 作为受信任配置文件进行部署，并设置证书服务器名称
Windows 提示员工信任服务器	WiFi 配置文件中的服务器名称与 RADIUS 证书不匹配	修正服务器名称，使其与证书完全匹配
NPS 拒绝已加入 Microsoft Entra ID 的设备	NPS 正在查找不存在的本地 Active Directory 账户	使用可将证书映射到 Microsoft Entra ID 对象的 RADIUS 服务
已吊销的设备仍能连接	RADIUS 保留了缓存的 CRL	将吊销与 Microsoft Entra ID 账户或设备禁用挂钩，并检查 CRL 缓存设置
证书缺少客户端身份验证	创建颁发 CA 时未包含该 EKU	创建带有客户端身份验证的新颁发 CA，并重新指向 SCEP 配置文件

如果故障集中在特定房间或楼层，而相同设备在其他地方可以正常身份验证，则故障出在无线电覆盖范围，而不是 PKI。与预共享密钥握手相比，EAP-TLS 交换的数据包更多，因此较弱的信号会表现为超时。WiFi 现场勘测：实用规划指南 介绍了如何找出这些盲区。

Cloud PKI 还是带有 NDES 的 SCEP：您应该选择哪种？

根据您现有的运行环境以及计划淘汰的系统做出决定。

您的现状	建议	原因
已加入 Microsoft Entra ID 的设备群，无 AD CS	带有 Cloud PKI 根证书的 Cloud PKI	无需构建或运行本地 PKI
AD CS 已就绪，NDES 服务器需进行操作系统更新	云 PKI 配套 BYOCA	保留您现有的根信任，同时淘汰 NDES 和连接器
AD CS 团队拥有长期 CA 路线图和其他证书模板	基于 NDES 的 SCEP，在下一次服务器更新时复核	现有投资已覆盖非 WiFi 使用场景
多个设备上需要相同的密钥对，例如 S/MIME	针对该使用场景使用 PKCS，WiFi 使用云 PKI	PKCS 可提供可导出的密钥；WiFi 证书应保持与设备绑定
目前在 NPS 上的混合加入设备，正在向 Entra ID 加入迁移	云 PKI 加云 RADIUS 服务	一旦设备离开 Active Directory，NPS 查询就会中断

医疗保健 领域的受监管资产通常会保留 AD CS 用于其他工作负载。对他们来说，BYOCA 通常是最合适的选择，因为它可以在整个组织中保持单一信任根。在 火车 上向随车工作人员平板电脑颁发证书的铁路运营商更适合云 PKI 根途径。这些设备从第一天起就实行云端管理。

云 PKI 的成本是多少，又能带来什么回报？

Microsoft 按每个席位、每月对云 PKI 进行许可授权。它可以包含在 Intune Suite 中，也可以作为 Intune Plan 1 之上的独立附加组件提供。请查看 Microsoft 当前的价格列表，因为打包方案可能会有变化。

将其与本地途径对您造成的成本进行权衡：

• 用于颁发 CA、NDES 和连接器主机的 Windows Server 许可证和虚拟机
• 发布 NDES 的反向代理或应用代理
• CA 数据库备份
• 打补丁和证书模板管理

带来的回报是更少的服务器、无需向互联网发布的 NDES 端点，以及您管理的每个平台上的设备绑定密钥。

实际案例：拥有 30 家物业的酒店集团

情况。 一个拥有 30 家 酒店 的集团，在其员工 SSID 上运行着 900 台已加入 Entra ID 的笔记本电脑和前台平板电脑，该 SSID 采用一个共享预共享密钥进行保护。每季度轮换该密钥意味着需要触及每家物业的每台设备。丢失一台平板电脑会让密钥面临泄露风险，直到下一次轮换。

做了什么。 IT 部门创建了一个云 PKI 根和颁发 CA，然后通过 SCEP 颁发了基于 TPM 的设备证书。云 RADIUS 服务验证了该证书链并检查了 CRL。该集团在试点期间运行了一个与旧 SSID 并行的 EAP-TLS SSID，分批迁移物业，然后关闭了预共享密钥网络。

结果。 场景计算非常直观：

• 员工网络上的共享密钥从一个减少到零。
• 跨 30 家物业的季度密钥轮换完全停止。
• 丢失平板电脑只需撤销一个证书，而无需对 900 台设备重新进行密钥配置。
• 无需本地 CA、NDES 服务器或连接器。

实际案例：拥有 250 家门店的零售连锁店

**情况。**一家 零售 连锁店通过 AD CS 和两台 NDES 服务器，向 4,000 台门店手持设备和笔记本电脑颁发了 WiFi 证书。Intune Certificate Connector 运行在第三台服务器上。这三台服务器的操作系统都需要更换，且 NDES 是通过应用程序代理发布的。

**采取的措施。**团队创建了一个 Cloud PKI 颁发 CA 作为 BYOCA，并使用现有的 AD CS 根进行签名。RADIUS 服务器已经信任该根，因此仅导入了新的颁发 CA 证书。SCEP 配置文件一次一个门店组地迁移到 Cloud PKI。现有证书在到期更新前保持有效，从而保留了回滚能力。

**结果。**该连锁店退役了三台服务器：两台 NDES 和一台连接器主机。它还删除了向互联网发布的 NDES 端点。RADIUS 或任何设备上都不需要重新信任根。AD CS 根保留在原位以用于其他工作负载。

Purple 适用之处

Purple 员工 WiFi 采用基于身份的网络与云 RADIUS，并与 Microsoft Entra ID、Okta 或 Google Workspace 连接。Purple 在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 之间实现硬件无关。为什么你的下一次 WiFi 升级不需要新硬件 解释了为什么改用基于证书的员工访问很少需要更换接入点。

Purple 在 80,000 多个实时场所运行（Purple 数据），正常运行时间达 99.999%，并获得了 ISO 27001 认证。将员工和访客保持在独立的网络上：为您管理的设备提供基于证书的员工 WiFi，为其他人提供 访客 WiFi。

常见问题解答

Microsoft Cloud PKI 可以颁发 WiFi 证书吗？

可以。Cloud PKI 通过 SCEP 证书配置文件向 Intune 管理的 Windows、macOS、iOS/iPadOS 和 Android 设备颁发客户端身份验证证书。这些证书使用 EAP-TLS 将设备验证到 WPA2-Enterprise 或 WPA3-Enterprise 网络。您的颁发 CA 必须包含客户端身份验证 EKU，并且您的 RADIUS 服务器必须信任 Cloud PKI 根和颁发 CA。Cloud PKI 通常不颁发 RADIUS 服务器自身的证书。该证书来自公共 CA 或您现有的 PKI。

使用 Cloud PKI 我还需要 NDES 吗？

不需要。Cloud PKI 自行响应 SCEP 请求，因此您不需要 NDES 服务器，不需要 Intune Certificate Connector，也不需要将 NDES 发布到互联网的反向代理。Intune 中的 SCEP 配置文件直接指向 Cloud PKI 颁发 CA 上显示的时 SCEP URI。如果您使用自带 CA 选项，您的私有根会为 Cloud PKI 颁发 CA 进行一次签名。在此之后，设备注册再也不会触及您的本地服务器。

RADIUS 服务器如何信任 Cloud PKI 证书？

您需要将 Cloud PKI 根 CA 和颁发 CA 证书导入 RADIUS 服务器的受信任 CA 存储中。请从 Intune 管理中心下载这两份证书。务必将两者全部导入，因为仅导入根 CA 会导致“未知 CA”拒绝。RADIUS 服务器还需要对每个证书中的 CRL 分发点具备出站 HTTP 访问权限，以便检查撤销状态。对于已加入 Entra ID 的设备，它必须将证书身份映射到 Entra ID，而非本地 Active Directory。

Cloud PKI 的撤销机制是如何工作的？

您可以在 Intune 管理中心从颁发 CA 撤销证书，Cloud PKI 会将变更发布到其 CRL。您的 RADIUS 服务器会下载该 CRL 并拒绝已撤销的证书。由于 RADIUS 服务器会缓存 CRL，已被撤销的设备可能会继续连接，直至下一次刷新。只要您的 RADIUS 服务在每次身份验证时都检查身份状态，您就可以通过同时禁用 Entra ID 账户或设备来填补这一时间差。

我应该选择 Cloud PKI 还是带 NDES 的 SCEP？

如果您运营纯 Entra ID 联网设备或计划停用本地 PKI 服务器，请选择 Cloud PKI。它省去了颁发 CA、NDES 和连接器主机。如果您拥有成熟的 AD CS 团队、长期 CA 路线图以及其他证书模板，请继续使用带 NDES 的 SCEP。如果您的 NDES 服务器即将需要更新换代，采用 BYOCA 的 Cloud PKI 可以保留您现有的根信任，同时依然能够停用 NDES。

Microsoft Cloud PKI 如何计费许可？

Cloud PKI 按席位、按月计费，叠加在 Intune Plan 1 之上。它可以作为 Microsoft Intune Suite 的一部分提供，也可以作为独立的 Cloud PKI 附加组件提供。由于套餐组合会有变化，请在制定预算前查看 Microsoft 的最新价格表。您可以将许可成本与 AD CS、NDES 和连接器技术栈所需的 Windows Server 许可、虚拟机、代理发布和补丁更新工作量进行对比评估。

我可以通过 Cloud PKI 继续使用现有的本地根 CA 吗？

可以，通过自带 CA（BYOCA）选项即可实现。您可以创建一个 Cloud PKI 颁发 CA，导出其证书签名请求（CSR），并用您现有的私有根（例如 AD CS）对其进行签名。任何已经信任该根的设备和服务器（包括您的 RADIUS 服务器）都会信任新的证书链。您只需要添加颁发 CA 证书即可。您可以按组逐步迁移 SCEP 配置文件，而现有证书在到期续订前依然有效。

Cloud PKI 是否兼容我现有的无线接入点（AP）？

是的，只要您的接入点支持基于 WPA2-Enterprise 或 WPA3-Enterprise 的 802.1X 即可。Cloud PKI 仅影响设备上的证书以及 RADIUS 服务器上的信任关系。接入点只是将身份验证转发给 RADIUS。Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 都支持这一点。Purple 的 Staff WiFi 作为硬件无关的云端叠加层，可跨所有这八家厂商平稳运行。