2026年8月11日

OCSPステープリングの設定と確認方法（Nginx）｜Let’s Encrypt証明書では不要になった理由も解説

サーバーセキュリティ・SSL

OCSPステープリングは、証明書の失効情報をWebサーバーが代わりに取得してTLSハンドシェイクに添付する仕組みです。ただし2026年10月現在、Let's Encrypt はOCSPの提供を終了しており、同社の証明書には OCSP のURLが入っていないため、Let's Encrypt の証明書ではステープリングを設定しても何も起こりません。この記事では、まず自分の証明書がステープリングの対象かを確かめる方法を示し、OCSPを提供しているCAの証明書を使う場合の Nginx の設定（ssl_stapling・ssl_stapling_verify・resolver）と、openssl s_client -status での確認手順を説明します。

OCSPとステープリングの仕組み

証明書は有効期限前でも、秘密鍵の漏えいなどで認証局（CA）が失効させることがあります。ブラウザがその失効状態を問い合わせる手段の一つが OCSP（Online Certificate Status Protocol）で、証明書の「機関情報アクセス（Authority Information Access）」欄に書かれたOCSPレスポンダーのURLへ問い合わせます。

素朴なOCSPには二つの欠点があります。ブラウザが接続のたびにCAへ問い合わせるため表示が遅くなること、そしてCAに「どの利用者がどのサイトを見たか」が伝わることです。OCSPステープリングでは、Webサーバーが定期的にCAからOCSP応答（CAの署名付き）を取得してキャッシュし、TLSハンドシェイクの中でクライアントに渡します。クライアントはCAへ問い合わせずに済み、応答はCAが署名しているのでサーバーが内容を偽ることもできません。

2025年以降の状況：OCSPからCRLへ

業界全体では、失効確認の手段をOCSPからCRL（証明書失効リスト）へ戻す流れが進んでいます。CA/ブラウザフォーラムの基準でOCSPの提供はCAの任意となり、主要ブラウザもOCSPに頼らない仕組みを採用しています。Chrome は以前から独自の失効リスト（CRLSets）を使っており、Firefox もCRLを集約した CRLite への移行を進めています。

Let's Encrypt はこの流れに沿って、2025年5月から新しい証明書にOCSPのURLを入れずCRLのURLを入れるようになり、2025年8月にOCSPレスポンダーを停止しました。OCSP Must-Staple（ステープリングを必須とする拡張）付きの証明書の発行も、それより前の2025年1月に終了しています。Let's Encrypt の証明書の有効期間は90日なので、現在使われている同社の証明書はすべてOCSPのURLを持たない新しい形式です。

そのため、Let's Encrypt の証明書を使っているサイトでは次のように考えて問題ありません。

ステープリングの設定は不要です。設定が残っていても、Nginx は起動時に「証明書にOCSPレスポンダーのURLがないのでステープリングを無視する」という警告を出すだけで、動作には影響しません。
警告が気になる場合は ssl_stapling の行を削除するか off にします。過去に certbot の --staple-ocsp オプションで設定した場合などに、この行が残っていることがあります。
certbot の --must-staple を付けた更新設定が残っていると、更新時にエラーになります。/etc/letsencrypt/renewal/ 配下の設定を確認してください。

一方、商用CA（OV・EV証明書など）の中にはOCSPレスポンダーを運用し続けているところがあります。その証明書を使う場合はステープリングに意味があるので、以下の手順で設定します。ただし各CAの方針は変わりうるので、契約しているCAの告知も確認してください。

自分の証明書にOCSPのURLがあるか確認する

設定の前に、証明書がOCSPに対応しているかを確認します。サーバー上の証明書ファイルを調べる場合と、公開中のサイトから取得して調べる場合の二通りです。

# サーバー上の証明書ファイルを調べる
openssl x509 -in /etc/ssl/example.com/cert.pem -noout -ocsp_uri

# 公開中のサイトの証明書を調べる
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ocsp_uri

http://ocsp. で始まるようなURLが表示されれば、その証明書はOCSPに対応しています。何も表示されなければOCSPのURLはなく、ステープリングは働きません。Let's Encrypt の現行の証明書では何も表示されないはずです。より詳しく見たい場合は openssl x509 -in cert.pem -noout -text の出力で「Authority Information Access」と「CRL Distribution Points」の欄を確認します。

Nginxでステープリングを設定する

OCSPのURLを持つ証明書であれば、HTTPSの server ブロックに次の設定を加えます。設定ファイルを編集する前に、元のファイルをバックアップしておいてください。

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/ssl/example.com/fullchain.pem;  # サーバー証明書＋中間証明書
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    # OCSPステープリング
    ssl_stapling        on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/example.com/chain.pem;  # 中間証明書（＋ルート証明書）

    # OCSPレスポンダーのホスト名を引くためのDNS
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # ...（以下、既存の設定）
}

各ディレクティブの役割は次のとおりです。

ssl_stapling on: ステープリングを有効にします。
ssl_stapling_verify on: CAから受け取ったOCSP応答の署名をNginx自身が検証します。検証に失敗した応答はクライアントへ渡しません。
ssl_trusted_certificate: 検証に使う証明書群です。発行元の中間証明書とルート証明書を含めます。クライアントには送られないので、ルート証明書を入れても通信量は増えません。ssl_certificate に中間証明書が含まれていない場合も、発行元を知るためにここへ中間証明書を入れる必要があります。
resolver: NginxはOCSPレスポンダーのホスト名を実行時に名前解決するため、DNSサーバーの指定が要ります。これがないと、エラーログに「no resolver defined to resolve ...」と出てステープリングが失敗します。サーバー内に systemd-resolved などのローカルのリゾルバーがあれば 127.0.0.53 のように指定しても構いません。IPv6で外へ出られない環境では ipv6=off を付けます。

http2 on; の書き方は Nginx 1.25.1 以降のものです。古いバージョンでは listen 443 ssl http2; と書きます。

設定を書いたら、構文チェックをしてから再読み込みします。

sudo nginx -t
sudo systemctl reload nginx

nginx -t の出力に「"ssl_stapling" ignored, no OCSP responder URL in the certificate」と出た場合は、証明書にOCSPのURLがありません。前の章の確認に戻ってください。

openssl s_client -status で確認する

ステープリングが効いているかは、-status オプションを付けて接続すると分かります。

openssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>/dev/null \
  | sed -n '/OCSP response:/,/^---/p'

効いている場合は、次のような内容が表示されます。

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    ...
    Cert Status: good
    This Update: ...
    Next Update: ...

OCSP Response Status: successful と Cert Status: good が出ていれば正常です。OCSP response: no response sent と表示された場合は、ステープリングされていません。

ここでつまずきやすいのが、Nginx がOCSP応答を「最初の接続をきっかけに」取得する点です。起動や再読み込みの直後の数回の接続には応答が付かず、no response sent になることがあります。数秒おいて2〜3回試し、それでも付かない場合に原因を調べます。また、Nginx のワーカープロセスはそれぞれ応答をキャッシュするため、ワーカー数が多いと全プロセスに行き渡るまで少し時間がかかります。

うまくいかないときの確認ポイント

no response sent が続く場合は、Nginx のエラーログ（/var/log/nginx/error.log など）に OCSP 関連のメッセージが出ていないかを見ます。よくある原因は次のとおりです。

名前解決ができない: resolver の指定漏れや、指定したDNSサーバーへ届かない。
OCSPレスポンダーへ出られない: OCSPは通常HTTP（80番）で通信します。サーバーの外向き通信をファイアウォールで絞っていると失敗します。
検証に失敗する: ssl_trusted_certificate に正しい中間証明書が入っていない。証明書を更新して中間証明書が変わったのに、このファイルを更新していないケースが多いです。

レスポンダー自体が応答しているかは、サーバーから直接問い合わせて確かめられます。

openssl ocsp -issuer /etc/ssl/example.com/chain.pem \
  -cert /etc/ssl/example.com/cert.pem \
  -url "$(openssl x509 -in /etc/ssl/example.com/cert.pem -noout -ocsp_uri)" \
  -resp_text -noverify | grep -E "Response Status|Cert Status"

ここで Cert Status: good が返るのに Nginx がステープリングしない場合は、Nginx側の設定（resolver・trusted certificate）に原因があります。

Apache の場合は、VirtualHost の外に SSLStaplingCache "shmcb:logs/ssl_stapling(32768)" を書き、VirtualHost 内で SSLUseStapling on を指定します。考え方は Nginx と同じで、証明書にOCSPのURLがなければ効きません。

まとめ

OCSPステープリングは、サーバーがCAの署名付きOCSP応答を代わりに取得してクライアントへ渡す仕組みで、表示の高速化とプライバシー保護に役立ちます。
Let's Encrypt は2025年にOCSPを終了し、現行の証明書にはOCSPのURLがありません。同社の証明書ではステープリングの設定は不要で、残っていても警告が出るだけです（2026年10月現在）。
設定前に openssl x509 -noout -ocsp_uri で証明書にOCSPのURLがあるかを確認します。
OCSP対応の証明書なら、Nginx では ssl_stapling・ssl_stapling_verify・ssl_trusted_certificate・resolver をセットで設定します。
確認は openssl s_client -status で行い、再読み込み直後は応答が付かないことがあるので数回試します。