パスワードのみのOpenVPNプロファイルにはどのCAファイルを入れるか

四つの問いを順にたどれば、CAダイアログは曖昧ではなくなる。運営者が実際に発行した素材は何か、プロファイルが既に含むものは何か、どのフィールドが問い合わせているのか、ファイル読み込み後に何が起きるのか。運営者自身の指示から答えられない最初の問いで止まること、なぜならそこで推測を重ねると、公開CA証明書がサーバーを出るはずのなかった秘密鍵と組み合わされるからだ。

順序が重要で、最後の二つの問いは、どの素材が存在すべきかを知って初めて意味を持つ。

プロファイルが既に持つものから始める

テキストエディタでプロファイルを開き、ファイルを探す前にcaブロックを探す。運営者の公開CAを含むインラインcaブロックがあればプロファイルは自己完結しており、それでもCAファイルを求めるクライアントは別のプロファイルや不完全なインポートを読んでいる可能性がある。代わりにパスを指すca行がある場合、そのパスは統合によってはクライアントの作業ディレクトリからの相対であり、別の統合では絶対である。何かを変更する前に、どちらの形式かを記録する。

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

プロファイルが参照するファイルについて、配布されたパッケージを確認する：CA証明書、場合によっては別個のクライアント証明書と鍵、そしてtls-authまたはtls-cryptファイルがあり得る。四つのファイルを参照するのに二つしか届かないプロファイルは不完全であり、フィールドを指し示しても直らない。たまたま手元にある証明書で代用するのではなく、不足している部分を運営者に求める。

四種類の素材を分ける

CA証明書はサーバーの身元を検証するために使われる公開の素材だ。クライアント証明書はユーザーやデバイスをサーバーに対して識別する。秘密鍵はそのクライアント証明書の秘密の半分であり、CAの署名鍵やサーバー鍵であってはならない。tls-authまたはtls-cryptの素材は、制御チャネルを保護する別個の共有秘密である。この四つは交換できず、CAフィールドをクライアント証明書に向けると、信頼の問題のように見える検証失敗が生じる。

パスワードのみの認証は、四つのうちどれが必要かを変えるのであって、意味を変えるのではない。auth-user-passとremote-cert-tls serverがあってもクライアントはCAに対してサーバーを検証するため、クライアント証明書がなくてもCAフィールドは表示される。クライアント証明書も必要かどうかは運営者の方針が決め、どのダイアログもそれを教えてくれない。

クライアントを信頼ファイルに向ける

CA証明書ファイルそのものを選ぶ：それを含むフォルダーや、クライアント ID を含む.p12バンドルではない。Windowsではパスの構文とファイル選択の挙動が多くの解説のLinux例と異なるため、インストールされたクライアントが受け付ける方法を使い、実行するアカウントがファイルを読めることを確認する。権限の問題とファイルの欠落はダイアログでは同じに見えるが、ログの行は異なる。選択後、プロファイル設定を開き直してクライアントが選択を保持したことを確認する。

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

クライアントがインラインブロックに対応しているなら、手作業で組んだプロファイルより運営者のインラインプロファイルを優先する。インラインの素材はプロファイルと一緒に移動し再インポートにも耐えるが、絶対パスはプロファイルを別のマシンへ移した瞬間に壊れる。

同じエラーではなく次のエラーを読む

正しいCAを渡す目的は、エラーを消すことではなく変えることだ。CA読み込み後のサーバー身元の失敗は、証明書が期待された名前やremote-cert-tlsの期待と一致しなかったことを意味し、パスワード拒否とは別の修理になる。パスワード拒否はTLS層が成功し、資格情報が誤っていることを意味する。最初の新しいメッセージを残すこと、それが役に立つ。

接続はできるがどこにも届かないクライアントは、信頼を完全に通り過ぎ、いまルーティングかDNSの問いに直面している。

そのダイアログを抜けるために検証を無効にしてはならない。どんな証明書でも受け入れるクライアントがCAを求める理由はなく、それが作るトンネルは運営者が意図したものではない。