strongSwan send_cert：IKE 证书何时发送

网关会记录与证书相关的认证失败，而第一反应往往是给接收方再加一个 CA。这假定证书已经送到并被拒绝。另一种可能是它从未被发送，而这由发送方的连接策略决定。在改动信任之前，先弄清楚两者中究竟发生了哪一种。

send_cert 到底控制什么

证书认证需要对端的终端实体证书通过 IKE 交换或事先配置到达另一侧。在 swanctl 中，连接设置 send_cert 决定本端是否携带自己的证书载荷：never、always 或 ifasked。默认的 ifasked 会在对端请求证书时作为响应发送。请求证书是另一项设置，因为向另一侧索要其证书与提供自己的证书并不是同一件事。

较旧的 ipsec.conf 部署使用 leftsendcert 和 rightsendcert，这些名称对应本端与远端角色，而不是直接对应 swanctl。

在改动连接之前，先读一次尝试

要根据一次受控尝试来诊断，而不是凭涉及证书的整体印象。策略和活动关联都可以查看。

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

连接列表显示配置的 send_cert 值，SA 列表显示哪些连接真正建立。日志补充协商细节：是否收到证书请求，以及是否发出了证书载荷。笼统的认证失败并不能说明存在投递问题，因此在得出结论前要找到具体交换。记下这次尝试的时间戳，让日志窗口覆盖整个握手过程。

接收方的信任是另一项决定

投递与信任是两种不同的属性，修好其中一个并不等于修好另一个。接收方必须持有预期的信任锚、收到可用的证书链，并与预期的对端身份匹配。缺少中间证书的终端实体证书，仍然无法通过严格的链式校验。反过来，安装 CA 完全不会迫使对端发送自己的证书。

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

检查会显示证书由哪个颁发者签发、何时过期，而接收方的信任锚必须与之对应。应当信任部署自有的颁发 CA，而不是链上的每个中间证书，因为把每个中间证书都提升为根会远远扩大信任范围。保持身份校验开启，因为只有在关闭校验时才成功的连接算不上修复。若证书链不完整，应修复配置，而不是改动发送方策略。

只在有证据时才改动发送方

当日志显示证书从未发送、而接收方确实请求过时，把 send_cert 设为 always 对该连接就是有依据的改动。在 swanctl 配置中应用它，重新加载连接，并建立新会话，而不是复用现有 SA。确认证书载荷现在出现，且接收方按预期信任锚接受它。如果没有任何变化，故障其实在信任一侧，发送方设置并不是原因。

把观察到的交换、信任锚和由此得到的验证结果写入变更记录。无法用这些内容描述的证书修复，只是巧合。