OpenVPN verify-x509-name: subject・name・name-prefix の違い

まず照合の種類を読み、そのあと本文を読む：verify-x509-name ディレクティブは正しく見えても、信頼するつもりのなかった証明書を受け入れてしまうことがある。期待するテキストが同じでも種類が違えば別の要件である。まず種類を読み、そのあと本文を読む。ディレクティブは接続へのもう一つの条件として扱い、確認のすべてと考えない。

このオプションが実際に主張すること

ディレクティブは、相手の証明書が持つべき identity を指定する。比較に失敗すると、OpenVPN はハンドシェイクを中止し、トンネルは上がらない。プロファイルの他のすべては依然として有効であり、証明書は信頼された CA に連鎖する必要があり、ロール確認も通過しなければならないので、これは代替ではなく追加条件である。名前の期待を満たしてもロール確認に失敗するプロファイルは壊れたままで、ログはたいていそう告げる。

これはブラウザが行うホスト名検証とも違う。ブラウザは自身の TLS スタックの規則に従って名前を subject の代替名と照合するが、OpenVPN は選んだ種類で証明書の一つのフィールドを比較する。だからブラウザ風のホスト名をディレクティブに貼り付けても、証明書が実際にサービスを覆っていても不一致になりうる。

subject: 完全な識別名を一文字ずつ

種類が書かれていない場合の既定は subject であり、期待値は証明書の subject DN 全体を再現しなければならない。フィールドの順序、区切り、空白、エスケープのすべてが意味を持つのは、比較が符号化されたままの文字列で行われるからだ。種類を省けば、三つの比較のうち最も厳しいものを選んだことになる。見た目の差を救う正規化の手順はない。最初の更新の前に知っておくべきことで、後ではない。

その厳しさは更新をまたぐと脆い。属性を並べ替えたり、余分なフィールドを挿入したり、値のエスケープ方法を変えたりする CA は、同じ機械に対して新しい文字列を作り、何年も機能していたディレクティブが次の発行で失敗し始める。受け入れた DN を変更記録に残せば、次の更新は差分になる。運営者が完全な DN を公開しその形を保証しているなら subject は妥当な選択であり、そうでなければ狭いフィールドのほうが真に保ちやすい。

name: 一つのフィールド、通常はコモンネーム

種類 name は subject の一つのフィールドを比較する。プロファイルが別段の定めをしていない限り、そのフィールドはコモンネームであり、期待値はまさにそのフィールドで、周囲の DN ではない。

落とし穴は、現代の証明書がサービスの名前を常に CN に入れるとは限らず、多くは subject の代替名に持ち、CN を空やす一般的なままにすることだ。だからブラウザが受け入れる証明書でもこの比較に失敗しうる。期待を書く前に実際に発行された証明書を調べ、プロファイルがどのフィールドを選ぶかを確認すること。空の CN と名前の比較は不一致であって、設定の事故ではない。

name-prefix: 設計上広いので範囲を限定する

種類 name-prefix の期待は、選ばれたフィールドの先頭に一致する。これは命名規則には便利で、共有されるものには危険である。

期待を vpn.example にすると、vpn.example.com も vpn.example.net も通り、鎖の残りが信頼されていればよい。広さは特長であり、同時に書面で正当化すべき部分でもある。CA と命名規則が自分のものであれば接頭辞は妥当で、公開 CA が同じパターンで発行するならはるかに弱い。規則に柔軟性が必要なら、クライアント側の確認を広げるのではなく CA で制限すること。

識別子から種類を選び、それから証明する

運営者が意図する identity から逆算する。完全な DN を公開して安定させているなら、subject がそれを表す。サービスをコモンネームで名付けるなら、name を使う。命名規則を所有しその空間全体を受け入れるなら、name-prefix がそれを明示する。

更新こそがディレクティブの試される場であり、承認済みの identity を古いファイルではなく新しい証明書と比較すること。新しいエンドポイントアドレスは新しい証明書 identity を意味せず、見慣れたアドレスが応答するからといってディレクティブを削除もしないこと。到達性と意図した相手は別の事実である、またアドレスは何かが応答したことだけを示し、正確なエラーと公開名の詳細は浄化した報告に記録すること。名前の不一致は秘密鍵の材料なしで示せるからだ。

サポートされた修正の後、意図したすべての確認を有効にして再接続し、実際に必要なリソースを検証する。成功とは意図したサーバーが受け入れられたことであって、何らかの証明書が通されたことではない。公式マニュアルであるOpenVPN 2.6 manual は三つの種類と信頼に関する注意を記述しており、ベンダーのインターフェースがプロファイルと食い違うときに引用すべき資料である。