TLS・PKI・証明書

OCSP（Online Certificate Status Protocol）おーしーえすぴー

証明書失効確認PKICRLTLSデジタル証明書OCSP Stapling

OCSPについて教えて

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

HTTPSで使うデジタル証明書が「今この瞬間も有効か？」をリアルタイムで問い合わせる仕組みだよ。免許証の有効期限を確認するんじゃなくて、「この人、今も資格停止されてないですか？」って警察に直接電話で確認するイメージ！

OCSPとは

OCSP（Online Certificate Status Protocol） とは、デジタル証明書の有効・失効状態をリアルタイムで確認するためのプロトコルです。ウェブサイトへのHTTPS接続時などに、ブラウザや通信ソフトウェアが証明書を発行した 認証局（CA: Certificate Authority） のOCSPサーバーに問い合わせを送り、その証明書が今現在も有効かどうかを確認します。

従来は CRL（Certificate Revocation List：証明書失効リスト） という「失効した証明書の一覧ファイル」をダウンロードして照合する方法が使われていました。しかしCRLはファイルサイズが大きく、更新も定期的にしか行われないため、リアルタイム性に課題がありました。OCSPはその弱点を補う形で登場し、個々の証明書について「有効（good）」「失効（revoked）」「不明（unknown）」の3種類でシンプルに回答を返す仕組みを実現しています。

特にフィッシング詐欺や不正アクセスで使われたサイトの証明書が緊急失効させられた場合、OCSPがあることでエンドユーザーへの被害を素早く防ぐことができます。システム発注や選定の場面では、利用するTLS証明書や認証基盤がOCSPに対応しているかどうかが、セキュリティ要件の確認ポイントになります。

OCSPの仕組みと応答の種類

OCSPの基本的なやりとりは「リクエスト→レスポンス」のシンプルなHTTP通信です。ブラウザ（クライアント）がOCSPレスポンダーと呼ばれるサーバーに問い合わせを送り、署名付きの応答を受け取ります。

応答ステータス	意味	具体的な状況
`good`	有効	証明書は現在も正常に使用可能
`revoked`	失効	証明書は失効済み（不正利用・鍵漏洩など）
`unknown`	不明	問い合わせ先のCAが発行した証明書ではない

[ブラウザ]                    [OCSPレスポンダー]
    |                                |
    |── OCSPリクエスト ──────────────>|
    |   (証明書のシリアル番号を送信)   |
    |                                |
    |<── OCSPレスポンス ─────────────|
    |   (good / revoked / unknown)   |
    |   ※CA秘密鍵で署名済み          |

覚え方：「証明書の健康診断を毎回オンラインで受ける」

OCSPの「O」はOnlineの「O」。証明書が有効期限内であっても、途中で失効していないかをオンラインで毎回確認するのがポイントです。「免許が期限内でも、違反で停止中かどうか確認する」と覚えましょう。

OCSP Stapling：パフォーマンス改善の仕組み

通常のOCSPでは、接続ごとにブラウザがOCSPサーバーへ問い合わせを行うため、以下の問題が生じます。

通信の遅延（ラウンドトリップが増える）
OCSPサーバーへの負荷集中
プライバシーの懸念（どのサイトに接続したかがCAに伝わる）

これを解決するのが OCSP Stapling（OCSPステープリング） です。Webサーバー自身があらかじめOCSPレスポンスを取得・キャッシュしておき、TLSハンドシェイク時にブラウザへ「添付（staple）」して渡します。

比較項目	通常のOCSP	OCSP Stapling
問い合わせ主体	ブラウザ	Webサーバー
通信の流れ	ブラウザ→CAのOCSPサーバー	サーバー→CAのOCSPサーバー（事前取得）
レイテンシ	増加する	増加しない
プライバシー	CAにアクセス先が伝わる	CAに伝わらない
対応要否	標準機能	サーバー側の設定が必要

歴史と背景

1990年代後半 — インターネットの商用利用拡大にともない、デジタル証明書の失効管理が課題に。CRL（失効リスト）が使われ始めるが、大規模化・リアルタイム性の問題が浮上
1999年 — RFC 2560としてOCSPの初版が標準化される。HTTPベースのシンプルな設計が採用された
2004年 — OCSP機能強化のためRFC 2560を補完するRFC 3029（DVCS）などが整備される
2013年 — RFC 6960としてOCSPが改定・更新。より厳密な仕様とセキュリティ要件が追加された
2013年〜 — OCSP Staplingが主要WebサーバーやTLSライブラリで広くサポートされ始める（Apache・Nginx・IIS等）
2019年〜 — Chrome・Firefoxなどブラウザ側でOCSPのソフトフェイル（失敗時に接続を続行）の挙動や廃止議論が続く。CRLSetsなど独自の代替手段を組み合わせる動きも
現在 — TLS 1.3環境ではOCSP Staplingが推奨され、証明書の失効確認の主役の座を維持している

OCSPとCRLの比較・PKIにおける位置づけ

OCSPとCRLは、どちらも証明書の失効確認を担う仕組みですが、アーキテクチャが異なります。PKI全体における位置づけを図解します。

比較項目	CRL	OCSP
方式	失効リストをダウンロードして照合	個別証明書をリアルタイム照会
リアルタイム性	低い（更新間隔がある）	高い（即時応答）
通信量	リスト全体をダウンロード	個別の証明書のみ
サーバー負荷	配布サーバー（CDN等）	OCSPレスポンダー
プライバシー	低懸念	やや懸念あり（OCSP Staplingで解消）
対応コスト	低い	サーバー設定が必要

規格・RFC番号	内容
RFC 6960	OCSPの現行標準仕様（2013年改定）。リクエスト・レスポンスの形式や署名方式を定義
RFC 2560	OCSPの初版（1999年）。現在はRFC 6960に置き換えられている
RFC 6961	TLS拡張によるOCSP Stapling（複数証明書対応）の仕様
RFC 4366	TLS拡張としてのOCSP Stapling（単一証明書）の元仕様
RFC 5280	X.509証明書とCRL全体のPKI標準仕様。OCSPと密接に関連