クライアント証明書なしのOpenVPN：サーバー側のポリシーであり、プロファイルではない

証明書と鍵の行を削除し、プロファイルを渡しても、接続は依然として証明書エラーで失敗します。その要件を強制していたのはプロファイルではありません。クライアント証明書が必須かどうかを決めるのはサーバーであり、クライアント側の編集でそれが取り消されることはありません。したがって修正はサーバー側のポリシー変更であり、意図的に行い、それに依存するすべてを同じ作業で更新します。

プロファイルはポリシーではない

Community OpenVPN 2.6 は、verify-client-cert の既定値が require であるため、クライアント証明書が必須の状態で出荷されています。これを none に設定することが、証明書の要求を止め、クライアント認証をサーバーがすでに運用しているユーザー名とパスワードの仕組みに委ねる方法です。古いガイドは同じ考えの旧表記である client-cert-not-required に手を伸ばしますが、インストール済みのバージョンが文書化しているディレクティブを使ってください。いずれにせよ変更はサーバー側で行われ、クライアントのプロファイルでは実行できません。

以下の断片がサーバー側の変更のすべてであり、それ自体では機能する認証設定ではありません。verify-client-cert none は証明書の要件を取り除き、username-as-common-name はアカウント名を、後続のコールバックとクライアントごとのファイルが見る識別子にします。どちらの行もパスワードを検査しないため、検証器は依然として必要です。

verify-client-cert none
username-as-common-name

その検証器は auth-user-pass-verify によって駆動されるプラグインまたはスクリプトであり、上のどちらかの行が意味を持つ前に配置されていなければなりません。順序を逆にすると、サーバーが証明書を求めずアカウントも検査しない期間が生まれます。

それでもサーバーを検証するもの

クライアント証明書を外すことは TLS を外すことではありません。サーバーは自身の証明書と鍵を保持し、クライアントは偽装者と通信しないための CA 信頼とホスト名の検査を保持します。クライアントが証明書を持たなくなったからといって remote-cert-tls server や CA バンドルを削除するのは、よくある重大な誤読であり、2.6 のリファレンス は二つの方向が独立していることを明言しています。一方はサーバーをクライアントに証明し、もう一方はクライアントをサーバーに証明します。

プロファイルは tls-auth や tls-crypt のブロックを持つこともあります。これは独自の配布とローテーションの周期を持つ制御チャネルの共有鍵なので、証明書や鍵の行がないファイルが自動的に公開して安全とは限りません。読むまでは秘密として扱ってください。

動作するプロファイルからコピーした証明書ファイルはそれ自体では何も証明せず、所有とはそれに対応する秘密鍵を保持していることであり、証明書認証を用いる配備がそれを確認します。証明書を含むファイルは、それで認証できるファイルではありません。

検証器がすべきこと

証明書の要件を取り除くと、すべては検証器、すなわちプラグインまたは auth-user-pass-verify によって駆動されるスクリプトにかかります。無効な資格情報を拒否し、無効化されたアカウントや資格のないアカウントを拒否し、バックエンドに到達できないときは閉じた状態で失敗しなければなりません。username-as-common-name はしばしば併せて有効化され、後続のコールバックとクライアントごとの設定ファイルが見る識別子を変えます。パスワードを検証するものではなく、資格のないアカウントを資格あるものにするものでもありません。これらは別の仕事であり、混同すると移行はハッピーパスのテストに合格し、最初の実際のインシデントで失敗します。

否定ケースを肯定ケースと同じくらい丁寧に試験してください。パスワードのプロンプトを表示するプロファイルは、クライアントがプロンプトを描けることしか証明しませんが、誤ったパスワードを受け入れるサーバーははるかに悪いことを証明します。試験セットには、悪いパスワードだけでなく、無効化されたアカウントと期限切れの資格情報も加えてください。

ポリシー、プロファイル、マッピングを一緒に変える

サーバーのディレクティブ、クライアントのプロファイル、そして クライアントごとの識別子マッピング の三つを調整してください。別々に変えると、クライアントは検証の前に失敗するか、管理者が予期しない名前で接続しますが、後者のほうが成功に見えるためによほど悪いのです。誤った識別子で成功する接続は、失敗する接続よりも気づきにくいものです。

この経路には二つのテストアカウントを用意し、一つは有効、一つは既知の不良にして、検証器を変更するたびに両方を使ってください。有効なアカウントはハッピーパスと識別子マッピングを証明し、不良のアカウントは拒否がまだ機能することを証明します。どちらの試験も資格規則については何も教えてくれないので、配備にそうした規則があるなら、ポリシー上の理由で拒否されるべきアカウントを加えてください。すべてを受け入れ始めた検証器は機能しているログインとまったく同じに見えるので、変更のたびに三つすべてを実行してください。

サーバーが実際に受け入れる認証方式を、プロファイルが示唆する方式ではなく記録してください。その記録は、人々が繰り返し尋ねる問い、つまり誰がこのサービスに接続できるかに答えます。また、さもなければパケットキャプチャからそれを再発見することになる次の管理者より長く残ります。