OpenVPN プロファイルには三つの証明書ブロックがある：どれが秘密か

一つの行を変えようと .ovpn ファイルを開くと、どれも認証情報に見える base64 のブロックが三つ並んでいる。公開してよいもの、パスワードと同じくらい機微なもの、そして相手側の鍵で何かが署名されていなければ意味を持たない公開鍵だ。ブロックが交換可能に見えるため、人はファイル全体をサポートのスレッドに貼り付け、その結果クライアント鍵が公開アーカイブに残る。どのブロックが何をするのかを切り分ければ、この種のプロファイルをめぐる混乱の大半は説明でき、自分で直すべき不具合も分かる。

一つのファイル、三つのブロック、それぞれ別の役割

一般的なプロファイルは BEGIN と END のマーカーの間に ca ブロック、cert ブロック、key ブロックを埋め込むか、 同じ三つを別ファイルとして指し示す。プロファイルによっては tls-auth や tls-crypt の鍵のための四つ目のブロックを加えるが、これは証明書ではなく共有の秘密である。クライアントは各ブロックを、それを名指すディレクティブに従って読むので、並び順よりもラベルのほうが重要だ。

中を実際に見るまでは、組み立て済みのプロファイルを機微なものとして扱う。公開証明書と秘密鍵が同じファイルの数行違いに並ぶことがあり、ヘッダーを含むスクリーンショットには両方が写り得る。見えている base64 を手作業で塗りつぶすのも当てにならない、一部だけ残ったブロックでも、配備名を示す証明書メタデータは漏れるからだ。三つのディレクティブの値を省いてコピーすれば、たいていは有益な質問ができる。

ブロックの周りのディレクティブが使われ方を決める。ca を変えればクライアントは別の認証局を信頼し、key を変えずに cert を変えれば、信頼とは無関係な不一致でハンドシェイクが失敗する。

CA ブロックは公開、CA 鍵は決して公開しない

認証局は公開鍵を身元に結びつける証明書に署名し、その認証局自身の証明書は、クライアントが連鎖を信頼できるか判断するためのアンカーになる。この証明書は設計上公開されていて、すべてのプロファイルに同梱するのは普通のことだからこそ自己署名の配備が商用の認証局なしで成り立つ。

クライアントのプロファイルに決して現れてはならないのは、認証局の署名用の秘密鍵だ。クライアントは何かを検証するのに必要とせず、これがあればプロファイルを持つ者が配備全体の新しい身元を作れてしまう。

認証局を信頼するというのは、聞こえるより狭い。CA が署名した証明書を何でも受け入れるクライアントは、同じ CA で別のサービス向けに発行された証明書も受け入れてしまう。想定するサーバーの役割や名前を固定するオプションがこの隙間を塞ぎ、 TLS オプションのリファレンス がそのための検証ディレクティブを列挙している。

サーバー証明書とクライアント証明書は逆向きを指す

サーバーの証明書は、正しい接続先に着いたかをクライアントが確かめるために見るものだ。自分のクライアント証明書は逆方向に働き、サーバーがそれを使って、この端末や利用者が自分が登録したものだと判断する。同じ形式で、信頼の向きは逆になる。

アドレスは身元ではない。正しい IP に届いても、誰が応答したかは何も証明できず、だから ホスト名や証明書名の確認は今もプロファイルに属する。アカウントのパスワードも、要求されたクライアント証明書を黙って置き換えることはなく、両者は別の段階で確認され、配備が両方を求めることもあるからだ。

クライアントの秘密鍵は、秘密のままでなければならない部分だ。漏れた可能性があるなら、手元の端末からファイルを消してもサーバー側は何も変わらず、運用者が失効させるまで対応する証明書を受け入れ続ける。運用者にその身元の差し替えや失効を頼むことだけが、持ち運べる対処になる。

同じに見えて同じでない二つの入力要求

暗号化して保存された鍵は、クライアントが使う前にパスフレーズを求める。VPN サービスが別にアカウントのパスワードを求めることもあり、二つの要求はほぼ同じ文言で数秒差に現れうる。パスフレーズはディスク上のファイルを守り、パスワードはサーバーに対してアカウントを証明する。取り違えると、助けになり得ないパスワード再設定へ人を送ることになる。

何かを再設定する前に、その要求を読む。アカウントのパスワード再設定は、忘れた鍵のパスフレーズや失効・期限切れの証明書には何の役にも立たず、障害が証明書の検証なのにパスワードを再設定すれば、二分で終わる修正がサポート案件になる。申告に有効期限の日付があるなら、まず端末の時計を確認し、次にその証明書自身の有効期間を見る。

証明書が本当に期限切れなら、差し替えは発行した相手から受け取るしかない。他人の鍵は更新の道ではなく、同僚から動くプロファイルを借りるのも同じだ。

きれいなハンドシェイクが証明することと、しないこと

TLS ハンドシェイクの完了に至ったというのは、設定された身元の関係が成り立ったという意味で、サーバーの証明書が自分の CA につながり、自分の証明書が受け入れられた。運用者の記録方針については何も語らず、トンネルが上がった後にアプリが動くかどうかも語らない。

ルートと DNS は接続の後の段階なので、ログインに成功した後にイントラネットのホストに届かないのは証明書ではなく接続性の問題だ。認証情報を入れ替えるのではなくその層を扱い、プロファイルを誰かに渡すときは、その出所、秘密の素材、身元の確認をまとめて引き渡す。