CA を再構築せずに VPN クライアントを追加する

もう一台のノート PC に証明書が一枚必要ですが、検索結果の最初の解説は PKI ディレクトリを消すコマンドから始まります。そのコマンドは初回設定のもので登録用ではなく、実行すると CA、発行履歴、旧発行者を信頼した全クライアントプロファイルを失います。判断はもっと狭いものです。既存の発行者に使える状態が残っているか、新しい端末が今の登録ポリシーに合うか。三つの条件で決まり、再構築が正当化されるのは一つだけです。

再構築が実際に壊すもの

PKI を初期化し直すと、ディレクトリは空の構造に置き換わります。新しい CA 鍵と証明書、空の発行データベース、新しいシリアル番号カウンタです。クライアントは黙って従いません。プロファイルは古い CA を固定しているため、既存の端末はすべて再登録が必要で、到達できない端末は手作業になります。

より静かな損失は台帳です。失効は、どのシリアル番号を誰に発行したかを知ることに依存します。インデックスを消しても署名はできますが、発行済みのどれを失効させたかったのかを確信を持って言えなくなります。発行者状態のない証明書だけの CA ディレクトリは、システムの誤った半分を復元するバックアップです。

CA 秘密鍵を稼働中のサーバーの隣にコピーするのは、断るべきもう一つの近道です。オフラインに置くべき署名権限を、信頼できない通信を終端するホスト上の別ファイルにしてしまいます。

第一の条件: 発行者の状態にまだ到達できるか

決める前に、サーバーが実際に信頼するディレクトリを特定します。サーバーが CA として提示する証明書と PKI ディレクトリ側を、ファイル名ではなく指紋で比較します。

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

指紋が一致すれば登録は増分で、再構築は不要です。異なれば、サーバーが信頼しない CA で署名することになり、証明書はきれいにインストールされてもハンドシェイクで失敗します。その失敗は何時間もクライアントの不具合と誤診されます。

次に発行状態を探します。インデックスファイル、シリアルカウンタ、CRL 番号ファイルです。インデックスがなくても鍵が残っていれば発行はできますが、失効記録の問題を引き継ぎます。変更記録に残してください。次の失効要求がそれを露呈します。

第二の条件: 新しい秘密鍵を誰が持つか

利用者が実感する判断なので、明示的に決めます。クライアントで生成して要求として送る鍵は、最初のコマンドから秘密部分が端末に残り、管理者は触れません。サーバーで生成する鍵は道具のない端末には楽ですが、管理者が全鍵の管理者になり、サーバー侵害の影響が広がります。

既存の CA に対する Easy-RSA 3 では、要求の取り込みと署名は二つのコマンドです。

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

証明書の種類は意図して選びます。クライアントではなくサーバー証明書として署名された要求は、見た目は正常でも相手に拒否され、エラーメッセージは理由をほとんど語りません。openssl ca で署名する場合、同じ選択は渡す拡張にあり、既定のセクションにはありません。

第三の条件: サーバーは証明書以上のものを要るか

証明書認証を使う通常の OpenVPN サーバーでは、証明書そのものが登録です。コモンネームがクライアント ID になり、クライアントごとのディレクトリ、プッシュするルート、固定アドレスはその名前に対応します。証明書だけ追加して設定を忘れると、トンネルはつながるのに必要なルートが現れません。

プラットフォームで変わります。OpenVPN Access Server は独自のユーザーデータベースを持つため、署名済み証明書はアカウントではありません。アカウントが存在し許可されている必要があります。他のゲートウェイは ID 文字列をグループに対応付けます。一台の登録は通常二つのシステムに触れ、証明書は最初の一つにすぎません。

増分の手順と、再構築が正しい場合

被害なく一台を追加する順序はこうです。指紋で発行者を確認し、PKI ディレクトリの新しいバックアップを取り、クライアント役割の要求を取り込んで署名し、承認された経路で証明書を鎖ごと渡し、利用者が接続する前に検証します。

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

目的の行は SSL client を示すはずです。発行後に CA バックアップを更新して終えます。新しいシリアルを記録する前のバックアップは、いま追加した端末を含まない状態を戻すからです。

再構築が正しいのは三つの場合です。CA 鍵が侵害された、発行状態が回復不能に失われた、鍵アルゴリズムや証明書ポリシーを意図的に変える。いずれも全クライアントの再登録計画を伴うプロジェクトで、一台の要求の手順ではありません。どれも当てはまらなければ増分で登録します。