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 を再利用せずに新しいセッションを確立してください。証明書ペイロードが今表示され、受信側が想定されたアンカーに対して受け入れることを確認してください。何も変わらないなら、障害は結局信頼側にあり、送信側の設定は原因ではありませんでした。

観察した交換、アンカー、そこから得られた検証を変更記録に書いてください。その言葉で説明できない証明書の修正は偶然です。