OCSPとは

詳細な図解

OCSPを読むときの前提

OCSP（Online Certificate Status Protocol）は、証明書が失効していないかをオンラインで確認する仕組みです。クライアントは証明書内のAIAに書かれたOCSP responderへ問い合わせ、good、revoked、unknownなどの結果を受け取ります。

実務では、証明書期限だけでなく、OCSP responderの到達性、応答期限、soft-failかhard-failか、OCSP staplingの有無、プロキシやFWの影響を見ます。

証跡には、対象FQDN、証明書シリアル、issuer、OCSP URL、応答ステータス、thisUpdate、nextUpdate、確認元、確認時刻を残します。

失効確認と接続失敗を分ける

OCSPの問題は、証明書自体が失効している場合と、OCSP responderへ到達できない場合で対応が違います。失効なら証明書の再発行や差し替えが必要で、到達性問題ならネットワークやCA側の可用性を確認します。

ブラウザやライブラリによって、OCSP確認に失敗したときの扱いが異なります。soft-failなら接続が継続することがあり、hard-failなら業務停止に見えることがあります。

• revoked、unknown、到達不可を分ける。
• クライアントごとの失敗挙動を確認する。
• FWやプロキシがOCSP通信を遮断していないか見る。

OCSP staplingと合わせて見る

OCSP staplingが有効な場合、サーバーがOCSP応答をTLS接続時に添付します。クライアントが外部のOCSP responderへ直接問い合わせる必要を減らせますが、サーバー側の取得失敗や古い応答のキャッシュが問題になります。

切り分けでは、stapleが返っているか、有効期限内か、対象証明書とissuerに対応しているかを確認します。中間証明書の不備があると、OCSP以前にチェーン検証で失敗します。

• stapling有無と応答期限を確認する。
• サーバー側のOCSP取得ログを見る。
• 中間証明書の提示状態も確認する。

社内PKIや閉域環境での注意

社内PKIや閉域環境では、端末やサーバーがOCSP responderへ到達できない構成になりがちです。VPN、プロキシ、ゼロトラスト接続、FWルールにより、失効確認だけが失敗することがあります。

端末証明書やmTLSでは、失効確認の失敗が認証失敗に直結する場合があります。OCSPとCRLのどちらを使うか、到達性をどう確保するかを設計時に決めます。

• OCSP URLへ到達できる経路を確認する。
• 閉域端末のプロキシ設定を確認する。
• 失効確認失敗時の認証挙動を記録する。

変更証跡と引き継ぎ

OCSP対応では、対象証明書、OCSP responder、応答結果、到達性、stapling状態、影響端末、暫定回避、恒久対応を残します。単に「証明書エラー」とまとめると再発時に追えません。

引き継ぎでは、Web基盤担当、端末管理者、PKI管理者、関連語としてCRL、OCSP stapling、証明書チェーン、mTLSを残すと確認しやすくなります。

• OCSP応答の原文と時刻を保存する。
• 失効、unknown、到達不可を分類する。
• staplingとCRLの代替確認を残す。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能