remote-cert-tls server：OpenVPNプロファイルで何を検査するか
このディレクティブが検査するのは相手の証明書にエンコードされた役割であり、名前ではありません。何かを無効にする前に、役割・信頼の基点・ホスト名の確認を比較してください。
OpenVPNプロファイルの三つの異なる部分が三つの異なる問いに答えますが、それらを混同すると機能していた検査を切ってしまうことになります。相手の証明書は自分が信頼する認証局によって署名されているか？その証明書はTLSサーバーの役割を宣言しているか？それは自分が到達しようとした特定のサーバーか？remote-cert-tls serverが答えるのは真ん中の問いだけで、証明書内部の拡張を読むことでそれを行います。
頭の中で混同しやすい三つの検査
信頼の基点はcaディレクティブにあります。役割の検査はremote-cert-tlsに属します。IDの検査はverify-x509-nameに属し、プロファイルがそれを使う場合もあれば、配備が追加する任意の名前検査に属する場合もあります。
これらは異なる障害をカバーします：
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
プロファイルが三つすべてを持っていても、CAが広く共有されすぎていれば弱いままであり、これはディレクティブではなく鍵管理の問題です。
役割の検査が読むもの
このディレクティブはマクロです。鍵用途の要件と、TLSウェブサーバーの役割を名指す拡張鍵用途の要件に展開されるため、相手の証明書はその目的を実際に宣言していなければなりません。クライアント認証用に発行された証明書は、同じ認証局が両方に署名していてもこれを満たしません。
これが重要なのは、小規模な配備では共有CAがよくあるからです。一つの認証局がすべてのクライアントとサーバーに署名し、役割の検査がなければ、それらの証明書のどれでもハンドシェイクのサーバー側を完了できました。検査はそのシナリオを不可能にはしませんが、その自明な版を取り除きます。
このディレクティブは設計上非対称で、クライアントはremote-cert-tls serverを携え、サーバーはremote-cert-tls clientを携えます。入れ替えれば、すべての接続が壊れた証明書に見える役割エラーで失敗します。
古いプロファイルは同じ目的でns-cert-typeを使うことがあります。現在のマニュアルページはこのオプションを置き換え済みとして扱うため、まだそれに依存しているプロファイルはデバッグではなく移行する価値があります。
無効にすると修正に見える理由
役割の検査が失敗すると、接続は検証エラーで停止し、明白な手はその行を削除することです。すると接続は上がり、進歩のように感じられますが、実際にはこのディレクティブが防ぐために存在する失敗モードです。これで、その役割を意図していなかった相手の証明書を受け入れることになります。
代わりにエラーを読んでください。どの検査が失敗したかを示しており、相手側の証明書を調べれば実際にどの拡張を持っているかがわかります。二分読めば、不具合が発行側か設定側かが決まります。推測は半日を費やし、たいていは弱体化したプロファイルで終わります。拡張鍵用途を失った更新済みサーバー証明書は更新の実際の不具合であり、クライアントを緩める理由ではありません。
名前の検査は別のディレクティブ
役割の検査を満たすということは、相手があなたの認証局によって署名された何らかのサーバーであるということですが、どれかについては何も言いません。同じCAが複数のゲートウェイに証明書を発行し、そのうち一つが侵害されたり転用されたりする場合には重要です。
verify-x509-nameは証明書のサブジェクトを設定した値と比較し、完全一致、プレフィックス、単一フィールドの照合モードがあります。実際にゲートウェイを識別するフィールドを使い、名前が変わったら意図的に更新することを想定してください。
どちらのディレクティブも適切な鍵の扱いを置き換えません。クライアント鍵ファイルがプロファイルと一緒に配られると、相手の身元は配布リストと同じ強さしかありません。
プロファイルを編集する前に証明書を調べる
相手の証明書とクライアントログをこの順に読みます。証明書はどの役割を宣言しているかを示し、ログはどの検査が拒否したかを示します。
次のコマンドは、詳細な接続から用途の拡張と検証行を出力します：
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify拡張がサーバーの役割を示しているのにログが役割エラーを報告し続けるなら、プロファイルは悪い証明書ではなく間違った証明書ファイルを指している可能性が高いです。拡張がクライアント認証だけを示すなら、クライアントを見るのをやめて発行を直してください。いずれにせよ、検証を外した後の成功したハンドシェイクは置き換えたエラーより少ないことしか証明しないため、接続を健全と呼ぶ前に検査を戻してください。