失効確認が別に必要なのはなぜ？

TLS証明書は、認証局が公開鍵とドメイン名の対応を署名して示すものです。秘密鍵の漏えいや誤発行があれば、有効期限前でも信頼を取り消す必要があります。有効期限だけを見るブラウザーでは途中の失効を見逃す可能性があるため、状態確認の仕組みが必要です。一方、接続のたびに外部の状態サーバーへ同期照会すると遅延や可用性依存が生じ、照会先に訪問ホストが知られる可能性もあります。

従来の証明書失効リスト（CRL）は、失効した証明書をまとめてクライアントへ配布します。リストが大きくなるほど転送・保存コストが増え、更新頻度と配布遅延の折り合いが必要です。OCSPは証明書ごとの状態を応答するため必要データを小さくできますが、ブラウザーが応答先へ直接接続すると、その可用性と追加往復に依存します。どちらも鮮度、性能、プライバシーの選択を伴います。

OCSP Staplingは何を変える？

RFC 6066のTLS status_request拡張は、クライアントが証明書状態情報を要求できるようにします。サーバーは証明書とともにOCSP応答をTLSハンドシェイクへ添付できます。ブラウザーが接続ごとに応答先へ直接接続しなくてよくなり、往復遅延と訪問先の露出を減らせます。ただし応答の検証は必要で、RFC 6066は満足できない応答を受けたクライアントにハンドシェイク中断を求めています。

ステープリングには、サーバーが有効で新しい応答を用意しておく必要があります。応答の期限切れ、更新失敗、証明書との不一致があれば、期待した状態情報を受け取れないことがあります。RFC 6066はTLS 1.2時代の拡張仕様であり、現在の証明書検証ポリシー全体を説明する文書ではありません。実際の挙動はブラウザーのポリシー、TLSバージョン、証明書拡張、配備設定によって異なります。

専門家の視点：信頼性はサーバー運用に左右される

Cloudflareの技術記事は、当時の同社の仕組みとして、各接続時に応答を取得する代わりに中央で集約し、有効期限が近づいた応答を更新して複数のサーバーへ配る設計を説明します。有効期間があるため、取得失敗時に再試行・復旧する余地が生まれるとしています。これは特定事業者の当時の運用事例で、すべての認証局やホスティング事業者が同じ信頼性を提供する保証ではありません。

通常の直接OCSP取得で応答が得られない場合、接続を許可するsoft-failは可用性を保ちやすい反面、攻撃者が応答を隠すと失効証明書を見逃す恐れがあります。ステープルを必須にする方針は、応答がなければ接続を失敗させて強い信号を求めますが、正規サーバーの更新障害も利用者の接続失敗になります。有効な応答を常に配れるという前提が運用で維持されて初めて、厳格な失敗方針を安全に採用できます。

CRLiteはデータをブラウザー側へ置く

MozillaのCRLite／Clubcard研究は、大量の失効情報を圧縮したメンバーシップデータにし、ブラウザーで照合する方式を検討しています。サイトごとにOCSP照会を送らずに済むため、遅延と個別訪問先の開示を減らせる可能性があります。論文は圧縮サイズ、更新通信量、フィルター更新の仕組み、Firefox Nightlyでの実装を評価しています。

論文は2024年末のWebPKIデータで、全スナップショット6.7MB、6時間ごとの差分は平均26.8kBと報告します。著者らによれば、clubcard方式はFirefox Nightly 134の標準の失効確認方式となり、研究中の確認の約93%を処理しました。これらは論文のデータ・時点・Nightly環境に限られ、現在の全Firefoxや他のブラウザーの標準設定、即時の全環境更新を示すものではありません。圧縮データの定期配布と検証、古いスナップショットや更新漏れへの対応は、別途必要な運用課題です。

比較するときに確認すること

OCSP Staplingは短期間有効な状態応答をサーバーから届け、CRLiteは圧縮された失効集合をクライアント側で照合します。前者は応答更新と配布の信頼性、後者は大規模データの更新頻度・保存・検証が主な運用点です。どちらも証明書発行管理、秘密鍵保護、信頼ストア、ブラウザー全体の検証方針を置き換えません。

設計時にはまず対象ブラウザーとTLSバージョンを特定し、応答がない・古い場合の扱いを明文化します。そのうえでプライバシー、遅延、ネットワーク断、データ鮮度、復旧手順を一体で測ります。現在の製品状況は最新文書と実際の構成で確認してください。

出典・参考資料: