IKEv2 有两个签名：证书签名与 IKE_AUTH 签名
CA 为证书签名，对端则以自己的方案为 IKE_AUTH 交换签名。请分别从各自的字段读取，并把两者都记录下来。
你的工单说证书是 SHA-256，网关日志却写着另一种签名算法，而且已经有人起草了重新签发 CA 的申请。在这份申请送出之前，请先把两个签名分开：一个是签发者对公钥盖下的印章，另一个是 对端在 IKE_AUTH 中证明自己持有匹配私钥。两者由不同的部件选择，也允许彼此不同。从各自所在的位置读取它们，只需要两条命令和一张表。
从证书中读取签发者的签名
CA 把自己的签名加在身份与密钥的绑定之上。这个签名记录的是 CA 在签发时做了什么，而不是主体在连接时会做什么，因此它的算法描述的是 CA 自己对哈希与密钥的选择。某类主体密钥完全可以落在另一类 CA 密钥之下，两者并不矛盾；CA 密钥轮换属于日常操作，而不是故障。读这两个字段，你就拿到了清点工作的一半：
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"把这两个标签分别记为独立条目。第一个描述 CA，第二个描述主体的密钥，两者都不能预测在线签名。
从 IKE 交换中读取在线签名
在认证过程中，每个对端用自己的私钥为交换数据签名，对侧则依据证书的身份、信任链与策略核验这份证明。对 RSA 而言，填充与哈希都属于这套在线方案，所以更长的密钥或崭新的 SHA-256 证书本身并不能为认证签名选择 RSA-PSS。协商出的方法会出现在守护进程日志或连接列表中，绝不会出现在证书里。要分别询问两端协商了什么，因为两个方向可以不同。
ipsec statusall | grep -i "auth\|proposal"当一端说出另一端无法产生的方案时，你就找到了工单所指的那个不一致。重新签发 CA 是错误的修复方式，因为出问题的从来不是证书。
RFC 7427 改变了什么，又没有改变什么
原始方法在 RFC 7296 中按算法组合编号。后来的 RFC 7427 签名扩展 增加了一种通用的 Digital Signature 方法，并带有签名哈希支持的通告，因此新的哈希不必再占用一个方法号。这是协商出来的，而不是假定的：对端不会因为自己的库能解析同样的证书就获得该扩展；只实现原始方法的对端，会迫使网关保留其中一种。这是带有兼容性代价的策略取舍，而不是缺陷。
支持情况按方向、按连接而定，所以请测试眼前的这个构建，而不是相信某个产品系列的声明。三年前写下的能力矩阵，描述的是三年前的构建。
在清单里写下四行
终结争论的记录有四行，每一行来自不同的位置，也由不同的人修改。在做任何决定之前先把它填好，因为真正出错的那一行才决定该修什么。
| 对象 | 从哪里读取 | 由谁修改 |
|---|---|---|
| 证书签发者的签名 | 证书的 Signature Algorithm 字段 | CA 运维人员，签发时 |
| 主体的公钥 | 证书的 Public Key Algorithm 字段 | 生成主体密钥的人 |
| IKE 认证方案 | 守护进程日志或连接列表，auth 与 signature-hash 通告 | 两端对等体上的 IKE 配置 |
| IKE 与 ESP 保护算法 | 连接的提议列表 | IPsec 配置，按方向 |
每一行都带有各自的兼容性后果。更换 ESP 加密算法不会改变签发者的签名，放松 CA 校验也不会凭空增加对端从未协商过的在线方法。当工单声称签名不一致时，真正出错的那一行几乎从来不是第一行。
在不削弱 PKI 的前提下处理遗留情形
较旧的对端可能只提供你策略已不允许的方案。选项是为其设置有时限的兼容性例外、更新客户端，或只针对该对端改用另一种认证安排。围绕更弱的证书签名重建 PKI 并不能修复在线交换中的限制，还会削弱所有信任同一 CA 的其他服务。请记录你改了哪一行，以及例外何时到期。
然后从头再跑一遍那两项读取，因为一行的改动可能改变另一行协商出的结果。整份清单不过两条命令和一张表，无论对端是路由器、笔记本电脑还是设备，工作都一样。