IKEv2 证书 SAN：身份校验为何失败

证书已链接到受信任的 CA，日期也没问题，对端却仍以身份错误拒绝完成阶段 1。可达性和有效签名只是 IKEv2 客户端检查内容的一半。另一半是它预期的身份是否出现在证书的正确字段中，而这个预期由配置文件决定，不是由证书文件名决定。

症状的形态总是一样

连接配置文件从主机名改为 IP 地址，或从带 DNS 名称的证书续期为只带地址的证书，于是隧道停止协商。网络路径上没有任何变化。客户端到达对端、收到证书，却拒绝对端身份，因为它被告知要预期的标识符并未出现在它接受的字段里。续期是常见诱因，因为替换用的证书往往来自与被替换证书不同的模板。

随后双方记录下的信息都毫无用处，这就是故障常被当成证书问题的原因。客户端日志可能写出它想要的身份，那个名字才是你要的线索，而不是到期日期。

匹配标识符的类型，而不只是值

dNSName SAN 与 iPAddress SAN 是字段不同、匹配规则也不同的两类，因此把 203.0.113.10 当作 DNS 字符串的证书，无法满足期待 IP 身份的客户端。现代校验器大多忽略通用名称，所以证书详情里那个友好的标签并不能证明什么会匹配。如果在排障过程中把主机名换成了地址，在核实之前应假定预期身份也跟着变了。把配置文件中的字符串与 SAN 中的字符串逐字符比较，末尾多一个点或一个空格就足够导致不一致。

通配符只是 DNS 的便利，且遵循自己的匹配规则，这也是基于 IP 的配置文件绝不应依赖它们的另一个原因。

找出每个客户端把预期存在哪里

在 strongSwan 中，用于与证书比较的值来自对端身份设置：rightid（传统配置），或 swanctl 中远程连接节的 id。它关于 Apple IKEv2 互操作性的文档在这里很有用，因为文中说明了由配置文件驱动的客户端所遵循的身份约定，而这些约定解释了一类在链路上看似随机的错配。

Apple 配置描述文件带有远程标识符字段，客户端检查的是那里的值，而不是连接设置中的服务器地址。Windows 和各设备客户端各有自己的字段与默认值，默认值常常跟随你输入的地址。两个字段不一致时，客户端真正读取的那个才会生效，而它很少是你编辑过的那个。

有意识地修配置文件或证书

在改动任何东西之前，用获准的工具检查对端证书，并列出 SAN 条目及其类型。这一步不需要私钥，也不需要上传，几秒钟就能定论。如果部署想要的是一个 DNS 身份，证书就必须以 dNSName 条目承载它；如果部署想要的是一个地址，证书就需要一条恰好对应该地址的 iPAddress 条目。

如果证书错了，就带着具体的预期标识符向运营方申请更正后的证书。如果配置文件错了，就改配置文件，别动证书。关掉身份校验会让错误消失，同时也会去掉“隧道正在与你预期的对端通信”这一检查。

按客户端平台记录预期身份，因为某个客户端自动推导出的值，在另一个客户端上可能需要显式填写。

给续期申请四项事实

写下预期标识符及其类型、当前证书实际拥有的 SAN 条目、执行检查的客户端与版本，以及确切的错误文本。用这四行构成的续期申请，第一次就能拿到正确的证书，而不是又一个文件名同样眼熟的证书。