OCSPとは？ わかりやすく10分で解説

1. はじめに

インターネットそのものに「必ずデジタル証明書が必要」というわけではありませんが、少なくともHTTPS（TLS）で安全にWeb通信を行ううえではデジタル証明書が重要な役割を担います。証明書は「この公開鍵はこの組織（サイト）に属する」と示し、通信相手の正当性を検証するための基盤になります。

1-1. デジタル証明書と“失効確認”の重要性

デジタル証明書には、発行者（CA）情報、所有者情報、公開鍵、有効期限などが含まれます。ここで注意したいのは、証明書は有効期限内でも、秘密鍵漏えいなどの理由で途中で失効（revocation）することがある点です。つまり「期限内だから安全」とは言い切れず、“今この瞬間に失効していないか”を確認する仕組みが必要になります。

この「証明書の失効状態」をオンラインで問い合わせるための代表的な仕組みが、OCSP（Online Certificate Status Protocol）です。

1-2. 本記事の目的

本記事では、OCSPの基本（何を確認し、何を確認しないのか）を整理したうえで、OCSP Staplingとの違い、メリット・デメリット、運用上の注意点までを分かりやすくまとめます。

2. OCSPとは

OCSP（Online Certificate Status Protocol）は、デジタル証明書の失効状態を問い合わせるためのプロトコルです。クライアント（ブラウザ等）が、証明書が「失効していないか」をOCSPレスポンダーへ問い合わせ、レスポンスを受け取ります。

2-1. OCSPが“確認するもの／しないもの”

• OCSPが確認するもの：対象証明書のステータス（一般に good / revoked / unknown）
• OCSPが確認しないもの：証明書チェーンの正当性、署名検証、ドメイン名の一致、有効期限（期限切れの判定）など

つまり、OCSPは「証明書が失効していないか」を補助する仕組みであり、証明書検証の全てを肩代わりするものではありません。クライアントはOCSPとは別に、証明書チェーンの検証や期限確認などを行います。

2-2. OCSPが登場した背景

証明書の失効情報を配布する仕組みとしてはCRL（Certificate Revocation List）もありますが、CRLはリストが大きくなりやすく、クライアントが都度ダウンロード・参照する運用は負荷や遅延の課題が出やすい面があります。そこで、必要な証明書について必要なタイミングで状態だけ問い合わせる手段としてOCSPが広く使われてきました。

2-3. OCSPレスポンダーとは

OCSPレスポンダーは、証明書の発行者（CA）側で提供されることが多い“問い合わせ先”です。証明書には通常、OCSPレスポンダーのURL（OCSP URI）が含まれ、クライアントはそれを参照して問い合わせます。

3. OCSPの役割

3-1. 失効した証明書の利用を抑止する

秘密鍵漏えい、誤発行、運用停止などにより証明書が失効した場合、失効した証明書を使い続けるとリスクが高まります。OCSPは、こうした失効状態をクライアント側が把握するための主要な手段の1つです。

3-2. “リアルタイム”に近い確認を可能にする

OCSPは一般に、CRLのような“巨大な一覧の配布”よりも、個別の証明書の状態を問い合わせる形になります。これにより、状況に応じてより迅速に失効状態を反映しやすくなります（ただし後述の通り、運用上はキャッシュやレスポンスの有効期間も関与します）。

3-3. 証明書検証の一部として信頼判断を補強する

証明書検証は、チェーン検証・期限・用途・失効確認など複数要素の組み合わせです。OCSPはそのうち失効確認を担い、総合的な信頼判断を補強します。

4. OCSPの動作プロセス

OCSPの基本フローは次の通りです。

1. クライアントがサーバー証明書（および中間証明書）を受け取る
2. クライアントがOCSPレスポンダーへ、証明書の識別情報を含むOCSPリクエストを送る
3. OCSPレスポンダーが対象証明書の状態を参照し、OCSPレスポンスを返す
4. クライアントがレスポンスを検証し、状態（good / revoked / unknown 等）を評価する

4-1. “リアルタイム”の意味に注意

OCSPはしばしば“リアルタイム”と説明されますが、実際にはレスポンスにthisUpdate / nextUpdateのような時刻情報が含まれ、クライアント側のキャッシュや再問い合わせのタイミングにも左右されます。つまり、常に毎回問い合わせるとは限らず、性能と可用性のために一定のキャッシュが前提になることが一般的です。

5. OCSPの利点と欠点

5-1. OCSPの利点

• 失効状態を個別に確認できる（必要な証明書について状態だけ取得できる）
• CRLより転送量を抑えやすい（大きな一覧を都度取得する形になりにくい）
• 失効への追従性を高めやすい（運用次第で比較的迅速に反映しやすい）

5-2. OCSPの欠点（可用性・遅延・プライバシー）

• 問い合わせ先（OCSPレスポンダー）への依存：レスポンダー障害・ネットワーク遮断で確認できないことがある
• 追加の通信が発生：問い合わせが増えるほど遅延要因になり得る
• プライバシーの懸念：クライアントが「どのサイト（の証明書）を検証しているか」がOCSPレスポンダー側に推測され得る

5-3. “ソフトフェイル”という現実

OCSPは理屈の上では有用でも、現実のネットワークでは問い合わせ失敗が一定頻度で起こり得ます（例：閉域、検閲、キャプティブポータル、DNS問題など）。そのため多くのクライアント実装では、OCSPに失敗しても即座に接続を拒否しないソフトフェイル（soft-fail）が採用されることがあります。これは可用性を確保する一方で、攻撃者がOCSP通信を妨害できる状況では“失効確認が効きにくい”という課題にもつながります。

6. OCSP Staplingの概要とOCSPとの違い

OCSP Staplingは、サーバー側が事前にOCSPレスポンスを取得し、TLSハンドシェイク時にクライアントへ“添付（staple）”して渡す方式です。

6-1. 何が変わるのか

• 通常のOCSP：クライアントがOCSPレスポンダーへ問い合わせる
• OCSP Stapling：サーバーが取得したOCSPレスポンスをクライアントへ提示する（クライアントは原則、追加問い合わせを減らせる）

6-2. OCSP Staplingの主なメリット

• 遅延の低減：クライアント側の追加問い合わせが減りやすい
• プライバシー改善：クライアントが直接OCSPレスポンダーへ問い合わせる頻度を減らせる
• レスポンダー負荷の軽減：大量クライアントからの問い合わせ集中を緩和しやすい

6-3. Staplingでも“万能”ではない

Staplingは有効な改善策ですが、サーバー側の取得・更新失敗、設定不備、レスポンスの期限切れなどがあると期待通りに機能しません。運用面では、OCSPレスポンスの更新頻度や監視が重要になります。

7. 運用・設計で押さえたいポイント

7-1. 「失効確認」だけに依存しない設計にする

OCSPは証明書検証の一要素です。現実にはソフトフェイル等もあり得るため、失効確認だけに依存せず、証明書管理（鍵管理・更新運用・監視）やTLS設定（強い暗号設定、HSTS 等）も含めた総合設計が重要です。

7-2. サーバー側でStaplingを有効化する価値

Webサイト運用者の立場では、Staplingを有効化することで、性能・プライバシー・可用性の観点で改善が見込めます。特に大規模サイトや利用者が多いサービスでは検討価値が高いでしょう。

7-3. クライアント（ブラウザ）実装差にも注意

失効確認の実装は、ブラウザやOS、ポリシー設定によって挙動差が生じ得ます。企業環境では、端末・ブラウザ統制（ポリシー）と合わせて、想定どおりに失効確認が動くかを検証することが現実的です。

8. まとめ

OCSPは、デジタル証明書の失効状態を問い合わせるためのプロトコルであり、証明書検証の一部として信頼判断を補強します。一方で、可用性・遅延・プライバシーの課題があり、現実の実装ではソフトフェイルが採用されることもあります。

こうした課題への対策として、サーバー側でOCSPレスポンスを提示するOCSP Staplingは有効です。OCSPの“何を確認するのか”を正しく理解し、運用・設計の中で適切に使い分けることが、安全で快適なTLS通信の土台になります。

FAQ（よくある質問）

Q. OCSPは「証明書が有効期限内かどうか」も確認しますか？

A. いいえ。OCSPが主に返すのは「失効していないか（revoked でないか）」というステータスです。有効期限の確認や証明書チェーンの検証は、クライアント側の通常の証明書検証処理で行われます。

Q. OCSPレスポンスの good は「絶対安全」を意味しますか？

A. いいえ。good は一般に「少なくとも失効として扱われていない」ことを示します。鍵漏えいの発生直後や反映遅延など、運用上のタイムラグがあり得る点も踏まえて判断が必要です。

Q. OCSPが失敗したら接続は必ずブロックされますか？

A. 必ずしもそうではありません。可用性の都合で、OCSP問い合わせに失敗しても接続を継続する「ソフトフェイル」を採用する実装があります（環境・設定により挙動は異なります）。

Q. OCSPとCRLの違いは何ですか？

A. CRLは失効情報を一覧（リスト）として配布する方式、OCSPは証明書ごとに状態を問い合わせる方式です。一般にOCSPは転送量を抑えやすい一方、問い合わせ先への依存が増えます。

Q. OCSP Staplingを使うと何が良くなりますか？

A. サーバーがOCSPレスポンスを事前取得して提示するため、クライアントの追加問い合わせが減りやすく、遅延やプライバシー面の改善が期待できます。

Q. OCSP Staplingを有効化すればOCSPサーバーは不要になりますか？

A. 不要にはなりません。サーバーはOCSPレスポンスを取得するためにOCSPレスポンダーへ問い合わせる必要があります。クライアント側の問い合わせ頻度が減る、という位置づけです。

Q. 企業ネットワークでOCSPが失敗しやすい原因は何ですか？

A. プロキシや閉域網、DNS制限、検閲・フィルタリング、キャプティブポータル等により、OCSPレスポンダーへの到達性が不安定になることがあります。

Q. OCSPはフィッシング対策になりますか？

A. 直接のフィッシング判定機能ではありません。ただし、誤発行や不正利用などで証明書が失効している場合、失効確認が効けばリスク低減に寄与します。

Q. “unknown” が返ってきたらどう扱えばよいですか？

A. “unknown” はレスポンダーがその証明書の状態を判断できないことを示します。クライアントの実装・ポリシーにより扱いは異なるため、環境側で期待する挙動（拒否／許可／警告）を確認することが重要です。

Q. OCSP周りでWebサイト運用者が最低限やるべきことは何ですか？

A. 証明書更新の監視と自動化に加え、可能であればOCSP Staplingの有効化、TLS設定の見直し（強い暗号設定、HSTS等）を合わせて検討すると効果的です。