iPhone での IKEv2 証明書設定：手動登録と管理登録の選択

ゲートウェイの証明書ツールが既定で使うという理由だけで RSA を選ぶのは、本当に重要な問い――この iPhone 群をどう登録するのか――の前に下す判断です。ユーザーが自分で入力する接続と、管理側が配信する構成プロファイルでは露出する設定が異なり、一部の証明書選択肢はどちらか一方の経路にしか存在しません。順序を正せば証明書計画は短くなり、誤れば端末が使わない資格情報を発行することになります。各手順が次の手順で選べる範囲を狭めるため、以下の手順は順序として扱ってください。

第一ステップ：登録経路を選ぶ

手動設定では、ユーザーがサーバーアドレスを入力し、認証方式を選び、インターフェースが許す資格情報を入力します。管理登録では、プロファイルがアドレス、識別子、資格情報ペイロードへの参照を保持します。管理経路は手動画面では表現できない組み合わせを表現できるため、証明書の判断はこの選択の後に行うべきで、前ではありません。

どちらの経路でも端末を認証できます。設定できる内容と ID の所有者が異なるため、管理プロファイルと手動の資格情報入力を混ぜずに、どちらかを意識して選んでください。

第二ステップ：選んだ経路のアルゴリズムを選ぶ

手動で構成した iPhone では、strongSwan の iOS 相互運用メモが、手動クライアントが ECDSA サーバー証明書を受け付けない可能性があるとして RSA サーバー証明書を推奨しており、同じメモは macOS を別扱いしています。これは対応クライアント群への指針として読み、Apple 製端末に関する恒久的な法則とは考えないでください。管理プロファイルには余地が多く、ペイロードとゲートウェイの両方が対応していれば、ECDSA クライアント ID を含む証明書種別を明示的に選べます。

何かを展開する前に、実際に対応している iOS バージョンを検証してください。最新リリースの実験用端末は、古い端末を含む配備群を表しておらず、実験室で動くアルゴリズムでも現場で最も古い端末では失敗することがあります。バージョン範囲は記憶ではなく端末管理から取得してください。配備群が複数のリリースにまたがる場合は、手動インターフェースが最も制約される最も古いものを先に試験してください。

第三ステップ：プロファイルの各フィールドを別物として読む

似た名前のキーがいくつかあり、それぞれ別のオブジェクトを表します。リモートアドレスは端末が発信するホストです。リモート識別子は、ゲートウェイが提示することを期待する IKE ID です。ペイロードの証明書参照はクライアント資格情報を指し、証明書種別フィールドは IKEv2 のマシン認証に使う種別を選びます。語が重なっていても、そのどれも CA の署名アルゴリズムではありません。

Apple の IKEv2 ペイロードリファレンスは、RSA を既定の証明書種別として明示的な ECDSA 種別とともに挙げ、発行者名キーを特定の認証設定に結び付けています。動作している配備からキーを一つコピーするのではなく、選んだ方式のリファレンスでこれらの関係を読んでください。

第四ステップ：ゲートウェイ ID を証明書に一致させる

たとえば vpn.example.com のような明示的なゲートウェイ名を使い、一致するサブジェクト代替名をサーバー証明書に入れてください。strongSwan の Apple 向けガイダンスはサーバー認証の拡張鍵用途も想定しており、RSA と ECDSA のどちらを選んでもそれは変わりません。アルゴリズムは名前の不一致、欠けた EKU、不完全なチェーンを修復できません。

信頼アンカーの配布は、ID を主張することとは別の作業です。端末には検証できる証明書チェーンが必要で、証明書に実際に入れた名前を期待するよう構成する必要があります。

別のプラットフォームが接続に成功したことは、そのプラットフォームの検証ルールの証拠であり、端末のルールを緩めてよい許可ではありません。文書化された理由がない限り、クライアント間で検査を同一に保ってください。

第五ステップ：クライアント ID と CA 信頼を分ける

クライアント証明書とその秘密鍵は、端末が信頼する CA 証明書と同じオブジェクトではありません。CA 証明書を PKCS#12 ID の中に束ねても、対応するすべての端末に信頼アンカーとして自動的にインストールされるわけではないため、信頼の配布は独自の検証を伴う別の手順として扱ってください。

設計が代わりにパスワードベースの EAP を使う場合、端末には想定されたアカウント認証とサーバー検証が必要です。その経路は、失敗時の挙動がはるかに悪い別の設計であるため、一つの共有クライアント秘密鍵を配備群全体に配ることを正当化しません。

更新と失効を念頭に置き、誰がクライアント資格情報を再発行するのか、プロファイルをどう更新するのか、紛失した端末をどう切り離すのかを決めて計画を終えてください。検証したプロファイルのバージョンと端末のバージョンを記録することが、次の証明書更新を日常的な変更にします。