LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

OCSPとCRLの違いを聞かれて、「問い合わせるか、一覧を取りに行くか」までは答えられても、VPN装置の設定でどちらを有効にすればよいかとなると手が止まる。認証局がOCSPをやめるという発表を見ても、自社のシステムに影響があるのかが分からない——。証明書を使うシステムの運用では、こうした迷いが起こりがちです。OCSP（Online Certificate Status Protocol）とCRL（Certificate Revocation List、証明書失効リスト）は、どちらも有効期限の前に取り消された証明書を見分ける仕組みで、CRLは失効した証明書の一覧を配り、OCSPは1枚ずつ状態を問い合わせます。

どちらを使うかは、接続の相手とネットワークの条件で変わります。ただし万能ではなく、CRLには失効が伝わるまでの時間差があり、OCSPには問い合わせ先が止まったときの扱いとプライバシーの問題があります。本記事では、システム開発と運用の担当者に向けて、それぞれの仕組み、両者の違い、コマンドと設定の例、使いどころ、つまずきやすい点、そして外部に頼むときに確認したい点を整理します。

証明書の失効とは

証明書は、有効期間の最後まで使われる前提で発行されます。ところが、名前の変更、利用者と認証局の関係の変化（従業員の退職など）、秘密鍵の漏えいやその疑いがあると、期間の途中でも無効にしなければなりません。^*1 こうしたときに認証局が証明書を取り消すことを失効と呼びます。

有効期限は証明書に書かれているので手元で判定できますが、失効したかどうかは証明書を見ても分かりません。認証局の出す別の情報を取りに行く必要があり、その出し方が一覧のCRLと、問い合わせのOCSPの2通りです。

取りに行く先は証明書の拡張に書かれ、CRLはCRL配布点（CRL Distribution Points）、OCSPは認証局情報アクセス（Authority Information Access、AIA）という拡張に入ります。署名をたどって発行元を確かめる手順は「証明書チェーンの仕組み」で扱っており、失効の確認はそれと並ぶもう一つの確認です。

CRLの仕組み

CRLは、認証局かCRLの発行者が署名した、時刻付きの失効証明書の一覧です。失効した証明書はシリアル番号で載り、受け取った側は十分に新しいCRLを手に入れて、確かめたい証明書の番号が載っていないかを見ます。一覧には、そのCRLを出した日時（thisUpdate）と、次のCRLをいつまでに出すか（nextUpdate）が入ります。

CRLは署名されているので、信頼できないサーバーや通信路を通して配ってもかまいません。その裏返しとして、失効が伝わる速さはCRLを出す間隔で決まります。RFC 5280は、CRLの発行間隔に応じて、失効の報告が利用者に行き渡るまで1時間、1日、1週間かかりうると説明しています。^*1

一覧が大きくなる問題には、前回の完全なCRLからの更新分だけを載せるデルタCRLで対応できます。失効の理由は理由コード（reasonCode）として付けられ、鍵の漏えい（keyCompromise）などを区別できます。

OCSPの仕組み

OCSPは、1枚の証明書について「いま失効しているか」を問い合わせるプロトコルで、RFC 6960が定めています。問い合わせでは、発行元の名前と公開鍵それぞれのハッシュ値、それに証明書のシリアル番号の組（CertID）で対象を示します。応答者（OCSPレスポンダー）は、署名した応答で次の3つのどれかを返します。

• good：問い合わせたシリアル番号の証明書で、有効期間内のものに失効したものは無い
• revoked：失効している（一時的な保留を含む）
• unknown：応答者がその証明書を知らない（担当していない発行元など）

注意したいのは、goodであってもその証明書が発行されたことまで意味するわけではないと、RFC 6960が書いている点です。また、応答者が一時的に答えられないときはtryLaterといった誤りの応答を返し、この誤りの応答には署名が付きません。^*2

応答には、状態が正しいと分かっている時刻（thisUpdate）と、次の情報が出る時刻（nextUpdate）が入ります。応答は前もって作り置いてもよく、古い応答を送り返す攻撃には、問い合わせと応答を結び付けるナンス（nonce）という拡張で備えます。

OCSPとCRLの違い

OCSPとCRLの違いを観点ごとに並べると、次のようになります。

プライバシーの違いは、Let’s EncryptがOCSPをやめた理由でもあります。同社は、ブラウザーなどがOCSPで確かめると、応答者を運営する認証局に、どのIPアドレスからどのWebサイトが訪問されたかが伝わると説明しています。^*3 CRLは一覧をまとめて取るので、この問題が起きません。

公開の認証局に対する業界の基準も、CRLの側に寄っています。CA/Browser ForumのBaseline Requirements（公開のTLSサーバー証明書を発行する認証局の基準）2.3.0版は、発行するすべての証明書にOCSPの問い合わせ先を載せる認証局には7日ごと、それ以外には4日ごとにCRLを出し直し、失効を記録したら24時間以内に更新するよう求めています。OCSPの問い合わせ先を載せるかどうかは任意です。^*4

両者の中間にあたるのが、図の右端のOCSPステープリングです。TLSの接続の始めにクライアントがstatus_requestという拡張で求めると、サーバーは前もって取っておいたOCSPの応答を証明書のすぐ後に添えて送ります。応答を添えることを証明書で約束させるTLS Feature拡張（通称Must-Staple）もあり、添えられていなければ即座に接続を失敗させられます。^*5

コマンドと設定の例

手元の証明書がどちらの方式に対応しているかは、OpenSSLで確かめられます。証明書に書かれた取得先を表示し、CRLの発行日時と次の更新日時を見て、最後に失効を含めて検証します。

# 証明書に書かれたCRL配布点とOCSPの問い合わせ先を表示する
openssl x509 -in server.pem -noout -ext crlDistributionPoints,authorityInfoAccess

# CRLを取得して、発行日時と次の更新日時を確かめる（DER形式の例）
curl -s -o ca.crl http://crl.example.jp/ca.crl
openssl crl -in ca.crl -inform DER -noout -lastupdate -nextupdate

# CRL配布点からCRLを取り、失効を含めて検証する
openssl verify -crl_check -crl_download -CAfile chain.pem server.pem

OCSPでは、発行元の証明書と対象の証明書を渡して応答者に問い合わせます。結果にはgood・revoked・unknownのどれかと、thisUpdate・nextUpdateの日時が出ます。サーバーが応答を添えているかは、s_clientの-statusで見られます。

# 応答者に直接問い合わせる
openssl ocsp -issuer issuer.pem -cert server.pem \
  -url http://ocsp.example.jp -resp_text

# サーバーがOCSPの応答を添えて返しているかを確かめる
openssl s_client -connect www.example.jp:443 -status < /dev/null

サーバー側の設定は、nginxなら次のようになります。ステープリングを働かせるには、発行元の証明書が分かることと、応答者のホスト名を引くためのresolverの指定が要ります。^*6 クライアント証明書で相手を確かめる接続では、ssl_crlでPEM形式のCRLファイルを指定します。このファイルは手元に置くものなので、社内の認証局がCRLを出し直すたびに置き換える仕組みを別に用意します。

server {
    listen 443 ssl;
    ssl_certificate         /etc/nginx/tls/fullchain.pem;
    ssl_certificate_key     /etc/nginx/tls/server.key;

    # OCSPステープリング（発行元がOCSPを提供している場合）
    ssl_stapling            on;
    ssl_stapling_verify     on;
    ssl_trusted_certificate /etc/nginx/tls/chain.pem;
    resolver                192.0.2.53;

    # 社内の認証局が出したクライアント証明書をCRLで確かめる
    ssl_client_certificate  /etc/nginx/tls/internal-ca.pem;
    ssl_verify_client       on;
    ssl_crl                 /etc/nginx/tls/internal-ca.crl.pem;
}

使いどころ

公開するWebサイトでは、失効を確かめるのは主にブラウザーです。サイトの側で気にかけたいのは、サーバーがステープリングを前提にした設定になっていないかと、発行元がOCSPを続けているかです。

発行元の方針が変わった例がLet’s Encryptです。2024年7月23日にOCSPをやめてCRLだけで失効の情報を出す意向を示し^*7、2024年12月5日には、証明書からOCSPの問い合わせ先を外す日を2025年5月7日、応答者を止める日を2025年8月6日とする日程を公表しました。^*3 応答者は予定の日に停止されました。^*8 同社は、影響を受けうるのはVPNなどブラウザー以外のソフトウェアだとしていました。

社内の認証局でクライアント証明書を配る場面、たとえば取引先とのAPI連携や社内VPNでは、失効の確認は自社で設計するものになります。退職や機器の廃棄で失効させてから何時間で接続を止めたいかを先に決め、CRLを出す間隔をそれに合わせます。相互に証明書を確かめる接続の全体像は「mTLSとは」、発行から失効までの管理は「証明書管理(PKI)システム」で扱っています。

有効期間のごく短い証明書で、失効の確認に頼らない考え方もあります。Baseline Requirementsは、2026年3月15日以降に発行する有効期間7日以内の証明書を短期の証明書とし、失効への対応もCRL配布点の記載も任意にしています。^*4

つまずきやすい点

一つめは、確認できなかったときの扱いです。Let’s Encryptは、多くのOCSPの実装は応答を取れなくてもシステムを止めない「fail open」の動きをすると説明しています。^*7 その場合、応答者に届かないときは失効した証明書も通ります。逆に厳しく確かめる設定では確認できないこと自体が障害になり、OpenSSLの-crl_checkも有効なCRLが無ければエラーにします。どちらに倒すかは接続ごとに決め、設定に書き残しておきます。

二つめは、CRLの期限切れです。nextUpdateを過ぎたCRLを持ち続けると、厳しく確かめるクライアントやサーバーでは有効なCRLが無いと扱われ、正しい証明書まで弾かれることがあります。nextUpdateまでの残り時間は、証明書の有効期限と同じように監視します。

三つめは、閉じたネットワークからの到達です。CRL配布点もOCSPの応答者もたいていHTTPのURLで、外部へ出られない業務サーバーからは取りに行けません。どのURLへの通信を許すのか、あるいはCRLを手元に置いて配るのかを、構成を決める段階で決めておきます。

四つめは、OCSPだけを前提にした作りです。OCSPの問い合わせ先が無い証明書に入れ替わったとき、失効を確かめられないとして接続を拒む機器やライブラリがあると、証明書を更新した日に通信が止まります。証明書を入れ替える前に、検証用の環境で新しい証明書を読ませて動きを確かめておきます。

外部に委託するときに確認しておきたい点

失効の確認は発行元・サーバー・クライアントの3者にまたがり、一部の設定だけを頼むと抜けが出やすいので、委託先にはまず自社の接続を棚卸しし、どの通信でOCSPとCRLのどちらを使っているか、どの認証局の証明書かを一覧にしてもらうとよいでしょう。

提案では、確認できなかったときに接続を止めるか通すかの決め方、社内の認証局のCRLを出す間隔、nextUpdateを監視する仕組み、証明書を入れ替える前に検証用の環境で確かめる手順があるかを確かめます。発表を追って設定を見直す役目を契約のどこに入れるかも、あわせて決めておきます。

まとめ：失効の確認で確かめておきたい3つの点

OCSPとCRLの違いを踏まえて失効の確認を組み立てるうえで、確かめておきたい点は3つに整理できます。第一に、自社の証明書と接続先ごとに、CRLとOCSPのどちらで失効を確かめているかを把握すること。第二に、確認できなかったときに接続を止めるか通すかを決め、CRLの期限と応答者を監視の対象にすること。第三に、発行元の認証局の方針を追い、OCSPの問い合わせ先が無い証明書でも動くかを、入れ替えの前に確かめることです。この3点を踏まえておけば、「証明書を更新したら、VPNだけがつながらなくなった」という事態を避けやすくなります。失効の確認の方式選びや社内の認証局の運用に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IETF RFC 5280「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」（https://www.rfc-editor.org/rfc/rfc5280）。出典：3.3 Revocation（失効の事情、CRLの定義、発行間隔と伝わるまでの時間）、5.1.2.4〜5.1.2.5（thisUpdate・nextUpdate）、5.2.4（デルタCRL）、5.3.1（理由コード）を参照（2026年10月確認）
2. *2　参考：IETF RFC 6960「X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP」（https://www.rfc-editor.org/rfc/rfc6960）。出典：2.1〜2.5（問い合わせと応答、good・revoked・unknownの意味、誤りの応答、thisUpdate・nextUpdate、応答の作り置き）、4.1.1（CertIDの構造）、4.4.1（ナンス）を参照（2026年10月確認）
3. *3　参考：Let’s Encrypt「Ending OCSP Support in 2025」（2024年12月5日）（https://letsencrypt.org/2024/12/05/ending-ocsp/）。出典：OCSP終了の日程（2025年5月7日に証明書からOCSPのURLを削除、2025年8月6日に応答者を停止）、プライバシー上の理由、ブラウザー以外のソフトウェアへの影響を参照（2026年10月確認）
4. *4　参考：CA/Browser Forum「Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates」Version 2.3.0（https://cabforum.org/working-groups/server/baseline-requirements/documents/）。出典：4.9.1.1（失効の期限）、4.9.7（CRLの発行頻度）、4.9.9（OCSP応答の有効な時間の幅）、7.1.2.11.2（CRL配布点）、1.6.1の短期の証明書の定義、7.1.2.7.7（サーバー証明書の認証局情報アクセス。OCSPの記載はMAY）を参照。2026年9月7日付の2.3.0版による（2026年10月確認）
5. *5　参考：IETF RFC 7633「X.509v3 Transport Layer Security (TLS) Feature Extension」（https://www.rfc-editor.org/rfc/rfc7633）。出典：Abstract（OCSPの応答が添えられない場合に即座に失敗させられること）を参照（2026年10月確認）
6. *6　参考：nginx「Module ngx_http_ssl_module」（https://nginx.org/en/docs/http/ngx_http_ssl_module.html）。出典：ssl_stapling・ssl_stapling_verify・ssl_trusted_certificate・ssl_crl の各ディレクティブの説明を参照（2026年10月確認）
7. *7　参考：Let’s Encrypt「Intent to End OCSP Service」（2024年7月23日）（https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/）。出典：OCSPを終了しCRLで失効情報を出す意向、多くのOCSP実装がfail openであるとの説明を参照（2026年10月確認）
8. *8　参考：Let’s Encrypt「OCSP Service Has Reached End of Life」（2025年8月6日）（https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/）。出典：OCSPサービスを停止したこと、以後はCRLだけで失効情報を出すことを参照（2026年10月確認）
9. *9　参考：IETF RFC 6066「Transport Layer Security (TLS) Extensions: Extension Definitions」（https://www.rfc-editor.org/rfc/rfc6066）。出典：8. Certificate Status Request（status_request拡張とCertificateStatusメッセージ）を参照（2026年10月確認）
10. *10　参考：OpenSSL「openssl-verification-options」（OpenSSL 3.0 マニュアル）（https://docs.openssl.org/3.0/man1/openssl-verification-options/）。出典：-crl_check（有効なCRLが見つからなければエラー）の説明を参照。あわせて openssl-x509・openssl-crl・openssl-ocsp・openssl-s_client・openssl-verify の各マニュアルでオプションを確認した（2026年10月確認）

Tweet