IKEv2 証明書の SAN：識別情報の検証が失敗する理由

証明書は信頼できる CA に連鎖し、日付も問題ないのに、ピアは識別情報エラーでフェーズ 1 の完了を拒否し続けます。到達性と有効な署名は、IKEv2 クライアントが確認する内容の半分にすぎません。残りの半分は、期待する識別情報が証明書の正しいフィールドに現れているかどうかであり、その期待は証明書のファイル名ではなくプロファイルによって設定されます。

症状はいつも同じ形です

接続プロファイルがホスト名から IP アドレスに変更されたり、DNS 名を持つ証明書からアドレスだけを持つ証明書に更新されたりすると、トンネルはネゴシエーションを停止します。ネットワーク経路には何も変わっていません。クライアントはピアに到達し、証明書を受け取り、期待するよう指示された識別子が受け入れるフィールドに表れていないため、ピアの識別情報を拒否します。交換用の証明書は置き換える元とは別のテンプレートから来ることが多いため、更新が通常のきっかけです。

その後、双方は役に立たないログを残すので、障害は通常証明書の問題として報告されます。クライアントのログには望んでいた識別情報が記録されることがあり、その名前こそが手がかりであり、有効期限ではありません。

値だけでなく識別子の種類を一致させる

dNSName SAN と iPAddress SAN は異なるフィールドで一致規則も異なるため、203.0.113.10 を DNS 文字列として持つ証明書は、IP 識別情報を期待するクライアントを満たしません。最近の検証器は一般名をほとんど無視するので、証明書の詳細にある分かりやすいラベルは、何が一致するかの証明になりません。トラブルシューティング中にホスト名をアドレスに置き換えた場合は、確認するまで期待する識別情報も一緒に移ったと想定してください。プロファイルの文字列と SAN の文字列は、末尾のドットや余分な空白だけでも食い違うため、一文字ずつ比較してください。

ワイルドカードは DNS 専用の便宜機能であり、独自の一致規則に従うため、IP ベースのプロファイルが決してそれらに頼るべきでないもう一つの理由になります。

各クライアントが期待をどこに保存するかを見つける

strongSwan では、証明書と比較される値はピア ID 設定に由来します：rightid、または swanctl のリモート接続セクションの id。Apple IKEv2 の相互運用性に関するドキュメントは、プロファイル駆動型クライアントが使う識別情報の慣例を明記しているのでここで役立ち、その慣例は、回線上ではランダムに見える不一致の一種を説明します。

Apple の構成プロファイルにはリモート識別子フィールドがあり、そこにある値がクライアントの確認対象であり、接続設定のサーバーアドレスではありません。Windows やアプライアンスのクライアントにはそれぞれ独自のフィールドと既定値があり、既定値は入力したアドレスに従うことがよくあります。二つのフィールドが食い違う場合、クライアントが実際に読む方が勝ち、それは編集した方であることはまれです。

プロファイルか証明書を、意図的に修復する

何かを変更する前に、承認されたツールでピア証明書を検査し、SAN エントリを種類とともに一覧にしてください。その検査には秘密鍵もアップロードも不要で、数秒で問題を決着させます。展開が一つの DNS 識別情報を意図しているなら、証明書はそれを dNSName エントリとして持つ必要があり、展開がアドレスを意図しているなら、証明書にはまさにそのアドレスの iPAddress エントリが必要です。

証明書が間違っている場合は、具体的な期待識別子を添えて運用者に修正版を依頼してください。プロファイルが間違っている場合は、プロファイルを直し、証明書はそのままにします。識別情報の検証を無効にするとエラーは消えますが、トンネルが意図したピアと通信しているという確認も失われます。

あるクライアントが自動的に導き出す値が別のクライアントでは明示的に必要になることがあるため、クライアントのプラットフォームごとに期待する識別情報を文書化してください。

更新依頼に四つの事実を添える

期待する識別子とその種類、現在の証明書が実際に持つ SAN エントリ、確認を行っているクライアントとバージョン、正確なエラーテキストを書き留めてください。この四行から作られた更新依頼は、同じ見慣れたファイル名の別の証明書ではなく、最初から正しい証明書を手に入れます。