EAP-TLS 与 PEAP：安全性、证书和适用性对比
Published
关于 eap tls vs peap 的最常见建议看似干脆利落，实则是错误的。选择 EAP-TLS 是因为它"更安全"，把 PEAP 留给还没赶上趟的团队。这种说法回避了决定多场所 WLAN 能否在周一正常运行的关键问题。您能否为每一个预定使用的设备颁发、更新和吊销证书？
我不会在整个网络环境中仅采用一种认证方式。EAP-TLS 适用于能够进行证书注册和更新的设备。PEAP（几乎总是配合内部 EAP-MSCHAPv2 使用）适用于已存在目录密码且证书注册不切实际的场景。更复杂的认证方式并不总是最可行的方案。酒店后勤部门过期的证书会导致员工被锁在系统之外，即使他们的账户依然有效；而忽略服务器检查的 PEAP 配置文件可能将目录密码拱手让给伪造接入点。这两种失败都是运维维度的。应当根据用户群体分配认证方式，而不是盲目寻求全网统一的方案。
目录
EAP-TLS 与 PEAP 综合对比
EAP-TLS 与 PEAP 之间的实际区别在于每个终端能够支持的凭据类型，以及维持其可用性所需的工作量。对于您可以进行注册和续订的设备，请使用 EAP-TLS。对于用户已经拥有目录密码且证书注册不切实际的情况，请使用 PEAP。这两种方法都不是适用于所有用户群体的唯一正确答案。
| 评估标准 | EAP-TLS | PEAP |
|---|---|---|
| EAP 类型 ID | 13 | 26 |
| 客户端凭据 | X.509 客户端证书 | 用户名和密码，通常为 EAP-MSCHAPv2 或 EAP-GTC |
| 服务器凭据 | RADIUS 服务器证书 | 外层 TLS 隧道上的 RADIUS 服务器证书 |
| 双向认证 | 客户端与服务器证书 | 服务器证书外加内层用户或设备认证 |
| 网络传输密码 | 无 | 有，在 TLS 隧道内部传输 |
| 若客户端跳过服务器检查，流氓 AP 可窃取的内容 | 无任何类密码信息；认证将直接拒绝并关闭 | 目录密码 |
| 单一设备吊销 | 吊销或注销该证书 | 禁用账号或重置可能重复使用的密码 |
| PKI 工作量 | 服务器与客户端证书、更新及恢复 | 仅需服务器证书 |
| 最佳适用场景 | 经 MDM 管理的员工与特权设备 | 无法注册证书的未经管理终端 |
一篇 2025 年 Authentik 技术文章 指出 EAP-TLS 的 EAP 类型 ID 为 13，而 PEAP 的类型 ID 为 26。这些 ID 用于向 RADIUS 和请求者识别身份验证方法，但它们并不能决定哪些人员或设备应当使用它们。
各项参数对实际运行的影响
客户端凭据决定了运维边界。EAP-TLS 提供 X.509 客户端证书。PEAP 使用用户名和密码，通常通过 EAP-MSCHAPv2 或 EAP-GTC 进行。这使得证书注册和更新成为关键的工作负载，而不是对各种方法进行理论上的优劣排名。
信任检查也有所不同。EAP-TLS 会对客户端和服务器证书进行双向验证。PEAP 则会在外层 TLS 隧道中验证 RADIUS 服务器证书，然后再通过内层方法对用户或设备进行身份验证。
密码泄露取决于请求者（Supplicant）的配置。EAP-TLS 在网络上传输时无需密码。PEAP 则在其隧道内部传输密码，因此跳过服务器检查的客户端可能会将目录密码泄露给伪造接入点。使用 EAP-TLS 时，丢失或不受信任的客户端证书将直接导致身份验证失败。
离职与解绑流程也取决于管理的具体内容。可以吊销或让设备证书到期，而无需重置个人的目录密码。禁用账户或更改复用的密码可能会影响绑定到该凭据的其他登录。
运维权衡非常明确：EAP-TLS 需要客户端证书、更新机制和恢复路径，而 PEAP 需要服务器证书和谨慎的客户端配置。将 EAP-TLS 分配给已注册的员工和特权设备；保留 PEAP 给无法纳入证书管理的未托管终端。为 会员平台运行无服务器架构 的团队可能拥有不同的会员、员工和设备群体，但托管模型本身并不能决定认证方式。凭据类型必须与您能够管理的群体相匹配。
每种方法的认证方式及密码泄露隐患
EAP-TLS 并不自动适合所有用户。关键决策在于您的团队能否为每个用户群体可靠地颁发、续订和吊销证书。PEAP 可以简化非托管用户的入网流程，但其密码安全取决于请求方配置是否正确。
这两种方法均使用 802.1X。请求者（Supplicant）是请求访问的设备，认证者（Authenticator）是转发该请求的接入点或交换机，而 RADIUS 服务器负责接受或拒绝请求。它们共享的是 EAP 框架，而非身份凭据。
IETF EAP 规范索引 将 IETF RFC 5216 中定义的 EAP-TLS 描述为基于证书的客户端和服务器认证，具备双向认证、受完整性保护的加密套件协商以及密钥衍生功能。该规范发布于 2008 年 3 月。在实际应用中，EAP-TLS 除了需要 RADIUS 服务器证书外，还需要通过 PKI 颁发的客户端证书。
两个序列，一个框架
EAP-TLS 在一次 TLS 交互中完成对两个端点的身份验证：
- 请求方与认证方启动 EAP，认证方将请求转发至 RADIUS。
- 在 TLS 交换过程中检查服务器证书和客户端证书。
- 此交换过程保护密码套件协商并生成密钥，无需发送可能被网络钓鱼、重放或暴力破解的密码。
- 缺失或不受信任的客户端证书意味着该设备会被拒绝。它无法退回到通过输入密码进行认证。
PEAP 会建立一个用于认证服务器的外层 TLS 隧道，然后运行内层方法，通常为 EAP-MSCHAPv2 或 EAP-GTC。由于内层方法可以使用用户名和密码，终端设备通常不需要客户端证书。IETF EAP 规范索引也描述了这些方法所使用的标准框架。
用户看不到 PEAP 的外层隧道。内部身份（通常是用户名和密码或令牌）仅在 TLS 建立后发送。这使得 PEAP 对基于目录的请求方非常熟悉，但如果客户端未正确验证隧道，密码仍会面临泄露风险。
带有内层 EAP-TLS 的 PEAP 是一种更为复杂的特殊情况，它将证书方法与外层 TLS 隧道相结合。通常所说的“PEAP”部署基本上是指 PEAP-MSCHAPv2。
客户端决定最终结果的关键环节
一篇 企业级无线 EAP 方法文章 阐明了这一区别：EAP-TLS 使用相互 X.509 身份验证。RADIUS 会验证客户端证书，而客户端也会验证服务器证书。没有密码可供钓鱼、重放或暴力破解。该文章还指出，NIST 要求无线站点和身份验证服务器都必须持有有效证书。
使用 PEAP 时，客户端必须验证 RADIUS 证书链和预期服务器名称。如果缺少任何一项检查，伪造接入点就能诱骗获取目录密码。设置为“不验证”的请求方配置文件无法保护密码安全。
实用规则：请在 WiFi 配置档中固定 RADIUS 服务器名称和颁发 CA。如果不进行这些检查，PEAP 可能会将密码泄露给伪造服务器。
捕获的 MS-CHAPv2 响应在攻击者通过伪造隧道获取后可以进行离线破解。验证隧道才是安全控制的核心；如果配置文件接受未受信任的服务器，内部认证方式也无法挽救安全性。同样的密码风险不仅限于 WiFi。针对 澳大利亚小型企业凭据泄露 的报告强调了为什么重复使用的目录密码对攻击者来说依然极具价值。
将 EAP-TLS 分配给您能够对其证书生命周期进行管理的托管设备和用户。在用户或设备无法可靠地接收和更新证书的地方使用 PEAP，但需通过请求方（supplicant）配置文件强制执行服务器名称和 CA 验证。其中的运维权衡非常直接：证书需要注册和恢复工作，而密码则会让您陷于管理重复使用和账号变更的繁琐中。更优的方法取决于您能管理哪些对象，而不是为每个 SSID 简单粗暴地指定一个胜者。
部署前必须满足的证书要求
在首次进入生产环境前，请在测试环境中确认这 6 个项目。证书链缺失或名称错误表现出来的现象是“WiFi 挂了”，而不是提示证书错误。
- RADIUS 服务器证书。由您的私有 CA 颁发。将请求程序配置文件指定的名称放入主题或 SAN 中。设置服务器身份验证用途，并随证书一起提供完整的中间链。使用会签署任何匹配名称的公有 CA，对于内部 RADIUS 名称来说是错误的信任模型。
- 客户端证书。每个设备或用户一个，具有客户端身份验证用途。在 SAN 中放入唯一的身份信息，例如用户主体名称或设备序列号。在平台支持的情况下，将私钥存储在 TPM 或安全包围区（Secure Enclave）中。
- 信任锚点。通过 MDM 配置文件安装内部根 CA 或颁发 CA。不要将设备指向公有根 CA，并寄希望于名称检查就足够了。
- 有效期与续订。为服务器证书和客户端证书发布有效期限。构建一个重叠窗口，以便在旧证书到期前安装好新证书。
- 吊销。为 RADIUS 服务器提供其可以访问的 CRL 或 OCSP 端点。以书面形式确定当该端点离线时，身份验证是失败还是继续。测试离线情况。切勿在广域网（WAN）出现瞬间故障时才发现问题。
- 注册通道。通过 MDM 使用 SCEP 或 PKCS#12 交付证书。在面向群组推广之前，先在一台设备上验证该流程（包括续订）。
假设某个诊所站点使用 Okta 管理员工身份，使用 Intune 管理笔记本电脑。配置文件中的 RADIUS 名称必须与证书匹配，并且应该分配到临床 VLAN 的 Okta 组必须与 MDM 用于注册的组相同。我们关于 Okta WiFi 认证 的文章详细介绍了该身份传递过程，且不会将实验室网络变成基于密码的 SSID。
在涉及实际办公区域之前，请先连接一台测试笔记本电脑，吊销其证书，并确认下一次关联尝试失败。
证书生命周期和部署工作量
当证书过期或客户端无法获取吊销信息，而用户账户依然完全有效时，EAP-TLS 的安全性就会演变为网络中断事故。这才是值得深思的问题。简单一句"证书配置太难"并不能算作架构设计。
NIST Special Publication 800-120 也指出了同样的风险。EAP-TLS 需要可靠的颁发、分发、续订、信任链管理和吊销检查。如果证书到期或吊销服务无法访问，即使用户的身份仍然有效，设备也可能会失去网络访问权限。PEAP 通常在外部 TLS 阶段对服务器进行身份验证，并通过内部方法（如 MS-CHAPv2）对用户名和密码进行身份验证，因此它跳过了客户端证书生命周期管理。虽然第一天部署更容易，但后续的工作量会转移到密码重置和错误配置文件的处理上。
防止证书成为系统中断的诱因
设计层面的应对方案是自动化，而不是编写更繁琐的操作指南。
- 通过 MDM 进行注册。 将配置文件、信任锚点和证书一起推送。手动 WiFi 设置往往是导致服务器名称检查被取消勾选的原因。
- 设置重叠续订期。 在旧证书到期之前安装新证书。所有笔记本电脑在同一个周末同时失效，说明续订重叠期太短。
- 测试离线吊销。 了解当无法获取 CRL 或 OCSP 时，RADIUS 是选择拒绝访问（Fail closed）还是允许访问（Fail open）。
- 保留恢复路径。 故障终端需要一种不需要“借用他人 PEAP 密码”的恢复途径。有线服务台端口或受严格限定的恢复 SSID，远比写在白板上的共享密钥更安全。
Purple Access 可通过 SCEP 接收来自 Microsoft Intune、Jamf Pro、JumpCloud、Kandji、Hexnode、Iru 和 Addigy 的 EAP-TLS 证书，整个组织只需进行一次五到十分钟的设置，无需按设备重复设置。此安全网络是无密码且基于证书的，如果设备未通过合规性评估，则会在身份验证时通过Conditional Access被拒绝。这是基于合规性门槛的接入，而非第二次密码提示。
当 PKI 尚不成熟、承包商无法纳入 MDM 或混合 BYOD 环境无法接受证书时，PEAP 仍然是简单直接的选择。医疗保健、教育、招待业和其他多场所网络通常会同时面临这三项挑战。请将 EAP-TLS 用于托管的企业、员工和高风险设备。同时为未托管或临时端点保留一个受到严格控制的替代方案。场所规模的身份识别才是关键决策，而不是一句 TLS 战胜了密码的口号。
如果 RADIUS 本身是薄弱环节，托管的后端服务可以消除"总部机房仅有一台服务器"的单点故障。在指责 EAP 方法之前，可以查阅我们关于 RADIUS-as-a-Service 的文章，以确认网络可达性和冗余性。
下面的简短演示展示了证书注册与密码内层方法的对比，这正是服务台在证书续订延迟时所看到的鲜明差异。
吊销漫游速度和客户端支持
支持度与速度属于查询类问题。目前的 Windows、macOS、iOS、Android 和 ChromeOS 请求程序均支持这两种方法。两者的区别在于故障模式。
当配置文件、颁发 CA 或有效日期出错时，EAP-TLS 会认证失败。当内部方法、身份格式或服务器名称检查与 RADIUS 策略不匹配时，PEAP 会认证失败。这两种失败都不意味着接入点“不支持企业级认证”。
吊销机制同样存在这种分野。禁用单个设备证书切断的是该笔记本电脑的访问权限，而不会影响该用户的其他登录凭据。重置目录密码则会影响所有仍在使用该密码的未托管客户端。实现即时且针对特定设备的访问切断是 EAP-TLS 的优势，而证书过期导致的硬性连接失败则是其相应的维护成本。
注重握手协议，而非品牌名称
一篇关于 无线认证延迟的 ACM 论文 指出，网络性能更多取决于握手次数、漫游、证书验证和后端延迟，而非认证方式的名称。标准 EAP-TLS 在其 TLS 交换中完成客户端和服务器证书认证。PEAP 则先建立 TLS 隧道，然后再运行内部认证，增加了一个独立的阶段。该论文中提及的 Cisco 技术资料指出，带有内部 EAP-TLS 的 PEAP 涉及两次 TLS 握手，并且在漫游期间进行完整重新认证时可能会很慢。
请分别测量这些指标。不要仅凭单一的平均登录时间就判定胜负。
- 第 95 百分位关联至 IP 时间
- 完整认证与漫游恢复延迟
- RADIUS 往返时间
- 认证失败率
- 证书续订失败数
会话恢复、PMK 缓存或 802.11r、本地 RADIUS 可达性以及较短的证书链，对这些数据指标的影响远大于更换密码套件。PEAP 在第一天看起来很简单，但仍可能因重复的密码交换和用户修复而产生延迟。EAP-TLS 在注册后可以感觉像是即时连接，但如果证书过期则会导致严重的连接失败。
| 故障现象 | 更可能的认证方式 | 常见原因 | 实用解决方法 |
|---|---|---|---|
| 在未知 AP 附近重复弹出密码提示 | PEAP | 请求方（Supplicant）未验证服务器名称或证书链 | 推送锁定 RADIUS 名称和 CA 的配置文件 |
| 角色变更后，一台笔记本电脑无法访问网络 | EAP-TLS | 证书已被吊销或设备已从 MDM 中移除 | 确认吊销状态并仅对该设备重新注册 |
| 周一整个团队都被锁在网络之外 | EAP-TLS | 证书同时到期或续订重叠期太短 | 在到期前分阶段续订并保留恢复路径 |
| 仅在完全重新认证时漫游感觉很慢 | 结合内部 EAP-TLS 的 PEAP | 两次 TLS 握手 | 优先使用恢复机制、PMK 缓存或 802.11r；除非必要，避免使用内部 EAP-TLS |
| 仅在单个站点出现随机拒绝 | 两者皆有可能 | RADIUS 往返时间或证书链获取问题，而非 EAP 名称问题 | 在更改认证方式之前，先测量 RTT 和 95% 位数的关联到 IP 时间 |
某个星期的漫游缓慢通常是 RADIUS 距离远或证书链拉取问题导致的，并非证明你选错了 EAP 类型。
分配各个群体并验证隔离效果
同一栋大楼内可能包含员工笔记本电脑、会议室访客、承包商 Mac 和收银机。它们不应共享同一种凭据类型。请规划好每个群体，在您现有网络旁试点一个站点，并在推广该设计前评估工单和认证日志。
| 人群分类 | 建议使用 | 切勿使用 | 原因 |
|---|---|---|---|
| 经 MDM 管理的员工与特权用户 | 基于 WPA-Enterprise SSID 的 EAP-TLS | 共享 PSK 或 PEAP | 证书身份识别、按分组划分 VLAN，且禁用账号时自动终止访问权限 |
| 短期停留的访客与来宾 | 基于访客 VLAN 的 Captive Portal 或 Passpoint | 在服务台进行 PEAP 或 EAP-TLS 注册 | 无需证书生命周期管理，也不存在可被钓鱼的目录密码 |
| 未经管理的笔记本电脑与承包商设备 | 仅限强制服务器验证的 PEAP-MSCHAPv2 | 在无法注册或更新证书时使用 EAP-TLS | 密码已存在，但配置文档必须检查 RADIUS 证书 |
| 打印机、电视、收银机、监控摄像头和传感器 | 具有独立 VLAN 的单设备 PSK | EAP-TLS 或共享 PEAP 密码 | 此类设备通常无法存储证书，且共享密钥难以轮换 |
| 同一建筑内的混合场所 | 按身份跨不同 VLAN 进行隔离 | 所有人共用一个 SSID 和一种认证方式 | 员工、访客与物联设备的安全风险各不相同，不应共享凭据类型 |
哪些群体保留密码认证，哪些绝不能保留
托管员工和特权用户在 WPA-Enterprise SSID 上使用 EAP-TLS。客房服务、前台和运营员工可以通过 MDM 的 SCEP 使用证书进行身份验证，根据目录组切入对应的 VLAN，并在账户被禁用时立即失去访问权限。共享 PSK 或 PEAP 密码只会让您试图淘汰的隐患卷土重来。
访客和来宾应保留在 Captive Portal 或 Passpoint 的访客 VLAN 上。切勿在前台分发证书，也不要将其置于 PEAP 上。这种场景下无生命周期可供运行，且存在您不希望被钓鱼获取的目录密码。Passpoint 配置文件可允许访客在下一次访问时自动重新连接，无需重新申请凭据。
未托管的笔记本电脑和承包商可以保留使用 PEAP-MSCHAPv2，但前提是配置文件强制进行服务器验证。如果您无法为其注册或更新证书，EAP-TLS 会导致其无法接入。如果您无法强制进行服务器检查，密码暴露风险将远远超过便利性，此类设备根本不应接入员工 SSID。
打印机、电视、收银机、EPOS、CCTV、传感器和门禁控制器可获得单设备 PSK 以及各自的 VLAN。它们通常无法存储证书。共享的 PEAP 密码会重新引入共享密钥问题。PCI DSS v4.0.1 Req 2.3.2 要求在知晓无线密钥的任何人离职时更改密钥，而共享密钥使这一点变得不切实际。xPSK 正适合这些设备。客房电视、温控器和收银机应当属于访客永远看不到的结合了密钥的 VLAN。
先在一个场所验证效果
将新设计应用到该站点现有的接入点上，与现有的网络并行运行。请通过工单和审计凭证来评估效果，而不是仅凭演示登录。
要求提供记录每次接受和拒绝的认证日志，包含身份、设备、MDM 注册状态、方法、接入点、SSID、站点、VLAN、角色、原因和时间。该日志同时也是满足 ISO 27001 访问与日志记录控制以及 PCI-DSS 要求 8 和 10 的证据集。在没有 MDM 的情况下，先锁定 PEAP 配置，并仅针对已管理的用户群计划证书发放。
我们可以在每个场所将这种划分作为三个网络运行。宾客使用 Captive Portal，包含场所现有的 PMS 客房验证。员工使用 EAP-TLS 或 Passpoint。物联网设备使用独立设备密钥。Cloud RADIUS 根据身份将每台设备分配到正确的网络和 VLAN，并拒绝已禁用账户的离职人员。摆脱共享员工密码的迁移路径，与我们在 将多场所员工 WiFi 迁移至 802.1X 指南中所述的路径一致。
建议从托管的员工 SSID 以及收银机的单设备密钥开始试点，并让承包商继续使用经过验证的 PEAP 配置文件，直到注册流程完全落地。在架构图中对所有人使用单一认证方法看起来更整洁，但在实际现场可能会以三种不同的方式出问题。
Purple Access 在您现有的接入点上为员工 WiFi 运行基于证书的认证，并为物联网设备提供单设备密钥，使 eap tls 与 peap 的选择成为针对不同人群的精准策略，而非影响整个企业网络的孤注一掷。您可以在单个站点上验证开放网络、安全网络和 xPSK，并在扩大推广范围之前评估工单和认证日志。访问 Purple Access 以规划您的员工、访客和设备网络。
