OCSP ステープリング（OCSP Stapling）

概要

OCSP ステープリング（OCSP Stapling） は、サーバーが認証局（CA）の OCSP レスポンダーから事前に取得した証明書の失効状態レスポンスを、TLS ハンドシェイク時にクライアントへ添付（ステープル）する仕組みです。RFC 6066 Section 8（2011 年）の TLS Certificate Status Request 拡張として定義されています。複数証明書への対応は RFC 6961（2013 年）で拡張されました。

従来の OCSP では、クライアントが TLS ハンドシェイクの途中で CA の OCSP レスポンダーに直接問い合わせていました。この方式には 3 つの問題があります。CA がクライアントのアクセス先を把握できるプライバシーの問題、OCSP レスポンダーへの追加 RTT によるレイテンシ、レスポンダーのダウン時の処理（soft-fail か hard-fail か）です。

OCSP Stapling はこれらの問題を解決します。サーバーが代わりに CA へ問い合わせ、署名付きの OCSP レスポンスをキャッシュして TLS ハンドシェイクに含めるため、クライアントは CA と直接通信する必要がありません。

仕組み

サーバーが CA から定期的に OCSP レスポンスを取得してキャッシュし、TLS ハンドシェイクの CertificateStatus メッセージでクライアントに返します。

処理フロー

OCSP Stapling が有効な場合の処理は次の手順で進みます。

1. サーバーが定期的に CA の OCSP レスポンダーへ問い合わせ、署名付きの OCSP レスポンスを取得する
2. サーバーが OCSP レスポンスをメモリにキャッシュする。レスポンスの有効期間は通常 7 日程度
3. クライアントが TLS ハンドシェイクの ClientHello で status_request 拡張を含める
4. サーバーが ServerHello の後に CertificateStatus メッセージとして OCSP レスポンスを返す
5. クライアントは OCSP レスポンスの署名を CA の公開鍵で検証し、証明書の失効状態を確認する

OCSP レスポンスは CA の秘密鍵で署名されているため、サーバーが内容を改ざんすることはできません。クライアントはレスポンスの署名を検証することで、CA から直接受け取った場合と同じ信頼性を得られます。

OCSP Stapling なしとの比較

OCSP Stapling がない場合、クライアントは証明書の Authority Information Access 拡張から OCSP レスポンダーの URL を取得し、直接 HTTP リクエストを送ります。この処理は TLS ハンドシェイクの最中に発生するため、接続確立に追加の RTT が加わります。OCSP レスポンダーが世界中に分散されていない CA では、レイテンシが 100〜300ms 増加するケースがあります。

OCSP Stapling を有効にすると、この追加 RTT がなくなります。サーバーは事前にレスポンスを取得済みで、ハンドシェイクのメッセージに含めるだけです。

OCSP Must-Staple

RFC 7633 で定義された OCSP Must-Staple は、証明書に「OCSP Stapling が必須」と明示するX.509 拡張です。この拡張が含まれた証明書をサーバーが提示する際、OCSP レスポンスが添付されていなければクライアントは接続を拒否します。

通常の OCSP Stapling はサーバーが対応していなくてもクライアントは接続を許可します（soft-fail）。Must-Staple はこの soft-fail を防ぐ設計でしたが、実際の採用率は低く、ブラウザーのサポートも不完全でした。Let’s Encrypt は 2025 年 1 月 30 日以降、Must-Staple 拡張を含む証明書の新規発行を拒否しています。

設定例

Nginx と Apache での OCSP Stapling の有効化手順を示します。

Nginx

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # OCSP Stapling を有効化
    ssl_stapling on;
    ssl_stapling_verify on;

    # 中間証明書チェーン（OCSP レスポンスの署名検証に使用）
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # OCSP レスポンダーの名前解決に使うリゾルバー
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
}

ssl_stapling on が OCSP Stapling の有効化です。ssl_stapling_verify on を設定すると、Nginx が CA から取得した OCSP レスポンスの署名を検証してから使用します。resolver ディレクティブを設定しないと、Nginx が OCSP レスポンダーの名前解決に失敗し、OCSP Stapling が機能しません。

Apache

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile      /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

    # OCSP Stapling を有効化
    SSLUseStapling on
    SSLStaplingCache shmcb:/var/run/ocsp(128000)
</VirtualHost>

Apache では SSLUseStapling on と SSLStaplingCache の両方が必要です。SSLStaplingCache に共有メモリキャッシュを指定することで、ワーカープロセス間で OCSP レスポンスを共有します。

確認方法

openssl で OCSP Stapling が有効かどうかを確認するには次のコマンドを使います。

openssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>/dev/null | grep -A 20 "OCSP response"

OCSP Stapling が有効な場合の出力です。

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Responder Id: ...
    Produced At: Apr 11 00:00:00 2026 GMT
    Cert Status: good
    This Update: Apr 11 00:00:00 2026 GMT
    Next Update: Apr 18 00:00:00 2026 GMT

Cert Status: good であれば証明書は有効です。OCSP response: no response sent と表示された場合は OCSP Stapling が無効か、サーバーがまだ OCSP レスポンスを取得していません。

外部の視点からも確認したい場合は、Labee Dev Toolbox の SSL Cert API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/ssl-cert?hostname=example.com"

{
  "success": true,
  "data": {
    "hostname": "example.com",
    "port": 443,
    "reachable": true,
    "status": 200
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

data.reachable が true であれば TLS ハンドシェイクが成功しています。OCSP Stapling の有無に関わらず、接続の成否を外部視点から確認できます。

よくある問題

OCSP Stapling の運用では、DNS リゾルバー設定の不備や Let’s Encrypt の OCSP 廃止への対応が主な課題です。

Nginx で OCSP Stapling が有効にならない

ssl_stapling on を設定しても OCSP レスポンスが添付されないケースには 2 つの原因があります。

resolver ディレクティブが未設定の場合、Nginx は OCSP レスポンダーの名前解決に失敗します。Nginx はデフォルトで DNS リゾルバーを持たないため、resolver 8.8.8.8 のように明示的に指定します。

ssl_trusted_certificate に中間証明書チェーンを指定していない場合、Nginx は OCSP レスポンスの署名を検証できません。Let’s Encrypt の場合は chain.pem を指定します。

初回接続で OCSP レスポンスが返らない

Nginx は起動時に OCSP レスポンスを取得せず、最初のクライアント接続を受けたタイミングで取得を開始します（lazy loading）。Nginx 起動直後の最初の数接続には OCSP レスポンスが添付されません。openssl s_client -status で確認する際は 2 回以上接続を試行します。

Let’s Encrypt の OCSP 廃止

2025 年 8 月 6 日に Let’s Encrypt は OCSP サービスを終了しました。Let’s Encrypt が発行する証明書には OCSP レスポンダーの URL が含まれなくなり、OCSP Stapling も機能しません。主要ブラウザーは CRLSets（Chrome）や CRLite（Firefox）で失効確認を行っているため、Let’s Encrypt 証明書では OCSP Stapling を無効にしても実用上の影響はありません。

OCSP レスポンスのキャッシュ期限切れ

OCSP レスポンスの Next Update フィールドで指定された時刻を過ぎると、レスポンスは無効になります。サーバーは期限前に新しいレスポンスを取得しますが、OCSP レスポンダーが長時間ダウンしていると、キャッシュが切れてレスポンスなしの状態になります。この場合、OCSP Must-Staple が設定されている証明書ではクライアントが接続を拒否します。