OCSPとは：証明書の失効確認の仕組みとOCSP staplingの設定、CRLへ戻る流れと判断【2026年】

OCSP（Online Certificate Status Protocol）は、TLS証明書が認証局によって失効させられていないかを、その場で問い合わせるためのプロトコルです。この記事では、RFC 6960が定める問い合わせと応答の中身、CRLとの違い、OCSP staplingの仕組みとnginxでの設定、opensslで応答を確かめるコマンドを順に扱います。あわせて、Let’s Encryptが2025年8月にOCSPを停止した経緯と、主要ブラウザがOCSPを問い合わせなくなった現状、TomcatのOCSP検証で続いた脆弱性を踏まえて、soft-failとhard-failのどちらを選ぶべきかを条件付きで示します。

まとめ：OCSPは公開Webでは役目を終えつつあり、社内のクライアント証明書でこそ設計が要る

公開Webサーバーの証明書について、OCSPは主役から降りました。CA/Browser Forumの規則でOCSPの提供は任意になり、CRLの提供が必須に変わっています。Let’s Encryptは2025年8月6日にOCSPレスポンダーを止め、ChromeはもともとOCSPを通常は問い合わせず、Firefoxも独自の失効リストへ切り替えました。新しくWebサーバーを立てるなら、OCSP staplingの設定に時間をかける理由は小さくなっています。

社内の認証局が発行するクライアント証明書でmTLSを組む場合は逆で、端末の紛失や退職者の証明書を無効にするためにOCSPかCRLを必ず組み込みます。要点は、問い合わせ先が落ちたときに接続を通す（soft-fail）か拒否する（hard-fail）かを明示的に決めること。Tomcatではこの扱いをめぐる脆弱性が2026年に4件出ており、既定値任せでは失効が素通りします。

OCSPとは何か、RFC 6960の問い合わせと応答の中身を読み解く

証明書のシリアル番号を送り、good・revoked・unknownの3値を受け取る流れ

OCSPの仕様は2013年6月公開のRFC 6960で、RFC 2560とRFC 6277を置き換えたものです。クライアントは、確認したい証明書の発行者名と公開鍵のハッシュ、シリアル番号を組にして、OCSPレスポンダーと呼ばれるサーバーへHTTPで送ります。

レスポンダーは認証局の鍵（または委任された鍵）で署名した応答を返します。応答の証明書状態は次の3値です。

goodは「失効していない」という意味で、証明書が本当に発行されたことまでは保証しません。証明書チェーンの署名検証は別に行う前提です。TLSのハンドシェイクでチェーンがどう検証されるかは、TLSの仕組みとハンドシェイクの流れで整理しています。

thisUpdate・nextUpdateとnonceで決まる、応答の鮮度とリプレイ対策

OCSP応答には、その状態が正しいと確認された時刻（thisUpdate）と、次に新しい情報が出る時刻（nextUpdate）が入っています。nextUpdateを過ぎた応答は信用しない、というのがRFC 6960の扱いです。認証局の多くは応答を事前に署名して配っており、応答の有効期間は数日単位になるのが一般的です。

過去の応答の使い回しを防ぐ仕組みとしてnonce拡張もあります。ただし事前署名の応答では使えないため、公開認証局のレスポンダーはnonceを付けない運用が大半です。

見落としやすいのはエラー応答です。tryLater（一時的に応答できない）やinternalErrorなどのエラーは署名されません。攻撃者が通信路に入れる立場なら、偽のtryLaterを返して確認を失敗させられます。ここで接続を通すかどうかが、後述するsoft-failとhard-failの問題です。

証明書のAIA拡張に書かれたOCSPのURLを、opensslで取り出す手順

クライアントが問い合わせ先を知る手がかりは、証明書の「機関情報アクセス（AIA）」拡張に書かれたURLです。CRLの取得先は「CRL配布点」拡張に書かれます（RFC 5280）。手元の証明書にどちらが入っているかは、次のコマンドで確かめられます。

# 公開中のサーバー証明書を取得して保存する
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -outform PEM > server.pem

# OCSPのURLだけを表示する（空なら証明書にOCSPの記載が無い）
openssl x509 -in server.pem -noout -ocsp_uri

# AIAとCRL配布点の拡張をまとめて表示する（OpenSSL 3.0以降）
openssl x509 -in server.pem -noout -ext authorityInfoAccess,crlDistributionPoints

Let’s Encryptの証明書で-ocsp_uriが空を返すのは正常です。2025年5月7日以降に発行された同社の証明書にはOCSPのURLが入っておらず、代わりにCRL配布点が入っています。

OCSPとCRLの違いと、CA/B ForumがCRL必須へ戻した経緯

一覧を配るCRLと個別に問い合わせるOCSP、通信量と鮮度の比較

CRL（証明書失効リスト）は、認証局が失効させた証明書のシリアル番号を一覧にして署名し、定期的に配る方式です。クライアントは一覧をまとめて取得し、手元で照合します。OCSPは証明書1枚ごとに問い合わせる方式で、CRLの一覧が大きくなる問題を避けるために作られました。

鮮度の差は思われているほど大きくありません。OCSP応答も事前署名でキャッシュされ、反映の遅れは数日単位になりえます。決定的な差は、OCSPでは接続先のサイトが認証局に伝わる点です。

Ballot SC063でOCSPが任意に、CRLが必須に変わった規則の中身

公開TLS証明書の発行ルールは、認証局とブラウザベンダーが参加するCA/Browser ForumのBaseline Requirementsで決まります。2023年7月に可決されたBallot SC063v4は、名前のとおり「OCSPを任意にし、CRLを必須にする」改正でした。あわせて、有効期間が短い証明書については失効情報の提供を省ける規定も入っています。

認証局はOCSPレスポンダーを維持する義務から解放され、逆にCRLの公開が義務になりました。検証側のソフトウェアがCRLを読めないなら、失効を確認できない証明書が今後も増えていきます。

Let’s Encryptの3段階のOCSP終了日程と、残されたCRL配布点

Let’s Encryptは2024年12月5日にOCSP終了の日程を公表し、2025年中に次の順で実施しました。

1. 2025年1月30日：OCSP Must-Staple拡張つき証明書の新規発行を停止（過去に発行実績のあるアカウントを除く）
2. 2025年5月7日：発行する証明書からOCSPのURLを削除し、Must-Staple拡張つきの要求はすべて拒否
3. 2025年8月6日：OCSPレスポンダーを停止

理由として挙げられたのは、OCSPがインターネット上のプライバシーに大きな危険をもたらすことと、認証局の基盤をできるだけ単純に保つことの2点です。停止当日にはOCSPサービスの終了が告知され、OCSPのURLを含む証明書はすべて期限切れになったと説明されています。発表では、VPNなどブラウザ以外の用途でLet’s Encryptの証明書を使う場合、OCSPのURLが無い証明書で正しく動くかを確かめるよう呼びかけていました。

ChromeとFirefoxはOCSPを問い合わせない、ブラウザ側の失効確認の実態

ChromeはCRLSetsで緊急の失効だけを配り、通常はオンライン確認をしない

ChromiumプロジェクトのCRLSetsの説明には、ChromeはOCSPやCRLのオンライン確認を通常は行わない、と明記されています。代わりに、Googleが選んだ失効情報をCRLSetsという形でブラウザに配り、緊急時の証明書ブロックに使っています。企業ポリシーでオンラインのOCSP確認を有効にすることはできますが、既定では動きません。

つまりChromeの利用者に対しては、サーバー側でOCSP staplingを設定しても失効確認の強さはほぼ変わりません。staplingの価値を「Chromeの表示を速くする」と説明している記事は、前提が古いと考えてください。

FirefoxはCRLite有効化を経て、DV証明書のOCSP確認を止める判断へ

Mozillaは2025年8月のCRLiteの解説記事で、Firefox 137からデスクトップ版の全利用者でCRLiteを有効にし、Firefox 142でドメイン認証（DV）証明書のOCSPを無効にすると発表しています。

CRLiteは、Certificate Transparencyのログに載った証明書の失効情報をすべて圧縮して配る仕組みで、12時間ごとに更新されます。利用者の通信量は1日平均300kB。ChromeのCRLSetsは約600kBで全失効の約1%しか含まない、という比較も同じ記事にあります。

OCSP staplingの仕組みとnginxでの設定、opensslでの応答確認

サーバーが応答を取得してハンドシェイクに添えるstaplingの流れ

OCSP staplingは、クライアントの代わりにサーバーがOCSP応答を取得し、TLSハンドシェイクの中で証明書と一緒に渡す方式です。クライアントはTLSのstatus_request拡張（RFC 6066の8章）で応答を要求し、サーバーはキャッシュしている署名済み応答を返します。TLS 1.3ではこの応答がCertificateメッセージの拡張に入る形に変わりました（TLS 1.3のハンドシェイクの変更点を参照）。

応答は認証局が署名しているため、サーバーが改ざんすることはできません。クライアントはレスポンダーと直接通信せずに済み、閲覧先が認証局に伝わる問題と、問い合わせの遅延の両方を避けられます。

これを強制する仕組みが、証明書に「staplingが無ければ接続を拒否せよ」と書き込むTLS Feature拡張（RFC 7633、通称Must-Staple）です。ブラウザの対応が広がらず、Let’s Encryptも2025年に発行を止めたため、新規に採用する理由はありません。

nginxのssl_staplingと応答の署名検証を有効にする設定例

nginxでは1.3.7以降、ngx_http_ssl_moduleのssl_staplingでstaplingを有効にできます。レスポンダーのホスト名を引くためのresolverと、応答の署名を検証するためのssl_trusted_certificate（中間証明書とルート証明書）をセットで書きます。

server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    # OCSP stapling を有効にし、取得した応答の署名も検証する
    ssl_stapling        on;
    ssl_stapling_verify on;

    # 応答の検証に使う中間証明書＋ルート証明書（クライアントには送られない）
    ssl_trusted_certificate /etc/ssl/example/chain-with-root.pem;

    # OCSPレスポンダーのホスト名解決に使うDNS
    resolver 192.0.2.53 valid=300s;
    resolver_timeout 5s;
}

設定後はnginx -tで文法を確かめてから再読み込みします。証明書にOCSPのURLが無い場合、nginxは「no OCSP responder URL in the certificate」という警告を出してstaplingを無視します。Let’s Encryptの証明書ではこの警告が出るのが正常で、設定の誤りではありません。証明書を差し替えたあとの再読み込みの手順は、SSL証明書の更新手順と反映されない原因の確認で扱っています。

opensslのocspとs_clientで応答の中身と期限を確かめる手順

レスポンダーへの直接の問い合わせと、サーバーがstaplingで返している応答は、どちらもopenssl ocsp系のコマンドで確認できます。

# 1) レスポンダーに直接問い合わせる（issuer.pem は中間証明書）
OCSP_URL=$(openssl x509 -in server.pem -noout -ocsp_uri)
openssl ocsp -issuer issuer.pem -cert server.pem -url "$OCSP_URL" -resp_text -noverify \
  | grep -E "Cert Status|This Update|Next Update|server.pem:"

# 2) サーバーが stapling で応答を添えているか確かめる
openssl s_client -connect www.example.com:443 -servername www.example.com -status </dev/null 2>/dev/null \
  | grep -A 3 "OCSP response"

1つ目でserver.pem: goodとThis Update・Next Updateが表示されれば、レスポンダーは動いています。-noverifyは応答の署名検証を省く指定なので、中身の確認用に限って使ってください。2つ目で「OCSP response: no response sent」と出たら、staplingは機能していません。nginxは最初の接続をきっかけに応答を取りに行くため、再読み込み直後の1回目は応答が付かないことがあります。数秒おいて再実行してから判断します。

soft-failとhard-failの選び方、Tomcatの脆弱性が示す既定値の危うさ

レスポンダー障害で接続を通すsoft-failと、止めるhard-failの違い

OCSPの確認が失敗する原因は、証明書の失効だけではありません。レスポンダーの停止、ネットワークの遮断、タイムアウト、署名されないエラー応答のいずれでも確認は完了しません。このとき接続を通すのがsoft-fail、拒否するのがhard-failです。

ブラウザはこれまでsoft-failを選んできました。認証局のレスポンダーが落ちるたびに世界中のサイトが見られなくなる事態を避けるためです。その代わり、通信路を握った攻撃者はOCSPの通信を遮断するだけで失効確認を無効にできます。公開Webで失効確認の実効性が低いと言われる根本の理由はここにあります。

TomcatのocspSoftFailをめぐる4件のCVEと11.0.26での修正

TomcatのSSLHostConfigの設定項目では、クライアント証明書のOCSP確認をocspEnabled（既定false）で有効にし、レスポンダーに届かないときの扱いをocspSoftFail（既定true）で決めます。既定のままOCSPを有効にすると、soft-failで動きます。

2026年は、このsoft-failの扱いをめぐる脆弱性が続きました。Tomcat 11.0系のセキュリティ情報によると、経緯は次のとおりです。

CVE-2026-86248は2026年9月23日に公表され、影響は11.0.0-M14から11.0.25までです。hard-failを指定したつもりでも失効した証明書が通る、という種類の不具合が1年で4回出たことになります。OCSPを使っているなら11.0.26以降へ上げ、失効させたテスト用証明書で実際に接続が拒否されるかを確かめてください。2026年11月時点の最新は11.0.27です。版ごとのサポート期限はTomcatのバージョン一覧とサポート期限で確認できます。

<!-- conf/server.xml：クライアント証明書を必須にし、OCSPを hard-fail で確認する -->
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           SSLEnabled="true" maxThreads="150">
  <SSLHostConfig certificateVerification="required"
                 truststoreFile="conf/client-ca.p12"
                 truststorePassword="changeit"
                 ocspEnabled="true"
                 ocspSoftFail="false">
    <Certificate certificateKeystoreFile="conf/server.p12"
                 certificateKeystorePassword="changeit" type="RSA" />
  </SSLHostConfig>
</Connector>

certificateVerification="optionalNoCA"を指定するとOCSPも無効になる、という注記も設定リファレンスにあります。クライアント証明書を任意にしたい場面でこの値を選ぶと、失効確認まで外れる点に注意してください。

社内CAとmTLSではhard-failを選び、レスポンダーを冗長化する条件

社内の認証局と社内のレスポンダーで閉じた構成なら、hard-failを選びます。公開Webと違い、レスポンダーの可用性は自社で管理でき、止まったときの影響範囲も把握できるからです。条件は、レスポンダーを2台以上で冗長化し、監視の対象に入れることです。これができないなら、OCSPではなくCRLを定期配布し、手元で照合する方式のほうが障害に強くなります。

クライアント証明書の発行と配布をどう設計するかは、mTLSの仕組みとクライアント証明書の導入判断で扱っています。nginxでクライアント証明書を受ける場合は、ssl_verify_client onとssl_ocsp on（1.19.0以降）の組み合わせでOCSP確認を有効にできます。

OCSPを採用する場面と見送る場面、失効確認を設計する判断基準

公開Webサーバーではstaplingを任意とし、Must-Stapleは採用しない

公開Webサーバーについての結論は明確です。OCSP staplingは、証明書にOCSPのURLがあり、設定の手間が小さいなら有効にしておいてよい程度の位置づけです。主要ブラウザがOCSPを使わない以上、失効確認の強さはほとんど変わりません。Must-Stapleは採用しないでください。認証局がOCSPをやめた時点で、証明書ごと使えなくなる危険があります。

失効確認の弱さを補う手段は、証明書の有効期間を短くし、自動更新にすることです。公開TLS証明書の最大有効期間は2029年3月に47日まで短くなる日程が決まっており、失効させなくても漏れた証明書が早く使えなくなる方向に進んでいます。

ブラウザ以外のクライアントで、OCSP前提の実装を見直すべき条件

影響が出やすいのは、ブラウザ以外のクライアントです。VPN装置、業務用のJavaアプリ、IoT機器、決済端末などで、証明書にOCSPのURLが無いと接続を拒否する実装が残っていることがあります。次のいずれかに当てはまるなら、改修か設定変更の対象です。

• 失効確認をOCSPだけで実装しており、CRL配布点を読まない
• OCSPのURLが証明書に無いと検証エラーとして扱う
• Let’s Encryptなど、OCSPを止めた認証局の証明書と通信する

改修の方向は、CRL配布点を読んで照合する処理を加えるか、接続先を自社の認証局の証明書に限定してピン留めするかのどちらかです。前者は汎用性が高く、後者は閉じた機器間通信に向きます。

失効確認の方式選定とクライアント証明書基盤を外部に相談する目安

社内CAの構築、クライアント証明書の配布、OCSPレスポンダーかCRL配布の選定、Tomcatやnginxでの検証設定は、認証基盤の設計として一体で決めるべき事項です。従業員端末やIoT機器が数百台を超え、失効の即時性と可用性の両方を求められる段階が、設計を外部と詰める目安になります。一創の認証基盤・ID管理システム開発では、証明書による端末認証やSSO・ID連携を含めた認証基盤の設計と開発を支援しています。

よくある質問

OCSPについて、実装や運用の場面でよく出る疑問をまとめます。

OCSPとCRLはどちらを使えばよいですか？

公開TLS証明書を検証するソフトウェアなら、CRLを読めることが前提です。Ballot SC063以降、CRLの提供は認証局の義務で、OCSPは任意だからです。社内CAでは、失効の反映が1日程度遅れても困らないならCRL、即時の無効化が必要でレスポンダーを冗長化できるならOCSPを選びます。迷ったらCRLから始めれば、障害点を増やさずに済みます。

OCSP staplingは今でも設定すべきですか？

必須ではありません。主要ブラウザがOCSPを使わないため、効果は限られます。証明書にOCSPのURLがあり、数行の設定で済むなら有効にしておいて害はない、という程度の位置づけです。Let’s Encryptの証明書では警告が出て無視されます。

Let’s EncryptのOCSP終了で、既存のサイトに影響はありますか？

ブラウザで見るWebサイトには、ほぼ影響はありません。影響が出るのは、OCSPのURLが無い証明書を拒否するVPN装置や業務アプリと、Must-Stapleを指定していたACMEクライアントの設定です。後者は2025年5月7日以降、発行要求そのものが失敗します。

OCSPのレスポンダーが落ちていると何が起きますか？

soft-failなら確認を飛ばして接続を続け、hard-failなら接続を拒否します。TomcatのocspSoftFailは既定でtrueなので、何も指定しなければ接続は通る設定です。hard-failを選ぶ場合、レスポンダーの停止がそのまま業務システムの停止につながる点に備えておく必要があります。

証明書が失効しているかを手元で確かめる方法はありますか？

opensslで確かめられます。openssl x509 -noout -ocsp_uriでOCSPのURLを取り出し、openssl ocspで問い合わせると、good・revoked・unknownのいずれかが表示される仕組みです。URLが無い証明書は-ext crlDistributionPointsでCRLの取得先を調べ、取得したCRLをopenssl crlで読みます。

関連記事

• TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説：失効確認の前段にある、証明書チェーンの検証とハンドシェイクの流れ。
• mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断：OCSPやCRLで失効させる対象になる、クライアント証明書の運用。
• SSL証明書の更新手順：certbotの自動更新と反映されない原因の確認：有効期間の短縮と自動更新で失効確認の弱さを補う手順。
• 電子署名の仕組み：X.509証明書の検証からPAdES長期署名まで：署名検証の場面での失効情報の扱い。
• 電子証明書とは？仕組み・種類・有効期限と取得方法をわかりやすく解説：認証局と失効の考え方を非エンジニア向けに整理。