ゲートウェイ証明書は正常なのに IKEv2 PEAP ログインが失敗する理由

VPN ゲートウェイの証明書は有効で、チェーンも検証されており、それでも IKEv2 クライアントは証明書の有効期間に関するメッセージを出してログインを拒否します。最初の反応はゲートウェイ証明書を再発行するか EAP 方式を変えることですが、どちらもたいていは誤りです。ログインの試行には二つの別個のサーバー ID、つまり IKE が使うゲートウェイ証明書と、PEAP を終端する側が提示する証明書が含まれます。一方は正常で、もう一方がクライアントを停止させた理由です。

二つの ID、一度のログイン試行

VPN プロファイルの証明書は IKE 交換に属し、設定された IKE ポリシーの下でゲートウェイがプロファイルの指定する相手であることを証明します。ここで失敗する証明書は別の会話、つまり PEAP がユーザーを認証する相手と開く TLS セッションに属し、その相手はゲートウェイ自身ではなく NPS のような RADIUS サーバーであることがよくあります。三つ目の確認であるユーザー資格情報は、そのセッションの内部で行われます。有効なパスワードは期限切れのサーバー証明書を修復できず、有効なゲートウェイ証明書は PEAP エンドポイントを保証できません。

この階層構造は、誰かが設定した唯一の証明書がゲートウェイのものだった場所で、なぜ証明書エラーが現れるのかを説明します。同じ証明書を再発行しても何も変わらない理由も説明します。

ログ行を段階と照らして読む

理由と日付を示すメッセージを探します。サブジェクトのエラーの隣に有効期間の指摘があれば、サーバーが渡された証明書を拒否したのであり、ユーザーがログインを拒否したのではありません。次に段階を特定しますが、strongSwan の charon ログは EAP 交換が始まる前に IKE_SA .* established を表示するので、その行より後の証明書エラーは EAP ID に属し、前のエラーはゲートウェイを指します。Windows クライアントの接続パネルの段階表示も同じことを伝えます。

どの証明書に触れる前にも、クライアントの時計を確認してください。数時間ずれた端末は、本当に期限切れの証明書と同じ有効性エラーを出します。時計を合わせるのは五秒の修正で、問題でもなかった証明書を交換するのは停止です。

どのエンドポイントが PEAP を終端するかを見極める

ゲートウェイと RADIUS の構成では、ゲートウェイは EAP を転送し、終端しません。strongSwan の eap-radius プラグインが交換を RADIUS サーバーに渡し、そのサーバーが PEAP の TLS セッションと証明書を持ちます。失敗した一回の試行を両方のログで突き合わせ、どのプロセスが実際にそのセッション用の証明書を選んだのかを確認してください。

NPS では、証明書はローカル コンピューターのストアにあり、サーバー認証の目的を持ち、クライアントが期待する名前に一致し、サービス アカウントから読める必要があります。NPS に関する Microsoft の証明書要件にこれらの条件が並んでいます。他の EAP サーバーには独自の選択規則があるので、NPS の細部を FreeRADIUS の展開に写したり、その逆をしたりしないでください。どちらの構成でも成り立つ規則は、PEAP を終端するエンドポイントが、これから変更する証明書を所有しているということです。

EAP が終端する場所で証明書を交換する

PEAP を終端するエンドポイントで、サポートされた手順により証明書を更新または交換し、サーバー認証の目的と期待される名前を保ちます。サービスが探す場所に完全なチェーンをインストールし、サービスに秘密鍵へのアクセスを与えます。多くのサービスは古い証明書をメモリに保持したまま提示し続けるため、サービスを再起動するか再バインドしてください。マシンにコピーしたファイルは、サービスが実際にどの証明書を提示しているかを何も証明しません。

次回の試行をサービス自身のログと突き合わせるか、セッションが提示した証明書を調べて、変更を確認してください。そのログにまだ古い拇印が出ていれば、再起動は効いていません。

ディレクトリ内で最も新しいファイルが使われていると決めつけないでください。名前が正しく権限が誤ったコピーは何も変えません。変更はファイルのタイムスタンプではなく、提示された ID で判断してください。

やってはいけないこと

エラーを回避するために PEAP 検証を無効にしたり、より弱い内部方式を強制したりしないでください。それはポリシーを変え、期限切れの証明書をそもそも捕まえたサーバー認証の性質を奪います。動く確認を動く接続と引き換えにすることになり、次の期限切れ証明書は何の知らせもなく訪れます。

別のオペレーティング システムで接続できたことを、証明書が受け入れ可能だという証拠にしないでください。そのクライアントは別の EAP 方式、別の信頼ストア、あるいはサーバー検証をまったく使っていないかもしれず、その成功はここで失敗した確認について何も語りません。意図的な否定テストを一つ維持し、たとえば名前の誤った証明書や信頼されないチェーンが期待どおりに失敗することを確かめてください。そのテストが今通るなら、証明書を直したのではなく確認を外したのです。どの ID が失敗したのかを書き留め、次の人がまたゲートウェイ証明書から始めないようにしてください。