OCSP staplingとは

詳細な図解

OCSP staplingを読むときの前提

OCSP staplingは、サーバーがOCSP responderから取得した失効確認結果をTLS接続時に添付する仕組みです。クライアントが外部OCSP responderへ直接問い合わせる負荷や遅延を減らせます。

実務では、stapleの有無、応答の有効期限、issuerとの対応、サーバー側の取得失敗、古い応答のキャッシュ、ロードバランサーやCDNでの挙動を確認します。

証跡には、対象FQDN、証明書シリアル、stapled responseの有無、thisUpdate、nextUpdate、responder、TLS終端点、確認時刻を残します。

有効な応答が添付されているか見る

OCSP staplingが有効に見えても、期限切れの応答や対象証明書と合わない応答を返しているとTLS警告の原因になります。証明書更新直後は古いstapleが残ることがあります。

確認では、各TLS終端点でstapleが返るか、応答のnextUpdateが十分残っているか、issuerに対応したOCSP応答かを見ます。

• stapled responseの有無を確認する。
• thisUpdateとnextUpdateを保存する。
• 証明書更新後に古い応答が残らないか見る。

サーバー側の取得失敗を確認する

staplingでは、サーバーがOCSP responderへ定期的に問い合わせます。サーバーからresponderへ到達できない、DNS解決できない、プロキシ設定がない、CA側が不安定といった理由で応答を更新できないことがあります。

クライアントには単にstapleなし、または期限切れとして見えるため、サーバー側ログとネットワーク経路を合わせて確認します。

• サーバーからOCSP responderへの到達性を見る。
• TLS終端点のOCSP取得ログを確認する。
• FW、DNS、プロキシ設定を確認する。

CDNやLBの終端点差分

CDN、ロードバランサー、WAF、リバースプロキシでTLSを終端している場合、OCSP staplingの設定や更新状態は終端点ごとに異なります。片系だけ期限切れ応答を返すと断続的な警告になります。

IPv4/IPv6、地域、SNI有無、複数証明書を分けて確認します。中間証明書の欠落があると、stapling以前にチェーン検証で失敗することもあります。

• CDN/LBの各経路でstapleを確認する。
• IPv4とIPv6の結果を比較する。
• 中間証明書の提示状態も確認する。

変更証跡と引き継ぎ

OCSP stapling対応では、対象FQDN、TLS終端点、OCSP応答の期限、取得失敗ログ、設定変更、反映確認、戻し条件を残します。単に有効化しただけでは運用証跡として不足します。

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

• 各終端点のstaple有無を保存する。
• OCSP応答更新の監視を確認する。
• 期限切れ応答時の切り戻しを残す。

関連語

同じ主要カテゴリの用語

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

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

InfraEngKit内の関連機能