VPN証明書をコピーしても鍵はコピーされない

この解説はクライアントの証明書一覧から始まる。そこには名前、発行者、有効期限しか表示されず、それ以外は何もない。これをエクスポートし、二台目の端末にインポートすると、クライアントが秘密鍵の所持を証明できないため接続は拒否される。ファイルは完全にコピーされていた。誤りは、証明書が自分の鍵を運ぶと期待したことにある。形式を選ぶ前にエクスポートのダイアログを読み、実際に受け取ったファイルを確認しよう。

二回のクリック、まったく異なる二つの成果物。

ファイルの拡張子ではなく、エクスポートのダイアログを読む

DER や PEM の証明書エクスポートには公開鍵と署名済みの身元の主張が含まれる。これはサーバーがあなたを信頼するために必要であり、クライアントがサーバーを検証するために必要なものでもある。PKCS#12 バンドルは、証明書とその連鎖、対応する秘密鍵を格納できるコンテナで、パスワードで保護されるが、鍵なしでも作成できる。

PEM はテキストの符号化にすぎず、中身を約束するものではない。同じ拡張子が、単一の証明書を表すことも、ラベル付きのブロックを複数含むファイルを表すこともあり、どちらになるかはエクスポートのオプションが決める。

したがって有用な問いは、どの拡張子を得たかではなく、ファイルにどのブロックが入っているかである。鍵なしでエクスポートされたバンドルもバンドルに変わりはない。形式の知名度ではなく中身を確認しよう。

実際に何を得たのかを確認する

何かをインポートする前にラベルを探す。次に証明書のフィールドを読み、どの身元を手にしているかを確かめる。確認は、実際にインポートされるファイルに対して行う。再エクスポートのたびに繰り返すこと。オプションが異なる場合がある。

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

証明書ブロックだけのエクスポートは公開された物体であり、認証はできない。証明書のない鍵ブロックでは、サーバーが期待する連鎖を欠くことになる。PKCS#12 の情報出力は鍵の有無も報告するので、その形式については疑問が解ける。アルゴリズムと鍵長も示され、鍵がなければ完全に失敗する。

秘密鍵を含むファイルは、たとえ以前に共有していた証明書に見えても、サポートのスレッド、課題トラッカー、チャットに決して貼り付けないこと。鍵パネルのスクリーンショットも同じ注意を要する。

鍵はコピーできない場所に住んでいることがある

管理された端末では、秘密鍵がオペレーティングシステムのキーチェーン、ハードウェアトークン、安全なエンクレーブに置かれ、エクスポート不可とポリシーで指定されていることがある。その場合、証明書マネージャーは公開された物体を表示し、秘密はその場にとどまる。どのエクスポートコマンドも持ち運べるコピーを生み出さない。モバイル端末管理による登録は、設計上しばしばこう動く。

これは統制であり、回避すべき障害ではない。公開証明書から秘密鍵を再構成することは不可能であり、そう主張するツールは別の何かをしている。

コピーするのではなく、新しい身元を登録する

推奨される道は、通常、新しい端末に別個の身元を登録し、古い端末が退役するときにそれを失効させることである。こうすれば各端末を独立して取り消せる。鍵付きのエクスポートが本当に承認されている場合は、出来上がったファイルとそのパスワードを資格情報として扱う。保存時は暗号化し、信頼できる経路で転送し、登録が終わったら削除する。

インポートが成功した様子を見るのではなく、インポートした身元で認証して検証する。公開証明書を自分のストアに受け入れたクライアントは、鍵について何も証明していない。

最後に、サーバーが新しい身元を受け入れ、古い身元がポリシーの意図どおりに振る舞い続けていることを確認する。こうしてこの解説は、正しそうに見えるファイルではなく、証拠をもって完了する。