既存のエンタープライズ CA を OpenVPN ピアに使う

OpenVPN のどこにも、証明書が Easy-RSA 由来であることを求める規定はありませんし、組織的な PKI をすでに持つフリートは、通常、二つ目を構築すべきではありません。本当の作業は、ツールを選ぶことではなく、発行されたアイデンティティが何を意味するのか、トンネルがどのピアを受け入れるのか、更新と失効がどのように検証側へ届くのかを決めることです。後の手順では最初に下した役割の判断を修復できないため、以下の五つの手順を順番に進めてください。

一つの共有アイデンティティではなく二つの役割を発行する

各ピアには独自の証明書と対応する秘密鍵が必要です。PKI チームに、サーバー用途を持つサーバーアイデンティティと、クライアント用途を持つ別個のクライアントアイデンティティを依頼し、ハンドシェイク時にトンネルが両者を区別できるようにします。

締め切りの圧力下で現れる近道に抵抗してください。ウェブサーバーの鍵をノート PC にコピーすると、役割チェックが依存する区別が消え、VPN エンドポイントにインストールされた CA 署名鍵は、一つの侵害されたホストを侵害された階層に変えます。PKCS12 バンドルはエンドポイント鍵とそのチェーンを運べますが、そのアイデンティティを別の役割で再利用する許可を与えることは決してありません。

各側で信頼の入力を接続する

クライアントとサーバーはそれぞれ、信頼アンカー、自身のアイデンティティ、明示的な役割の期待を必要とします。三つすべてを明記したクライアントの断片は次のようになります。

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

サーバー側は remote-cert-tls client と自身の証明書でそれを鏡写しにし、これがクライアント証明書をサーバーとして受け入れるのを防ぎます。名前の確認は役割の確認とは別の判断です。ブラウザー流のホスト名一致を仮定するのではなく、どのフィールドが比較されるかを配備済みの設定で確認してください。フリート全体で共有されたファイルパスは共有されたポリシーと同じではないため、両側はどの発行者を信頼するかも明示すべきです。

信頼を広げずに中間証明書を配布する

両側が一つの発行チェーンを共有する必要はありません。ピアが中間証明書で署名された証明書を提示するとき、検証側はその中間証明書が利用可能である必要があり、OpenVPN は信頼アンカーの入力と、ローカルに提示されたチェーンを完成させるために使われる追加の証明書を区別します。OpenVPN 2.6 の TLS オプションリファレンス は両方を文書化しています。

中間 CA はそれ自体が問題ではありませんが、信頼バンドルに投げ込まれた広いエンタープライズルートは問題です。アンカーが広いほど、チェーン試験を通過する証明書が増え、役割チェックはそれを認可された職員の一覧に変えることはありません。階層が許す範囲で、アンカーを実際に VPN アイデンティティに署名する発行者まで狭めてください。許さない場合は、広いアンカーを黙って放置するのではなく、意図的に受け入れたリスクとして文書化してください。

更新と失効が VPN 検証側にどのように届くか、どの発行者が重要で誰が一覧を公開するかを含めて、PKI チームと合意してください。証明書に埋め込まれた CRL 配布ポイントは指示であり、何かがそれを取得した証拠ではありません。

失効が実際にどのように届くかを決める

crl-verify は検証側にファイルまたはエンドポイントを参照させ、その取り決めには所有者と更新経路が必要です。配備時に一度だけコピーされた一覧は、証明書が最初に失効したときに静かに保護をやめます。

予想される伝播時間を書き留め、失効させてもよい証明書で試してください。一覧を VPN ホストで更新できない場合の代替は、より短い有効期間と実際に動作する更新プロセスであり、URL があるから失効が機能するという仮定ではありません。

実際のクライアントで受け入れを証明する

許可されるべきクライアントを接続し、ログでネゴシエートされた証明書の詳細を確認してください。次に、失敗すべきケースとして、サーバーとして提示されたクライアント証明書、信頼アンカーの外にある発行者の証明書、そして余分があれば失効した証明書を試します。

受け入れた発行者、役割チェック、失効の取得元をプロファイルの隣に記録してください。その記録は、先月まで動作していたデバイスが接続しなくなったときに次のエンジニアが必要とするものであり、エンタープライズ CA が汎用の信頼の捨て場としてではなく、文書化された受け入れ境界の内側で使われている証拠でもあります。