クライアントの証明書ファイルが消え、反射的に名前を失効させて新しい証明書を発行したくなる。その対応では元の証明書が有効なまま残る。失効はラベルではなくシリアル番号に基づくからだ。CA は発行した証明書の写しをほぼ確実に保持しており、その写しを見つけることが作業のすべてである。

ファイルを失うことは CA の記録を失うことではない

Easy-RSA PKI は発行した公開証明書を保持し、現行リリースは PKI 内の certs_by_serial ディレクトリにシリアル別の写しも保管する。失効に秘密鍵は必要ない。重要なのは CA が署名した正確な証明書であり、それは CA がすでに持っている。

正しい PKI のバックアップ上で、それを所有する管理者とともに作業する。失効は監査可能な操作であり、深夜に本番データベースを修理する作業ではない。

クライアントのインライン公開証明書の写しでもよい。配備がそれを残していればの話だが。

まず発行者とシリアルを読む

復元した PEM を調べ、発行者、シリアル番号、サブジェクト、有効期間を書き留める。シリアル番号は一つの発行者の範囲内で一意であり、環境内のすべての CA で共通ではない。だから発行者は識別子の一部になる。複数の証明書が同じサブジェクトを共有する場合、それらを区別するのはこのシリアル番号である。

その値を CA の記録と、証明書を保有していると考える端末や人物に照合する。

コモンネームは再利用でき、実際によく再利用される。シリアルを書き留める前に、どの証明書を取り消すか決めてはいけない。

新しい証明書を失効させても何も起きない理由

同じコモンネームで代替を発行すると、別のシリアルを持つ二つ目の証明書ができる。代替を失効させると新しい方が取り消され、元の証明書は期限まで有効なまま残る。CA から見れば独立した二つのオブジェクトであり、CRL は名前ではなくシリアルを列挙する。CA インデックスが発行済み証明書ごとに一行を保つのは、まさにそのためである。

同じ混同が逆の誤りを生む。クライアント側のファイルを削除し、CA が忘れたと考えるのだ。クライアント側の削除は失効の出来事ではなく、写しを持つ者には証明書が使われ続ける。

どちらの誤りも、名前を識別子とみなすことから来ている。

シリアルが指す証明書を失効させる

CA に触れる前にオブジェクトを特定する。openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates は四つの値を一度に出力し、CA の保管庫と照合するのはシリアルである。Easy-RSA はその保管庫を pki/certs_by_serial の下に置き、シリアルごとに一つのファイルを持つ。失効コマンドはシリアルではなくコモンネームを受け取るので、保管されたファイルを pki/issued/<common-name>.crt にコピーし、名前を特定したオブジェクトに向ける。PKI ディレクトリで easyrsa revoke <common-name> を実行し、index.txt の該当行が R に変わったことを確認する。シリアルはオブジェクトを選ぶ手段であり、コマンドが受け取る引数ではない。

openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates
cp pki/certs_by_serial/A1B2C3D4.pem pki/issued/client-01.crt
./easyrsa revoke client-01
grep -n client-01 pki/index.txt
./easyrsa gen-crl

index.txt が R を示さない場合は、CRL を生成する前に立ち止まってエラーを読むこと。まだ有効な記録から作った CRL は何も取り消さない。行が変わってから初めて easyrsa gen-crl を実行し、ファイルの配布に進む。

CRL は実際に適用される場所で公開する

PKI のサポートされた手順で新しい CRL を生成し、この発行者の失効を適用するすべての検証者に公開する。

CA の上に置かれた更新済みファイルだけでは何も変わらない。VPN は自前の検証者で判断を完結させるからだ。CRL の発行者、有効期間、失効したシリアルを確認し、サービスが前のファイルをキャッシュせず再読み込みすることを確かめる。所有者とパスは内容と同じくらい重要である。デーモンが読めない CRL は CRL がないのと区別できない。OpenVPN の crl-verify オプションはデーモンが読むファイルを指定するので、サーバー設定でそのパスとファイルの所有者を確認する。

ファイルのタイムスタンプではなく、実際の接続試行で検証する。

CRL が適切でない場面を知る

発行者の秘密鍵がもはや信頼できないなら、既知のシリアルを取り消しても、権限のない保持者が新しい証明書に署名するのを止められない。それは発行者信頼の移行であり、新しい CA と配布計画が必要だ。CRL に一行足す話ではない。元管理者にアクセスがあったこと自体は鍵の悪用の証拠ではないので、信頼を再構築する前に事実を確認する。

状態文字を反転させるために発行データベースを手で編集することは、署名済みの失効の代わりにならず、CRL を記録と矛盾させる。

シリアル、CRL、配布手順を一つのメモにまとめれば、次の監査は読むだけの作業になる。Easy-RSA プロジェクトは導入したリリースでサポートされるコマンドを文書化しており、従う価値のある唯一のインターフェースである。

関連記事