OCSP ステープリング解説（なぜ任意なのか）
更新 2026-11-03 · 5 分で読めます
失効確認は証明書チェーンで最も弱い環です。ブラウザは証明書がまだ有効かを第三者に問い合わせなければならず、その問い合わせが訪問者を CA に晒します。ステープリングはその答えをハンドシェイクの中へ移します。
通常の OCSP の問題
ブラウザは証明書を受け取ると、CA の OCSP レスポンダに問い合わせて失効していないか確認できます。このリクエストは第三者への別接続で、遅延を増やし、ページが読み込まれる前に訪問者がどのサイトに接続しているかを明かしてしまいます。
レスポンダが遅い、あるいは到達不能な場合、ブラウザは検査を無視する（フェイルオープン）か、サイトを遮断する（フェイルクローズ）かのどちらかです。どちらも良くありません。
ステープリングが変えるもの
ステープリングでは、サーバー自身が署名済み OCSP レスポンスを取得してキャッシュし、TLS ハンドシェイクに添付します。ブラウザは誰にも問い合わせずに失効状態を得るので、余分な往復も漏洩もありません。
さらに「訪問者のネットワークから CA に到達できる必要がある」という依存も外れます。OCSP レスポンダが断続的に遮断される地域では、これが効きます。
有効化と確認
nginx ではステープリングに resolver とチェーンファイルが必要で、どちらか欠けると黙って無効になります。Apache ではキャッシュ指令をサーバーレベルに置く必要があります。reload したら必ず外側から確認してください。設定は書いてあるが効いていない状態と、そもそも書いていない状態は、見分けがつかないからです。
# nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
# verify from outside — look for a stapled response, not just "OCSP response: none"
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A3 "OCSP Response Status"なぜ A+ で必須ではないのか
ステープリングはプライバシーと遅延の改善であって、プロトコル強度の改善ではありません。ステープリングしないサーバーは、TLS 1.0 を提示するサーバーのようには「弱く」ありません。CertH は設定健全性のポジティブな信号として扱いますが、最高評価の必須条件にはしていません。
とはいえ最も安上がりな改善のひとつです。設定 2 行、クライアントへの影響ゼロ、そしてすべての訪問者に測定可能なプライバシー上の利益があります。
FAQ
CA のレスポンダが落ちるとステープリングは壊れますか？
サーバーは最後にキャッシュしたレスポンスを、期限が切れるまで返し続けます。nginx は更新に失敗するとキャッシュにフォールバックします。安定した挙動のためには resolver と有効なチェーンファイルの両方が必要なのはそのためです。
must-staple は有効にすべきですか？
ステープリングが極めて安定している場合だけです。must-staple 拡張があると、ステープルされたレスポンスがないときにクライアントが接続を拒否するため、キャッシュや resolver の一度の失敗が全断につながります。