OCSP と CRL の違い：各失効確認は実際にどう動くか

この 二つの失効確認のうち一方は 一つの証明書についての署名済みの回答を返し、もう一方は全体をダウンロードする署名済みリストを返します。どちらも資格情報がまだ信頼できるかを検証者に伝えるためのもので、しかも失敗の仕方はまったく似ていません。以下の順序は、運用者が本番で実際に出会う順に沿っています。回線上のバイトから始まり、接続を拒否するゲートウェイで終わります。手順を飛ばすと、展開は紙の上にしか存在しない失効ポリシーを抱えたままになります。

ステップ 1：各確認が返すものと、使える状態がいつまで続くか

CRL は発行者が失効させたすべての証明書を対象とする 一つの署名済みオブジェクトとして公開されるため、検証者は 一度取得し、リストの nextUpdate を過ぎるまで再利用します。OCSP 応答はもっと限定的で、ちょうど 一つの証明書に答え、thisUpdate、producedAt、そして通常は nextUpdate も持ちます。この違いが他のすべてを決めます。キャッシュされた CRL は静かに古くなります。ファイルは依然として解析でき、署名も依然として検証できるからです。一方、期限切れの OCSP 応答は、タイムスタンプを読んだ時点で明らかに無価値です。

したがってまず確定すべきはキャッシュです。どのコンポーネントがコピーを保持し、そのコピーがどの上限に従うのか。ゲートウェイでは上限を nextUpdate から安全余裕を引いた値にすべきで、HTTP キャッシュヘッダーがたまたま示す値にしてはいけません。openssl crl -in issuer.crl -noout -lastupdate -nextupdate は両方の日付を出力し、nextUpdate がすでに過去であるリストは、単に古いのではなく欠落として扱う必要があります。

ステップ 2：証明書がクライアントをどこへ導くか

リーフ証明書は通常 二つの手がかりを持ちます。CRL 配布点拡張と、OCSP 用の機関情報アクセス項目です。openssl x509 -in client.pem -noout -ext crlDistributionPoints が前者を出力し、後者は openssl x509 -in client.pem -noout -text の AIA セクションにあります。どちらの拡張も指し示すものであって義務ではありません。失効確認を決して実装しないクライアントでも、拡張が 一年前に死んだレスポンダーを指している証明書に対して問題なく接続します。

配布点はしばしば 一つのネットワークセグメント内でしか解決できない内部ホストを指し、古いクライアントの中には ldap URL を真っ向から拒否するものもあります。到達性は、トンネルを終端するホストから試してください。自分のノート PC からではありません。失敗が実際に意味を持つのはその視点だけだからです。

ステップ 3：障害の前に fail-closed か fail-open かを選ぶ

到達できないレスポンダーや期限切れのリストは決断を迫ります。接続を拒否するか、受け入れて空白を記録するかです。OpenSSL の verify サブコマンドは厳格な選択を明示します。-crl_check を加えると、利用できない CRL が unable to get certificate CRL となり検証が失敗するからです。多くのスタックではソフトフェイルはフラグではなく、確認が存在しないことそのもので、だからこそ事故で出荷されます。

クライアントが実際にどんな挙動を持つかを見るには、レスポンダーを取り除いて再接続します。それでもトンネルが上がるなら、飛ばされた確認を記録したログ行を探し、インシデントの最中に誰かがその行を読むかを自問してください。同じベンダーでもプロトコルごとに異なり、同じマシン上の IKEv2 クライアントと OpenVPN クライアントは無関係な設定項目を読みます。

ステップ 4：トラフィックが許可される場所で確認が動くことを証明する

接続を終端または認可するプロセスを見つけ、失効確認を有効にする設定行を尋ねてください。チェーンを検証するのに失効を一度も尋ねないゲートウェイは、文書にあるポリシーとは別のポリシーを適用しており、証明書チェーンのスクリーンショットはその反対を証明しません。OpenVPN はこのオプションを crl-verify と書き、strongSwan は CRL と OCSP の参照を CA 設定の下に置き、そこに crl_uris または ocsp_uris を設定します。どちらも指せないなら、確認は存在しないとみなしてください。

OCSP 応答が意味を持つのは、発行 CA が署名した場合、またはその CA が委任した OCSPSigning 拡張鍵用途を持つレスポンダーが署名した場合だけであり、無関係なサービスの回答は何も証明しません。レスポンダーを自分で運用するなら、ハードな依存として監視してください。死んだサービスが 一つあるだけで、fail-closed のクライアントすべてが同時に停止します。

ステップ 5：証明書を 一つ意図的に失効させる

テスト用の証明書を用意し、本番と同じ経路で失効させ、レスポンダーに直接問い合わせます。openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text は失効時刻とともに Cert Status: revoked を報告するはずで、good という回答は、あなたの失効がクライアントの問い合わせるレスポンダーに届いていないことを意味します。次に openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem を実行し、リスト経路で同じ判断を確認します。終了コードではなく理由の文字列を読んでください。失効による拒否もチェーンエラーも、どちらも失敗に終わるからです。

本当に重要なのは最後のステップです。実際の適用点に対して古いプロファイルで再接続し、拒否が失効に由来することを確認する。そのうえで新しい有効な証明書で再接続し、単にリスナーを壊しただけではないことを証明します。クライアント側でプロファイルを削除してもサーバーの判断については何も証明できず、トンネルを決して終端しないマシンで openssl verify が成功しても同じです。RFC 6960 は適合する OCSP 応答に何が含まれるかを定めており、このテストが読むステータス値も含まれます。