网关证书没问题：IKEv2 PEAP 登录为何仍然失败

你的 VPN 网关证书有效，证书链也能验证通过，IKEv2 客户端却仍然拒绝登录，并给出关于证书有效期区间的提示。第一反应通常是重新签发网关证书或更换 EAP 方法，而这两种做法往往都不对。这次登录尝试携带两个彼此独立的服务器身份：IKE 使用的网关证书，以及终结 PEAP 的那一方所出示的证书。其中一个没问题，另一个才是客户端停下的原因。

两个身份，一次登录尝试

VPN 配置文件里的证书属于 IKE 交换：它证明在配置的 IKE 策略下，网关就是配置文件所指名的对端。这里失败的证书属于另一段对话，即 PEAP 与负责验证用户身份的一方建立的 TLS 会话，而那一方往往是 NPS 之类的 RADIUS 服务器，而不是网关本身。第三项校验是用户凭据，它在那个会话内部完成。有效密码无法修复已过期的服务器证书，有效的网关证书也不能为 PEAP 端点作担保。

这种分层解释了为什么证书错误会出现在一个只配置过网关证书的地方。它也解释了为什么重新签发那张证书毫无作用。

结合阶段来读日志行

找到写明原因和日期的消息。主体错误旁边出现有效期区间的抱怨，意味着服务器拒绝了交给它的证书，而不是用户拒绝了登录。然后再定位阶段：strongSwan 的 charon 日志会在 EAP 交换开始之前显示 IKE_SA .* established，因此该行之后的证书错误属于 EAP 身份，而之前的错误则指向网关。Windows 客户端连接面板里的阶段文字也说明了同样的事。

在触碰任何证书之前，先检查客户端时钟。时间偏差数小时的设备会产生与真正过期证书相同的有效期错误。校准时钟只需五秒钟，而替换一张从来不是问题的证书则意味着一次中断。

弄清楚哪个端点终结了 PEAP

在网关加 RADIUS 的架构中，网关转发 EAP 而不终结它。strongSwan 的 eap-radius 插件把交换交给 RADIUS 服务器，由后者持有 PEAP 的 TLS 会话及其证书。把一次失败的尝试在两份日志中对齐，确认究竟是哪个进程为那个会话选择了证书。

对 NPS 而言，证书必须位于本地计算机存储中，带有服务器身份验证用途，与客户端期望的名称匹配，并且服务账户能够读取。Microsoft 对 NPS 的证书要求列出了这些条件。其他 EAP 服务器有各自的选取规则，所以不要把 NPS 的特殊做法照搬到 FreeRADIUS 部署中，反之亦然。两种情形都成立的规则是：终结 PEAP 的端点才拥有你即将更换的那张证书。

在 EAP 终结的地方更换证书

在终结 PEAP 的端点上，通过受支持的流程续订或更换证书，保留服务器身份验证用途和期望的名称。把完整证书链安装到服务查找的位置，并授予服务访问私钥的权限。重启或重新绑定服务，因为许多服务会把旧证书留在内存里并继续出示它。复制到机器上的文件并不能证明服务实际出示的是哪张证书。

把下一次尝试与服务自身的日志对齐，或者检查会话所出示的证书，以此确认更改。如果那份日志仍显示旧的指纹，说明重启没有生效。

不要以为目录里最新的文件就是正在使用的那个。名字正确但权限错误的副本什么也改变不了。判断更改要看实际出示的身份，而不是文件时间戳。

不要做的事

不要为了绕过错误而关闭 PEAP 验证，也不要强制使用更弱的内部方法。那会改变策略，并移除当初抓到过期证书的服务器身份验证属性。你是用一项有效的检查换来了一个可用的连接，而下一次证书过期时将没有任何提示。

不要把另一个操作系统的成功连接当作证书可以接受的证据。那个客户端可能使用不同的 EAP 方法、不同的信任存储，或者根本不做服务器验证，所以它的成功并不能说明这里失败的那项检查。保留一项刻意的否定测试，例如名称错误的证书或不受信任的证书链，让它按预期失败。如果这项测试现在通过了，说明你移除了一项检查，而不是修好了证书。写下是哪个身份失败了，以免下一个人又从网关证书开始。