OCSP Staplingとは？仕組み・OCSP廃止後の位置づけ・設定方法と診断基準

OCSP Staplingとは

OCSP Stapling（OCSPステープリング）とは、Webサーバーが自分の証明書について認証局（CA）から取得した「失効していない」という署名付きOCSP応答を、TLSハンドシェイクの中でクライアントへ同送（staple＝ホチキス留め）する仕組みです。

ブラウザがCAのOCSPレスポンダーへ個別に問い合わせる必要がなくなるため、次の2つの効果があります。

• 接続の高速化：ブラウザ側の追加の問い合わせが不要になります。
• プライバシー上の問題の軽減：ブラウザが直接問い合わせると、「どのサイトを閲覧したか」がCAに知られます。Staplingではサーバーが代わりに取得するため、この問題が軽減されます。

セキュリティAIチェッカーは、この項目で「Staplingが可能な証明書なのに、Staplingされていない」場合だけを改善対象として扱います。重大度はlow、重み1の参考項目です。

OCSP Staplingの仕組み（4ステップ）

1. クライアントは ClientHello に status_request 拡張（RFC 6066）を付けて「OCSP応答を同送してほしい」と要求します。
2. サーバーは事前にCAのOCSPレスポンダー（証明書の Authority Information Access 拡張に記載された OCSP - URI）から応答を取得・キャッシュしておきます。
3. TLS 1.2 では CertificateStatus メッセージ、TLS 1.3 では Certificate メッセージ内の拡張としてOCSP応答を返します。
4. クライアントはCAの署名と有効期間（thisUpdate／nextUpdate）を検証して失効状態を判断します。

関連する仕様の整理

OCSPの終了とOCSP Staplingの現在の位置づけ

OCSPは「任意」、CRLは「必須」に

2024年3月15日以降、公的に信頼されるTLS証明書では、OCSPの提供がCAの任意となり、CRL（証明書失効リスト）の提供が必須となりました（CA/Browser Forum Ballot SC-063）。

Let's Encrypt は2025年5月7日に証明書からOCSP URLを外し、同年8月6日にOCSPレスポンダーを停止しています。つまり現在は「OCSP URLを持たない正規の証明書」が多数存在し、そのような証明書では原理的にStaplingができません。

ブラウザ側の失効確認の現状

• Chrome：既定でオンラインのOCSP問い合わせを行わず、独自の CRLSet で失効情報を配布しています。
• Firefox：Firefox 137 からデスクトップ版（Windows／Linux／macOS）の全利用者に CRLite を有効化し、Firefox 142（2025年8月公開）でDV証明書に対するOCSP問い合わせを無効化すると公表しました。

このため「Staplingがないと失効確認が全く行われない」という状況ではなくなりつつあります。Staplingの価値は、OCSPを利用する一部のクライアントや、OV/EV証明書・社内システム向けの確実な失効確認に移っています。

Must-Staple（RFC 7633）

RFC 7633 の TLS Feature 拡張（Must-Staple）を付けた証明書は「必ずStapleすること」を宣言し、対応クライアントはStapleがない接続を拒否します。Let's Encrypt は、ブラウザ対応が広がらなかったことを理由に Must-Staple 付き証明書の発行を終了しています。Must-Staple証明書を使っている場合、OCSP取得に失敗するとサイトが表示できなくなるため、運用リスクが高い点に注意が必要です。

OCSP Staplingについてよくある誤解

• 「Staplingがない＝証明書が危険」：そうではありません。証明書の有効性・信頼性は「TLS証明書が現在有効」と「証明書チェーンが信頼される」の別項目で判定します。
• 「OCSP URLがない証明書は不正」：これも誤りです。CA/Browser Forum の Baseline Requirements 上、OCSPは任意でCRLが必須です。さらに同じ SC-063 により、有効期間がごく短い短期証明書（2026年3月15日以降の発行分は7日以下、それ以前は10日以下）は、CRL・OCSPのどちらのURLも記載しなくてよいとされています。
• 「設定を有効にすれば必ずStapleされる」：Staplingを有効にしても、サーバーがOCSPレスポンダーへ到達できない（外向き通信の制限、DNSリゾルバ未設定）と応答は付きません。

なお、証明書の残り期限は「証明書期限の余裕」、TLSのバージョンは「TLS 1.2以上のみを許可」の各項目で確認します。

OCSP Staplingの診断基準（セキュリティAIチェッカー）

取得方法

• 最終URLがHTTPSの場合に、対象ホストの公開IPアドレスへ Node.js の tls.connect で直接接続します。
• 接続条件は、SNI付き、rejectUnauthorized: true（証明書検証あり）、最小TLS 1.2、requestOCSP: true、5秒タイムアウトです。
• ハンドシェイク中に OCSPResponse イベントで空でない応答を受け取ったかどうかを記録します。
• getPeerCertificate() で取得した証明書の infoAccess に OCSP - URI が含まれるか（証明書がOCSP URLを持つか）を記録します。
• 追加のHTTP取得は行いません。

判定条件

得点への影響

重み1の参考項目のため、総合スコアへの影響は最大でも約1ポイント程度です。応答の中身（good／revoked）の検証や nextUpdate の鮮度は判定対象外です。

自治体サイトでの判定例

OCSP Staplingがないとどんなリスクがあるか

• 閲覧先の漏えい：Staplingがなく、クライアントがOCSPを直接問い合わせる場合、閲覧の事実がCAに伝わります（多くは平文HTTP）。経路上の第三者にも閲覧先が推測されます。
• ソフトフェイルによる失効の素通り：OCSPレスポンダーの障害時、多くのクライアントは「ソフトフェイル」（確認できなければ接続を許可）します。そのため、秘密鍵の漏えい後に失効させた証明書が攻撃者に悪用される余地が残ります。Staplingはこの確認を接続経路に組み込むことで改善しますが、攻撃者はStaplingしないサーバーを用意できるため、Must-Stapleなしでは完全な対策になりません。
• 優先度は低い：想定被害は限定的で、他の通信系項目（TLSバージョン、証明書の信頼性、HSTS）に比べ優先度は低いです。証明書の失効が実際に問題になるのは、秘密鍵の漏えいや誤発行が起きた場合です。

OCSP Staplingの設定方法（Apache・nginx・IIS・CDN）

まず証明書にOCSP URLがあるか確認する

最初に、証明書にOCSP URLがあるかを確認します。ない場合は本項目の対応は不要で、証明書の自動更新と短い有効期間による対策を優先します。

# 証明書の OCSP URL を確認（何も表示されなければ OCSP 非対応の証明書）
openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp </dev/null 2>/dev/null \
  | openssl x509 -noout -ocsp_uri

# Stapling の有無を確認（"OCSP Response Status: successful" が出れば有効）
openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp -status </dev/null 2>/dev/null \
  | grep -A 6 "OCSP response"

Apache（mod_ssl）

SSLStaplingCache は VirtualHost の外（サーバー全体設定）に置く必要があります。共有ホスティングの .htaccess では設定できないため、事業者へ依頼してください。

# httpd.conf / ssl.conf（グローバル）
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

<VirtualHost *:443>
    ServerName www.city.example.lg.jp
    SSLEngine on
    # サーバー証明書＋中間証明書を連結したファイル（SSLCertificateChainFile は 2.4.8 以降非推奨）
    SSLCertificateFile      /etc/pki/tls/certs/fullchain.pem
    SSLCertificateKeyFile   /etc/pki/tls/private/server.key
    SSLUseStapling on
    # 既定は on。off にすると status が good 以外の応答（エラー・期限切れ等）や
    # 問い合わせ失敗時に合成される tryLater 応答をクライアントへ渡さない
    SSLStaplingReturnResponderErrors off
</VirtualHost>

nginx

server {
    listen 443 ssl;
    server_name www.city.example.lg.jp;
    ssl_certificate         /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key     /etc/nginx/ssl/privkey.pem;
    ssl_trusted_certificate /etc/nginx/ssl/chain.pem;   # 応答検証用の中間・ルート
    ssl_stapling        on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 1.1.1.1 valid=300s;              # OCSPレスポンダーの名前解決に必須
    resolver_timeout 5s;
}

• nginx は最初の接続を契機にOCSP応答を取得するため、再起動直後の1回目の接続ではStapleされないことがあります。確認は数回接続してから行ってください。
• OCSP URLを持たない証明書で ssl_stapling on のままにすると、nginx は起動時に「"ssl_stapling" ignored, no OCSP responder URL in the certificate」という警告を出してStaplingを無視します。動作に支障はありませんが、設定を外しておくと警告が消えます。

IIS（Windows Server）

Windows Server の IIS（SChannel）は、OCSP URLを持つ証明書に対してStaplingを自動で行う実装です。サーバーからOCSPレスポンダー（通常TCP 80）への外向き通信と、プロキシ設定を確認してください。

CDN・ロードバランサー・クラウド

• CDN・ロードバランサー（Cloudflare、AWS CloudFront／ALB など）でTLSを終端している場合、StaplingはCDN側の機能です。オリジンサーバーの設定では変わりません。
• Vercel など Next.js のホスティング基盤では、TLS終端をプラットフォームが担うため、アプリ側で設定する項目はありません。

サイトを壊さないための注意点（ガードレール）

• 外向き通信を制限しているサーバー（自治体の閉域・LGWAN接続系など）では、OCSPレスポンダーへの通信許可（FWのホワイトリスト）が必要です。到達できない状態でMust-Staple証明書を使うと閲覧不能になります。
• Must-Staple付き証明書は、明確な理由がない限り新規に採用しないでください。
• 証明書の更新時に中間証明書を差し替え忘れると、ssl_stapling_verify が失敗しStapleされなくなります。更新手順にStaplingの確認を含めてください。
• ASVSではLevel 3の要件です。一般的な自治体の広報サイトでは、HTTPS化、TLS 1.2以上、HSTS、証明書の自動更新を先に完了させてください。

よくある質問（FAQ）

参考資料

• Let's Encrypt ブログ（2024年12月5日）：Ending OCSP Support in 2025（OCSPサポートの終了）
• CA/Browser Forum Ballot SC063v4: Make OCSP Optional, Require CRLs, and Incentivize Automation
• Mozilla Hacks（2025年8月19日）：CRLite: Fast, private, and comprehensive certificate revocation checking in Firefox
• OWASP ASVS 5.0.0 V12 Secure Communication（V12.1.4）
• OWASP WSTG-CRYP-01 Testing for Weak Transport Layer Security
• Node.js TLS (SSL) ドキュメント
• RFC 6960 Online Certificate Status Protocol - OCSP
• RFC 6066 Transport Layer Security (TLS) Extensions
• RFC 7633 X.509v3 TLS Feature Extension
• Apache HTTP Server mod_ssl
• nginx ngx_http_ssl_module

「OCSP Stapling」と関連する診断項目

• TLS証明書が現在有効critical
• 証明書チェーンが信頼されるhigh
• 証明書期限の余裕high
• TLS 1.2以上のみを許可high
• HTTPSで配信されているcritical
• HTTPからHTTPSへ転送high
• HSTSが設定されているhigh
• HSTSの有効期間medium