// シス担のミカタ
暗号化・証明書

OCSP・CRL おーしーえすぴー・しーあーるえる

OCSPCRL証明書失効証明書検証OCSP StaplingPKI
OCSP・CRLについて教えて

簡単に言うとこんな感じ！

SSL証明書が「まだ有効か・失効していないか」をリアルタイムで確認する仕組みだよ。CRLは「失効した証明書の一覧リスト」、OCSPは「一個だけ即座に確認できる問い合わせ方式」なんだ。有効期限内でも漏洩したら無効にできるのがポイント！

OCSP・CRLとは

証明書の有効期限が来る前でも、秘密鍵の漏洩や組織変更などの事情で証明書を無効にする（失効させる） 必要が生じることがあります。そのとき、ブラウザやクライアントが「この証明書は今でも有効か？」を確認するための仕組みが CRL と OCSP です。

CRL（Certificate Revocation List：証明書失効リスト） は、CAが失効させた証明書のシリアル番号を一覧にして定期的に公開するリストです。ブラウザはこのリストをダウンロードして照合します。

OCSP（Online Certificate Status Protocol） は、1件の証明書の有効性をリアルタイムでCAのOCSPレスポンダに問い合わせるプロトコルです。CRLよりも軽量で最新の情報を確認できます。

CRLとOCSPの比較

比較項目CRLOCSP
方式失効証明書リストをダウンロード1件ずつCAに問い合わせ
鮮度定期更新（数時間〜1日遅れることも）ほぼリアルタイム
トラフィック大きい（リスト全体取得）小さい（1件分）
プライバシー問題なしCAが接続先を把握できる
主な用途旧来のシステム・CRL配布ポイント経由現在の主流
OCSP Stapling—サーバーが事前にOCSPレスポンスを取得してクライアントに提示

OCSP Staplingとは

通常のOCSPでは、ブラウザが接続のたびにCAのOCSPサーバーへ問い合わせを行うため、プライバシーの懸念（CAがどのサイトにアクセスしたか把握できる）とパフォーマンスの低下があります。

OCSP Stapling（OCSPステープリング） では、Webサーバー自身が定期的にOCSPレスポンスを取得し、TLSハンドシェイク時にクライアントに「ステープル（添付）」して提示します。これにより、ブラウザがCAへ問い合わせる必要がなくなります。

歴史と背景

  • 1996年：X.509 v2でCRLの仕様が定義
  • 1999年：RFC 2560でOCSPが標準化
  • 2004年：OCSPのTLSハンドシェイクへの統合（Stapling）が提案
  • 2013年：RFC 6960でOCSP v2が標準化
  • 2015年：Let’s Encryptが普及し、OCSP Staplingの重要性が高まる
  • 現在：ブラウザはOCSPよりCRLセット（CRLite）方式への移行も検討中

証明書検証フロー（OCSP Stapling利用時）

ブラウザ Webサーバー （証明書＋OCSPレスポンス保持） CAのOCSPレスポンダ ①サーバーが定期問合せ ②TLSハンドシェイク要求 ③証明書＋OCSPレスポンスを返す ④ ブラウザがレスポンスを検証 CAへの別途問い合わせ不要！

関連する規格・RFC

規格・RFC番号内容
RFC 5280CRLの仕様（X.509 PKIの一部）
RFC 6960OCSP v2の仕様
RFC 6961TLS Multiple Certificate Status Request（OCSP Stapling拡張）

関連用語