Android IKEv2 の信頼エラー: ルートではなく中間 CA を送る

端末は接続を拒否し No trusted RSA public key found for vpn.example.net と表示しますが、同じゲートウェイ証明書は同じネットワークのノート PC からは動作します。証明書を再発行したくなりますが、その前に三つの失敗のどれかを確定してください。証明書の中身に関わるのは一つだけです。

一つのメッセージの背後にある三つの失敗

Android はゲートウェイ証明書から VPN プロファイルで選んだ CA までのチェーンを組み、サーバー名をプロファイルと照合します。通知は結果を示すだけで、段階は示しません。信頼の失敗は交換で渡された証明書ではチェーンを完成できなかったこと、識別の失敗はチェーンは有効だが名前が一致しないこと、アルゴリズムの失敗は端末やプロファイルが鍵種別や署名を受け入れないことを意味します。

順に修復を試すのではなく証拠で判断します。デーモンのログ レベル 2 での一度の試行でどの行かが分かり、決して誤っていなかった証明書を再発行するより安く済みます。

まず決める: チェーン全体が届いたか

strongSwan はその接続用に設定された証明書を送り、中間証明書は別の資格情報です。デーモンがペイロードに載せる前に CA 証明書として読み込む必要があるため、サーバー証明書が中間で署名され、ルートが信頼の基点で、中間が CA のビルドディレクトリにしかない構成では、まさにこの失敗になります。

swanctl 構成なら swanctl --list-certs、旧 starter なら ipsec listcerts でデーモンの保持内容を確認します。中間はルートの上に CA 証明書として現れるべきです。無ければクライアント側の設定では解決せず、あれば次の問いに進みます。

次に送信されるかを確認します。swanctl.conf のリファレンスにある send_cert は、既定の ifasked が相手の要求時のみ送信し、always は常に送信します。旧式の同等は ipsec.conf の leftsendcert=always です。この設定は送信を制御するもので可用性ではなく、読み込まれていない中間は補えません。

チェーンが短い場合はデーモンが探す場所に中間を置く

中間はリーフの隣ではなく CA ディレクトリに置きます。ipsec.conf の構成なら /etc/ipsec.d/cacerts、swanctl なら /etc/swanctl/x509ca、またはパッケージが代替するパスです。設定を再読み込みして証明書を再列挙します。バンドルで送る版もありますが、CA ディレクトリが版やパッケージをまたいで移植可能です。

クライアント側でも確認します。端末は交換が運んだものだけを見るため、レベル 2 のログに送信証明書の中間が現れるはずです。ログに出ても失敗するなら別の行であり、CA ファイルの調整では結果は変わりません。

チェーンが完全なら証明書の編集を止める

識別の失敗は VPN プロファイルの名前と証明書の名前の不一致です。Android は設定したサーバー識別を検証した証明書と比較するため、証明書がホスト名を示すのにプロファイルがアドレスを指す場合や、証明書が覆わないホスト名をプロファイルが指す場合は、チェーン検証が成功しても失敗します。誤った側を直し、変更時は両者を揃えます。

アルゴリズムの失敗はチェーンが有効で名前が一致するときに現れます。Android の版により受け入れる鍵種別や署名方式が異なり、プロファイル種別自体が選択肢を制限します。古い組み合わせなら証明書の破損と決める前に端末の対応を比べます。ログではハンドシェイクが信頼の場合より進み、チェーンが問題でなくなったことが分かります。

中間を端末のユーザールートとして入れない

欠けた中間をユーザー証明書として端末に入れると警告は消えますが、ユーザーが入れたルートを受け入れる全アプリの信頼モデルが変わります。次のクライアントに響く配送の不具合も隠し、ゲートウェイは将来の端末すべてに不完全なチェーンを送り続けます。恒久策はサーバー側で一度だけ行います。

変更記録では三つの判断を分けて残します。どの証明書を送ったか、どの識別を比較したか、どのアルゴリズムを交渉したかです。常に完全なチェーンを送るゲートウェイ、証明書を正しく名指すプロファイル、艦隊が支える鍵種別の三つがこの失敗のすべてです。