OCSP（Online Certificate Status Protocol）とは何ですか？

証明書が失効しているかをリアルタイムで確認するプロトコル。OCSP Stapling によってプライバシー問題を改善できます。

SSL

OCSP（Online Certificate Status Protocol）

Q: OCSP（Online Certificate Status Protocol）の概要について教えてください

OCSP（Online Certificate Status Protocol） は、X.509 デジタル証明書の失効状態をリアルタイムで問い合わせるプロトコルです。RFC 2560（1999 年）で最初に定義され、RFC 6960（2013 年）で改訂されました。

2026年1月29日更新

概要

OCSP（Online Certificate Status Protocol） は、X.509 デジタル証明書の失効状態をリアルタイムで問い合わせるプロトコルです。RFC 2560（1999 年）で最初に定義され、RFC 6960（2013 年）で改訂されました。

証明書が失効しているかを確認する手段は、OCSP の前は CRL（Certificate Revocation List）でした。CRL は失効した証明書のシリアル番号を一覧にしたファイルで、CA が定期的に公開します。しかし CA によっては CRL のサイズが数 MB に達し、ダウンロードと検証のコストが問題でした。OCSP はこの問題を解決し、特定の証明書 1 枚の状態だけを問い合わせる仕組みです。

ただし、従来の OCSP にはプライバシー上の問題があります。クライアントが CA の OCSP レスポンダーに直接問い合わせるため、CA はどのクライアントがどのサイトにアクセスしたかを把握できます。また、OCSP レスポンダーへの追加 RTT が発生し、レスポンダーがダウンしている場合の処理（soft-fail か hard-fail か）もセキュリティと可用性のトレードオフになります。

仕組み

OCSP はクライアントから CA への直接問い合わせ、OCSP Stapling によるサーバー経由の配信、Must-Staple による強制の 3 つの方式があります。

OCSP の基本的な処理フロー

クライアントが OCSP を使って証明書の状態を確認する手順は次のとおりです。

クライアントがサーバーから証明書を受け取る
証明書の Authority Information Access 拡張フィールドから OCSP レスポンダーの URL を取得する
クライアントが OCSP レスポンダーに HTTP リクエストを送る。リクエストには証明書のシリアル番号と発行者の情報が含まれる
OCSP レスポンダーが good、revoked、unknown のいずれかで応答する
クライアントは応答結果に基づいて証明書を受け入れるか拒否するか判断する

OCSP レスポンスは CA の秘密鍵で署名されており、改ざんを検証できます。

OCSP Stapling

OCSP Stapling は、OCSP のプライバシー問題とレイテンシを解消する仕組みです。TLS Certificate Status Request 拡張として RFC 6066 Section 8（2011 年）で定義され、複数証明書への対応を RFC 6961（2013 年）が拡張しています。クライアントが CA に直接問い合わせる代わりに、サーバーが事前に OCSP レスポンスを取得して TLS ハンドシェイクに添付（ステープル）します。

処理の流れは次のとおりです。

サーバーが定期的に CA の OCSP レスポンダーに問い合わせ、署名付きの OCSP レスポンスを取得する（通常数時間ごと）
クライアントが TLS ハンドシェイクの CertificateStatus メッセージで OCSP レスポンスを受け取る
クライアントは CA に直接問い合わせることなく、サーバーから取得したレスポンスで証明書の状態を確認できる

OCSP Stapling の主な利点は 3 つあります。CA がクライアントのアクセス先を把握できないためプライバシーが向上します。OCSP 問い合わせの RTT がなくなるためレイテンシが改善します。OCSP レスポンダーがダウンしても、サーバーにキャッシュされたレスポンスを使えるため可用性が向上します。

OCSP Must-Staple

OCSP Stapling のさらなる発展として、RFC 7633 で OCSP Must-Staple 拡張が定義されました。この拡張が証明書に含まれると、クライアントはサーバーからの OCSP レスポンスが必須だと判断し、レスポンスなしでは接続を拒否します。

通常の OCSP Stapling は任意であり、サーバーがレスポンスを添付しなくても多くのクライアントは接続を許可します（soft-fail）。Must-Staple はこの soft-fail の抜け道を塞ぐ意図で設計されました。

しかし実際の採用率は低く、ブラウザーのサポートが不完全でサーバー実装も不安定でした。Let’s Encrypt は 2025 年 1 月 30 日以降、OCSP Must-Staple 拡張を含む証明書の発行リクエストを拒否し、2025 年 5 月 7 日以降は更新リクエストも含めて完全に拒否しています。

設定例

Nginx と Apache で OCSP Stapling を有効化する設定を示します。

Nginx での OCSP Stapling

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;

    # 中間証明書チェーン（fullchain.pem で代用可）
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # OCSP レスポンスの問い合わせに使うリゾルバー（Google Public DNS）
    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 レスポンスの署名を検証します。ssl_trusted_certificate には中間証明書を含むチェーンを指定します。

Apache での OCSP Stapling

<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
    Responses:
    Certificate ID:
    ...
    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 が無効です。

外部の視点からも確認したい場合は、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 の運用では、サーバー設定の不備と Let’s Encrypt の OCSP 廃止に伴う対応が主な課題です。

OCSP Stapling が有効にならない

Nginx で ssl_stapling on を設定しても OCSP レスポンスが添付されない場合、原因として以下が考えられます。

resolver ディレクティブが設定されていないと、Nginx が OCSP レスポンダーの名前解決に失敗します。Nginx のデフォルト設定には DNS リゾルバーが含まれないため、明示的に resolver 8.8.8.8 などを指定します。

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

Let’s Encrypt 証明書の OCSP Must-Staple を含む更新失敗

2025 年 5 月 7 日以降、Let’s Encrypt は OCSP Must-Staple 拡張を含む証明書の更新を拒否します。以前に --must-staple オプション付きで発行した証明書を更新しようとすると失敗します。certbot の設定ファイル（/etc/letsencrypt/renewal/example.com.conf）から must_staple = True の行を削除してから更新を実行します。

OCSP レスポンスの有効期限切れ

OCSP レスポンスには有効期限があります（通常 7 日程度）。Nginx は有効期限が切れる前に自動的に再取得しますが、OCSP レスポンダーがダウンしている期間が長いと、キャッシュが切れて古いレスポンスを返し続けるか、レスポンスなしになります。OCSP レスポンダーのダウンを検知するには、監視と alerting で OCSP ステープリングの状態を定期的に確認します。

Let’s Encrypt による OCSP の廃止

2025 年 8 月 6 日、Let’s Encrypt は OCSP サービスを終了しました。主な理由はプライバシーです。OCSP レスポンダーは証明書を発行した CA が運用するため、クライアントから大量のアクセスログが集まり、「どのユーザーがどのサイトを訪問したか」を CA が追跡できる状態を構造的に作り出すと判断しました。

Let’s Encrypt は現在、失効情報を CRL のみで提供しています。主要ブラウザーの失効確認の実態を見ると、OCSP への依存はすでに薄れています。Chrome は OCSP のリアルタイム問い合わせを行わず Google が独自配布する CRLSets を使い、Firefox は CRLite という圧縮リスト方式を採用しています。短命証明書（有効期間が数日から数週間）の普及も、失効確認の重要性を下げる方向に働いています。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す