VPN における自己署名証明書と公開 CA：実際に何が変わるのか

VPN の設定で証明書のページを開くと、無料の自己署名証明書の選択肢が有料の公開 CA の隣に並んでおり、まるでセキュリティの選択のように見える。実際にはこれは対象者の選択だ。どちらの選択肢も同じ基本要素でトンネルを暗号化し、秘密鍵が漏れればどちらも無価値になる。両者を分けるのは、サーバーの身元について誰が主張するか、そしてその主張を検証できる立場に誰がいるかだ。

証明書は混同されがちな二つの仕事をする

証明書は公開鍵を名前に結び付け、鍵が暗号化と署名の仕事を担う。証明書上の署名は別個の声明であり、何らかの機関がその名前がこの鍵の持ち主に属することを確認したという意味だ。 自己署名証明書はその声明を自分自身について述べるが、これは第三者による主張ではまったくない。

公開ウェブサイトには第三者の版が必要で、訪問者は事前の関係なしに訪れてブラウザーの信頼ストアに依存するからだ。VPN クライアントは見知らぬ相手ではない。インストールするプロファイルの中に CA 証明書を渡すか、サーバー証明書をピン留めするので、検証はあなたが選んだ機関に対して正確に行われる。その検証に意味があるために商用 CA が関与する必要はない。

結果として得られるセッションの強度は、署名者ではなく鍵のサイズと暗号スイートから来る。だから自己署名証明書を「暗号化が弱い」と呼ぶのは単純に間違いであり、保証される範囲が狭いという別の性質だ。

公開 CA がその料金を正当化する場面

最も明確なのは管理ページだ。同僚や請負業者など、用意されたプロファイルを持たない誰かがブラウザーの警告なしに VPN サーバーのウェブ画面を開かなければならないなら、公的に信頼された証明書がその摩擦を取り除く。ブラウザーはすでに署名者を信頼しているので、インポートするものも説明することもない。

その便利さには購入前に挙げておくべきコストがある。更新を自動化しなければサイトは定期的に壊れ、公開証明書は証明書の透明性ログにホスト名を露出し、発行のレート制限は熱心に再試行するスクリプトを罰する。どれも公開 CA を避ける理由ではないが、プライベート CA が別の場所へ移す運用上の作業だ。

公開証明書がしないのは、あなたのユーザーを認証することだ。クライアントの身元は別の決定であり、クライアント証明書、パスワード、または第二要素で決められ、サーバーに署名する CA は誰がそれに接続してよいかについては何も語らない。

プライベート CA が VPN に合う場面

既知のクライアント群を持つプライベート VPN では、自前の CA を運用するのが従来の選択だ。CA を一度作成し、クライアントが使う名前でサーバー証明書に署名し、各プロファイルの中に CA 証明書を配布する。そうすれば各クライアントはあなたの機関に対してサーバーを検証し、外部の誰もホスト名を知らない。

コストは現実だが限られている。誰かが管理ページを直接開くと、ブラウザーにはあなたの CA を信頼する理由がないので警告を出す。プロファイルの配布は導入作業の一部になり、CA をローテーションするには全クライアントに触れる必要がある。これは既知のユーザーが十人か五十人のサービスには受け入れられる価格で、何千人もの公開エンドポイントには苦痛だ。

一つの条件が全体を有効にする。検証が実際に行われることだ。証明書エラーを無視するよう設定されたクライアントは、どんな証明書を提示するどんなサーバーも受け入れるので、暗号化が残ったまま身元の保証が消える。その設定こそが「自己署名は安全でない」という物語の多くにおける実際の弱点だ。

CA の秘密鍵が後で何ができるかを決める

驚きは通常、数か月後に端末を追加したくなったときに訪れる。クライアント証明書の発行には CA の秘密鍵が必要で、失効リストの作成にも必要だ。証明書と鍵のファイルはあるが CA の鍵がないサーバーを引き継いだ場合、新しいものには署名できない。選択肢は PKI を再構築して全クライアントに新しい CA 証明書を渡すか、パスワード認証に切り替えるかだ。後者は別のセキュリティモデルであり、失ったものを取り戻すわけではない。

同じ領域に小さな罠が二つある。easy-rsa のスクリプトは自分を置いたディレクトリにいる前提なので、ファイルが見つからないエラーは通常、壊れたインストールではなく場所の間違いを意味する。そして証明書だけで構成する設計は完全に正当だ。事前共有鍵なしでクライアント証明書を要求できる。ただし各クライアントが一つ持ち、サーバーが連鎖を検証することが条件だ。

チーム全体に一つの共有クライアント証明書ではなく、端末ごとに一つ証明書を発行しよう。そうすればノートパソコンを失っても、全員への再発行ではなく一つの失効で済む。

引き継いだものを確認する

変更を計画する前に、すでに持っている証明書を読む：

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

発行者が主体と等しければ、その証明書は自己署名であり、これは欠陥ではなく設計上の選択だ。日付は更新が誰かの問題になる時期を教え、配布しようとしている CA に対する検証の成功は、一人のクライアントが試す前に連鎖が機能することを確認する。

次に、対象者と配布方法で選ぶ。未知のブラウザーが管理ページを信頼しなければならないなら公開 CA、各クライアントがあなたの管理するプロファイルを受け取るならプライベート CA だ。どちらの答えも他方より暗号化が強いわけではない。