IKEv2 には 二つの署名がある：証明書と 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 方式を追加するため、新しいハッシュに専用の方式番号は要らなくなった。これは折衝するものであり、前提にするものではない：ライブラリが同じ証明書を解析できるからといってピアが拡張を得るわけではなく、元の方式しか実装しないピアがいれば、ゲートウェイはそのうち一つを残さざるを得ない。これは互換性のコストを伴うポリシーの取引であり、欠陥ではない。

対応は方向ごと、接続ごとに決まるので、系列単位の主張を信じるのではなく、目の前のビルドを試すこと。三年前に書かれた対応表は三年前のビルドを記述している。

棚卸しに四行を入れる

議論を終わらせる記録には四行あり、各行は別の場所から読み取られ、別の人物によって変更される。誤っている行こそが対処法を選ぶため、何かを決める前に記入すること。

各行はそれぞれの互換性の帰結を伴う。ESP の暗号を変えても発行者の署名は選ばれず、CA の検証を緩めてもピアが折衝していないオンライン方式は増えない。チケットが署名の食い違いを主張するとき、本当に誤っている行はほとんど最初の行ではない。

PKI を弱めずに旧環境の事例を決着させる

古いピアが、ポリシー上もはや許されない方式しか提示できないことがある。選択肢は、期限付きの互換性の例外、クライアントの更新、そのピアだけの別の認証構成である。弱い証明書署名を中心に PKI を作り直しても、オンライン交換の制約は直らず、同じ CA を信頼する他のすべてのサービスを弱める。どの行を変えたか、例外がいつ切れるかを記録すること。

一つの行の変更が別の行で折衝される内容を動かしうるため、二つの読み取りを最初からやり直すこと。棚卸しの全体はコマンド二つと表一つであり、ピアがルーターでもノート PC でも機器でも作業は同じである。