間違ったVPN証明書を取り消した？ 復旧の選択肢と限界

誰かがCAコンソールで証明書を取り消し、今ではユーザーが接続できない。最初の衝動は取り消しの巻き戻しを探すことだが、ほとんどのPKIにはそれが存在しない——取り消しはシリアル番号に関する宣言された事実であり、サポートされた戻り道は新しい証明書であって、逆転した記録ではない。以下の確認を順番に進めてほしい——どの修復が許されるかは、理由コードと、鍵がこれまでに露出したかどうかで決まる。

人物ではなく証明書を特定する

一般名は繰り返され、前四半期に再登録したユーザーは同じCNで異なるシリアル番号を持つ証明書を二つ持っていることがあり、片方を取り消してももう片方は動作し続ける。まず正確な対象を確定する。

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

シリアル番号、発行者、取り消し日、CRLに記録された理由を書き留め、次にそのシリアル番号を提示する端末を確認する。取り消された証明書がノートPC、スマートフォン、予備のルーターにまだインストールされていることがあり、一台にしか届かない交換は二件目のインシデントを生む。

迅速な動作確認は何も変えずに状態を裏付ける：

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

証明書を取り消済みと報告すればCRLとクライアントは一致しており、問題なく検証できれば手元のクライアントは取り消されたものではなく、調査は続く。

CAが保留と恒久的な取り消しのどちらを使ったかを確認する

RFC 5280はcertificateHoldを一時的な状態、removeFromCRLをそれを解放する信号と定義している。そのライフサイクルは実在するが、万能の巻き戻しボタンではない。理由コードを読めば、発行者が解放をサポートするつもりだったのかが分かる。

罠は、一時的な意図が一時的な記録を意味すると仮定することだ。CAのエントリがkeyCompromiseまたはcessationOfOperationを持つ場合、ボタンを押した人の意図に関係なく、証明書は恒久的に取り消されている。逆に、保留の解放を実装していないCAでcertificateHoldと印されたエントリは、解放が永遠に公開されないため、実質的に恒久である。

OpenSSLベースのCAはこの限界を示し、caコマンドは-crl_reasonの値を受け付け、certificateHoldやremoveFromCRLも含むが、デルタCRLは生成しない。OpenSSL CAのドキュメントはCRL出力についてこの制限を明記している。シリアル番号を単に省いた完全なCRLは「このエントリは解放された」と言うデルタとは別の公開モデルであり、OpenSSLベースのVPN CAにremoveFromCRLを貼り付けても、標準で定義された解放にはならない。

鍵が露出した可能性があるなら交換する

取り消された証明書は、この鍵がもはや信頼できないかもしれないという宣言である。取り消しが実質的に正しかった場合——ノートPCの紛失、共有ドライブへの鍵のコピー、チケットへの秘密鍵の貼り付け——同じ証明書を復元することは、意図どおりに機能していたセキュリティ判断を覆すことになる。

登録プロセスを通じて新しい鍵ペアを発行して新しいプロファイルを配布し、古いシリアル番号はその全寿命にわたって取り消したままにする。シリアル番号や指紋で身元を固定しているものすべてを更新する。

古いものを復元する利便性の議論は現実的だが、静かにではなく明示的に答えるべきだ。「ユーザーは今日アクセスを必要としている」は発行を速める理由であって、説明できない鍵の取り消しを撤回する理由ではない。

管理上の誤りだったなら、統制のもとで交換する

取り消しが単に誤りで、鍵が一度も露出していなかった場合でも、修復は編集ではなく統制された交換であり、発行者のサポートされたプロセスを使い、シリアル番号と発行履歴を無傷に保ち、二つの誘惑的な近道を避ける。index.txtの状態文字をRからVに戻すことと、新しい証明書がシリアル番号を再利用できるように発行行を削除することだ。

OpenSSL CAではデータベースがタブ区切りで読み違えやすく、それが手作業の編集を魅力的にする：

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

読むだけで、書かない。ファイルを編集すると監査証跡なしに次のCRLが変わり、元の行をまだ保持している二つ目のCAインスタンスやバックアップは後で食い違う。

交換証明書を発行したら、通常の仕組みで新しいCRLを公開し、クライアントに取得させる。CRLを削除したり、寿命をゼロにしたり、クライアントプロファイルで取り消し確認を無効にしたりすると、CAがこれまで公開した他のすべての取り消しを弱めることで一人のユーザーを直すことになる。

新しい受け入れを確認し、記録を残す

すでに開いていたセッションではなく、新しい接続でテストする。生きたトンネルは新しいハンドシェイクが行う受け入れ確認を再実行しないことがあり、CRLキャッシュのためクライアントは更新するまで接続を続けられる。切断して再接続し、どのシリアル番号が受け入れられたかをサーバーログで確認する。

まだ新しいうちに、どのシリアル番号が、誰によって、どの理由で取り消され、どの交換証明書が発行され、いつCRLが再公開されたかを記録する。その記録が次の取り消しレビューを可能にし、誤りが隠されず処理された証拠にもなる。

将来の短い停止には、配備に仕組みがあれば、ID層で無効化されたアカウント、削除されたグループメンバーシップ、保留されたクライアントプロファイルといった受け入れ一時停止を使う。これにより一時的なポリシー判断を、発行済み証明書がまだ信頼できるかという問いから切り離せる。