ca.key を全 VPN クライアントに配ると CA が壊れる理由

セットアップ手順のどこかで、どのファイルがそこに属するかを決めるより簡単だからという理由で、ディレクトリごと全ノート PC にコピーされている。そのディレクトリには ca.key が入っており、二台目の端末に届いた瞬間に認証局は認証局でなくなる。保持者は誰でも、ネットワークの残りが信頼する身元を発行できる。

この混乱は、二つのファイルが見た目に似ていて正反対の働きをするだけに、一度ほどいておく価値がある。

検証用の素材と署名用の素材

クライアントが必要とするのは、相手が提示した証明書がその認証局によって署名されたかを確かめるための CA の公開証明書である。これは検証の作業であり、秘密を一切必要としない。相手の証明書に署名するのは別の作業で、CA を運用する者が一度だけ、保護された保管場所から決して出ない秘密鍵を使って行う。この二つの作業を分けておくことが、二つのファイルを配る意味そのものである。

つまり ca.crt はプロファイルに属し、ca.key はその近くのどこにも属さない。ファイル名は慣習であって保証ではないから、名前から推測するのではなく種別を調べる必要がある。

中間 CA やオンライン発行サービスを用いる構成も例外ではない。端末から署名能力を遠ざけながら、端末証明書を大規模に発行するための標準的な方法である。

クライアントが自分の鍵で証明すべきこと

各端末は自分専用の鍵ペアと証明書を受け取るが、証明書は CA が一度だけ署名する。クライアントはその証明書を提示し、対応する秘密鍵を保持していることを証明し、サーバーが受け入れるかどうかを決める。ノート PC を失ったときに失効させるのはこの身元である。

この対比が最も効くのは盗難のあとだ。端末ごとの身元があれば、露出したクライアントは失効または相手の削除によって外され、残りの群れは動き続ける。

漏えいした認証局の鍵はそう扱えない。それが署名した、あるいは署名できたすべての証明書が疑わしくなるため、応答は単一の失効ではなく信頼の置き換えになる。これはプロジェクトであって、チケットではない。

どこかへコピーする前にファイルを読む

二つのコマンドで、秘密を何も出力せずに手元の対象がどの種別か分かる。一つ目は証明書の主体と CA フラグを示し、二つ目は鍵を検証してその種別を報告する。配布しようとしている束の中のファイルに対して両方を実行する。秘密鍵として検証が通るものは、クライアントのディレクトリに置くべきではない。

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

クライアントの束に入っているファイルで二つ目のコマンドが成功したら、手を止めてその束を侵害済みとして扱う。鍵が有効だと述べる出力はその鍵が存在するとも述べているのだから、存在そのものが問題のすべてである。

逆向きにも注意すべきで、クライアントのプロファイルにはそのクライアント自身の秘密鍵が正当に入っている。見つけた鍵を片端から削除すると、何も改善しないまま接続が切れるので、削除する前に種別を特定する必要がある。

すでに配ってしまった鍵を封じ込める

手元のコピーを削除すれば露出が巻き戻るとは考えないこと。ファイルを保持した者は誰でも複製できたはずで、複製したと考えるのが安全である。運用者のインシデント手順に従い、信頼の基点を交換し、新しい CA の下で端末証明書を再発行する。

次に、問題を生んだ梱包を変える。許可するファイルを明示した一覧とともにディレクトリの内容を送り、CA の鍵はクライアントの群れに決して加わらない機械に置き、どのシステムが保持しているかを記録する。

認証局が頻繁に発行しなければならないなら、署名を狭い範囲と短い有効期間を持つサービスや中間局の背後へ移す。そうすれば将来の誤りが露出するのは発行の一部であり、配備全体の信頼の根ではない。