VPN証明書の棚卸し：CA台帳が証明できること

ゲートウェイは、設定されているのが信頼できる発行元であり、証明書がハンドシェイクの最中に届くために、見たこともないクライアント証明書を受け入れます。プロトコルはそう動くようにできており、だからこそサーバー上のディレクトリ一覧は貧弱な棚卸しになります。発行元は何を作ったかを知り、サーバーは何が接続したかを知り、失効状態は何が取り消されたかを知っています。この三つの記録を混ぜた棚卸しは、結局どれも言っていないことを主張してしまいます。

ゲートウェイが信頼するのは発行元であり、ファイル一覧ではない

検証は提示された証明書を信頼アンカーと照合するので、同じ発行元が昨日作った身元は、サーバーのディスクに一度も存在しないまま接続できます。そのために何かをコピーする必要はなく、誰かが手で承認する必要もありません。したがってサーバー自身の記録が示すのは到着であって、到着しうる身元の総体ではありません。

逆のずれも同じくらい厄介です。ディレクトリには、期限切れの証明書、失効した証明書、配備されなかった端末向けに発行された身元が残りえます。ファイルを数えると分かるのはファイルがいくつあるかであり、それは誰も尋ねていない問いです。代わりに、意味を持つ記録から始めてください。

四つの問い、四つの異なる記録

どの記録も一つの問いにはよく答え、他の問いにはうまく答えられませんから、それらを統合した報告書は完全に見えながら、特定の仕方で誤っています。下の表は、どのシステムが作ったかではなく、どの問いを決着させるかで並べています。

公開証明書のアーカイブは、秘密鍵を含まないので秘密ではありませんが、共有できるものでもありません。サブジェクトと端末名は運用の詳細を明かすので、報告書はそれを必要とする相手にとどめるべきです。秘密鍵は、棚卸しに必要なのが資格情報ではなくメタデータであるため、棚卸しから完全に外します。

発行元とシリアル番号だけが安定した鍵である

サブジェクトは再利用され、ファイル名も使い回されるので、昨年ある端末を指していた名前が今は別の端末を指すことがあります。どちらも鍵ではなく、どちらかに基づいた報告書は最終的に二つの身元を一行にまとめてしまいます。

発行元とシリアル番号の組が証明書を一意に識別し、どちらの項目も証明書そのものから得られます。サブジェクト、有効期間の日付、複製の出所、そして責任者または端末とともに記録してください。失効と配備の状態は、有効期間内の証明書が自動的に承認済みになるわけではないので、それぞれの観測時刻を持つ別の項目として追加します。この二つの事実は別のシステムにあり、まとめてしまうと、ファイルは最新に見えるのに身元が取り消されている場合が隠れます。

証明書は一枚ずつ読む

ディレクトリ全体に展開するワイルドカードはバッチ用のインターフェースではなく、どのファイルがどの出力を生んだかを隠します。メタデータは証明書ごとに読み、失効側はそれ自身の成果物から読みます。OpenSSL x509 のリファレンスに、これらのオプションが表示する項目が並んでいます。

openssl x509 -in <cert>.pem -noout -issuer -serial -subject -dates -fingerprint -sha256
openssl crl -in <issuer>.crl -noout -text | head -n 40

管理された Easy-RSA PKI では、ツールが対応するワークフローを通じて発行データベースに問い合わせ、ディレクトリ構成を前提にするのではなく、棚卸しを組み立てている間は原本を読み取り専用にしておきます。台帳の形式は十分に規則的なので、データベースを手で開かなくても有効な項目を数え、取り消された項目を一覧できます。

grep -c '^V' pki/index.txt
grep '^R' pki/index.txt | cut -f4,5

次の発行にも耐える棚卸し

ディレクトリの一度きりの出力は、次の証明書が発行された瞬間に古くなりますから、報告書は発行のワークフローから作り、通常の運用の一部として更新させてください。これにより報告書は再現可能にもなり、何が発行されたかで二人の見解が割れたときに効きます。

結果は表計算の練習ではなく、更新と廃止の判断に使ってください。ローカルの複製を削除しても、すでに存在する遠隔の複製は無効になりません。設定された失効と承認のワークフローで身元を取り消し、そのうえで取り消しを日付とともに記録します。サーバーから消えても発行元が依然として信頼している身元は廃止されておらず、その違いが、正確な棚卸しと、ただ安心させるだけの棚卸しを分けます。