Mac IKEv2 ECDSA：クライアントに属する証明書の種類はどれか
Mac では、IKEv2 設定の ECDSA256 はローカル ID 証明書を指し、ゲートウェイや発行者の署名ではありません。選ぶ前に各役割を読んでください。
macOS では、IKEv2 クライアント設定の ECDSA 選択は狭い問いに答えます。どの証明書が Mac の ID を証明するか、という問いです。ゲートウェイ証明書、クライアント証明書を発行した署名、トンネルの暗号化提案は記述しません。これら四つの役割を一つの互換性の問いとして扱うと、正しいローカル設定がサーバー側の不一致のせいにされます。判断は小さいものですが、その根拠となる証拠は正確でなければなりません。
このフィールドが指す証明書は一つ：ローカル ID
Apple の Network Extension API は、クライアント資格情報の証明書タイプを公開しており、NEVPNIKEv2CertificateType.ECDSA256 を含みます。これは ECDSA p-256 証明書タイプとして文書化されています。このプロパティは identityReference または identityData で提供される証明書に適用されます。
つまり判断の対象は、Mac が提示する証明書と、それに付随する秘密鍵です。そのリーフ証明書の公開鍵に一致するタイプを選び、サポートされる仕組みで ID を提供してください。Mac に ID 用の使用可能な秘密鍵がなければ、タイプの選択で接続は救えません。
管理プロファイルでは、IKEv2 ペイロードの CertificateType と、PayloadCertificateUUID のような証明書参照を組み合わせて同じ判断を行います。これらのフィールドには前提条件と対象 OS リリースのスキーマがあり、プロファイルにコピーした裸のタイプ値はインストールできません。設定ウィンドウがすべての API オプションを表示するとも限りません。配布前にそのリリースのペイロード前提条件を確認してください。
証明書のラベルではなく役割で判断する
変更しようとしているフィールドを読み、どの証明書を指しているかを問いかけてください。証明書ビューアのラベルはサブジェクト、発行者、署名アルゴリズムを混在させており、クライアント ID の選択に関わるのは一つだけです。
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
証明書ビューアが CA の ECDSA 署名を表示していても、それは発行者の署名鍵を表します。クライアント自身の鍵は依然として RSA かもしれず、タイプのフィールドは署名の行ではなくクライアント鍵に従うべきです。この一つの混同が「ECDSA を設定したのに接続が失敗する」という報告の多くを説明します。何かを変える前に、リーフの鍵タイプとプロファイルで選択したタイプを比較してください。
リーフが特定できれば判断は簡単になります。p-256 のクライアント鍵なら ECDSA256、別の鍵なら別のサポート対象タイプです。クライアント証明書とその鍵が一致しない場合は、VPN プロファイルを変える前にその組を修正してください。
ゲートウェイ証明書は別の判断
ゲートウェイは自身の証明書を提示し、Mac はトラストアンカーと期待する名前に対してそれを検証します。その証明書が ECDSA、RSA、その他の鍵タイプのどれを使うかはサーバーの性質であり、クライアント ID 設定の性質ではありません。
ECDSA クライアント証明書のローカルなサポートは、すべてのゲートウェイ証明書、曲線、サーバー認証設定が相互運用できることを証明しません。サーバーの ID、そのチェーン、IKE 認証方式を別々の入力として確認し、実際に配布するプロファイルでテストしてください。
ゲートウェイ証明書が問題なら、症状は通常、ID 選択時ではなくピア検証時に現れます。クライアントの種類を変える前に失敗の段階を読んでください。信頼の失敗とクライアント鍵の不一致は同じ修正を共有しません。
発行者の署名と鍵合意グループはクライアントの種類ではない
X.509 はサブジェクトの公開鍵と発行者の署名を別のフィールドに保持します。サブジェクト公開鍵情報は証明書内の鍵を表し、署名アルゴリズムは CA の鍵と署名操作を表します。証明書タイプ設定に一致するのは前者だけです。
IKE と Child SA の提案は別の軸です。ECDSA 証明書タイプは ESP 暗号化の選択ではなく、鍵合意グループを変えても証明書タイプは選ばれません。プロファイルには有効な提案と誤った ID タイプが入ることも、正しい ID タイプとピアが拒否する提案が入ることもあります。
変更記録では三つの行を分けてください。ID 証明書と鍵、ゲートウェイの信頼入力、提案のアルゴリズムです。これらを一つの「暗号設定」メモにまとめると、次の失敗を帰属できなくなります。
設定したフィールドで判断を検証する
プロファイルが実際に参照する ID を確認し、その参照先の証明書に期待する公開鍵と使用可能な秘密鍵があることを確かめてください。UI に表示されるタイプ、参照される証明書、デバイス上の鍵は一致している必要があります。
次にゲートウェイの入力を確認します。期待するサーバー名、トラストアンカー、IKE 認証方式です。最後に接続し、ハンドシェイクがどこで止まるかを読みます。ID 交換前の失敗はこの設定から離れた原因を示し、ピア検証での失敗はゲートウェイ側を示します。
選んだタイプ、ID 参照、ゲートウェイ証明書のサブジェクトを配布メモに記録してください。次のプロファイル更新でどれでも変わりうるので、三つの名前付き値は設定パネルのスクリーンショットより速く比較できます。