【SC試験】OCSPとCRLの失効確認はこう問われる｜過去問4題の解答例とOCSPステープリング

情報処理安全確保支援士（SC）試験対策、第3週のテーマ「PKIと認証技術」の核心部分に入ります。前回はデジタル証明書による「通信相手の正当性」の保証について解説しました。

しかし、セキュリティにおける「信頼」は永続しません。パスポート紛失時やクレジットカード盗難時に利用停止手続きを行うように、デジタル証明書も有効期限内に強制停止が必要な事態が発生します。これを「証明書の失効（Revocation）」と呼びます。

本記事では、クライアント（Webブラウザなど）が「この証明書は有効か、失効しているか」を確認する仕組みを深掘りします。CRL、OCSP、そして近年の午後試験で頻出のOCSPステープリングについて、その仕組みからメリット・デメリット、サーバー設定まで徹底解説します。

証明書失効の必要性とリスクシナリオ

デジタル証明書には、X.509規格に基づき必ず「有効期間（Validity Period）」が設定されています。パブリックなサーバー証明書の有効期間の上限は短縮が進んでおり、CA/Browser Forumの投票SC-081v3により、2026年3月15日以降に発行される証明書は最長200日、2027年3月15日以降は100日、2029年3月15日以降は47日へと段階的に引き下げられます（それ以前は398日が上限でした）。しかし、どれだけ有効期間を短くしても、この期間内に証明書を無効にすべきケースは存在します。

失効が発生する3つの主要シナリオ

情報処理安全確保支援士試験の問題で以下のケースが描かれた場合、即座に「失効手続きが必要」と判断する必要があります。

① 秘密鍵の危殆化（きたいか）

最も緊急度が高く、深刻なケースです。

サーバーへの不正アクセスによる秘密鍵ファイルの流出
管理者による公開リポジトリへの誤アップロード
OpenSSLなどのライブラリの脆弱性（Heartbleedなど）によるメモリ上の秘密鍵窃取

秘密鍵が攻撃者の手に渡ると、なりすましたフィッシングサイトの構築や通信の復号・盗聴が可能になります。これを防ぐため、対応する公開鍵証明書を直ちに失効させ、世界中のクライアントに「この証明書は信用してはいけない」と周知する必要があります。

② 登録情報の変更

証明書には発行対象（Subject）の情報が含まれています。

企業の合併・買収による組織名変更
ドメイン名の所有権移転
Webサイトの運営停止

実態と異なる情報が記載された証明書の継続使用は信頼性の欠如につながります。特にEV（Extended Validation）証明書のような、厳格な審査を経て組織の実在性を証明するタイプでは、情報の正確性が極めて重要です。

③ CA側の事情や過失

認証局（CA）自身の信頼性が揺らぐ事態です。

CAの秘密鍵危殆化
誤った審査プロセスでの証明書発行の発覚

失効は日常的に起こりうるイベントですが、CAがデータベース上で単に「無効」とマークするだけでは不十分です。クライアントが接続時にその事実に気づけなければ、ユーザーは危険な接続先に情報を送り続けてしまいます。

そこで、失効情報を配布・確認するプロトコルとして、CRLとOCSPが標準化されました。

無料メール講座登録特典FREE PDF

SC午後記述テンプレート集

設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。「知っているのに書けない」を解消する1冊です。

設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し

無料でPDFを受け取る →

＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。

CRL（Certificate Revocation List）：リスト型確認モデル

CRLは、日本語で「証明書失効リスト」と呼ばれ、「ブラックリスト」の配布という非常にシンプルな仕組みです。

CRLの動作フロー

リストの作成 認証局（CA）は、有効期限内であるものの失効させた証明書の「シリアル番号」を列挙したリストを作成します。

署名と発行 CAはこのリスト自体にデジタル署名を付与し、改ざんできない状態にして、CRL配布点（CRL Distribution Point：CDP）と呼ばれるWebサーバー（HTTPリポジトリ）やLDAPサーバーで公開します。

クライアントの確認

ユーザーがWebサイトへアクセスし、サーバー証明書を受け取る
証明書内の「CRL配布点」拡張領域に記載されたURLを確認する
そのURLにアクセスし、CRLファイルをダウンロードする
ダウンロードしたリストの中に、今受け取った証明書のシリアル番号が含まれているか検索する
リストにあれば「失効」として接続断、なければ「有効」として通信継続

CRLの構造的な欠点

CRLは初期のPKIから存在する確実な方法ですが、インターネットの拡大とともに重大な欠点が露呈しました。これらは情報処理安全確保支援士試験でも頻出論点です。

タイムラグ（リアルタイム性の欠如）

CRLは、CAによって「定期的」に発行されます（例：24時間に1回、週に1回など）。もしCRL発行直後に秘密鍵が漏洩し、CAが失効手続きを行っても、その情報が反映された「次のCRL」が発行されるまでの間、クライアントは古いCRLを参照し続け、危険な証明書を「有効」と誤認します。この空白時間はセキュリティ上の大きな隙となります。

クライアントへの負荷と帯域圧迫

大規模な商用CAでは、失効した証明書の数は膨大になります。CRLファイル自体のサイズが数メガバイト〜数十メガバイトに達することも珍しくありません。

Webサイトにアクセスするたびに、ブラウザが巨大なファイルをダウンロードし、展開し、検索を行う処理は、通信帯域を圧迫し、ページの表示速度（レイテンシ）を著しく低下させます。モバイル環境など回線が不安定な場所では、CRLのダウンロード失敗によりWebサイトが見られない事象も発生します。

対策：デルタCRL

「巨大化」問題への対策として考案されたのが「デルタCRL」です。これは、前回発行した完全なCRL（ベースCRL）からの「差分情報」のみを記載した小さなリストです。

クライアントはベースCRLをキャッシュしておき、頻繁に更新される小さなデルタCRLのみをダウンロードしてマージすることで、最新状態を維持します。しかし、管理が複雑になるため、すべての環境で採用されているわけではありません。

3. OCSP（Online Certificate Status Protocol）：リアルタイム照会モデル

CRLの「タイムラグ」と「巨大なファイルサイズ」という課題を解決するために開発されたのが、OCSP（Online Certificate Status Protocol）です。

OCSPの仕組み

CRLが『リスト全体をダウンロードするバルク取得型』方式に対し、OCSPは『特定の証明書についてピンポイントで問い合わせる個別照会型』方式です。

リクエスト送信 クライアント（ブラウザ）は、検証したい証明書のシリアル番号を含んだOCSPリクエストを作成し、証明書に記載されているOCSPレスポンダ（応答サーバー）へ送信します。

データベース照合 OCSPレスポンダは、CAの失効情報データベースを直接（またはそれに近い鮮度で）参照し、その証明書の現在の状態を確認します。

レスポンス返送 レスポンダは、状態を示すステータスにデジタル署名を付与してクライアントへ返します。ステータスは主に以下の3つです。

good：有効（失効リストに存在しない）
revoked：失効（失効済みである）
unknown：不明（OCSPレスポンダが、照会された証明書のステータス情報を保持していない、または判断できない状態）

比較項目	CRL 🗂️	OCSP ⚡
📊 データ量	❌ 大きい(全リスト) 数MB～数十MB	✅ 小さい(個別応答) 数KB
⏱️ リアルタイム性	❌ 低い更新間隔あり(数時間～1日) 古い情報の可能性	✅ 高いリクエスト時点の最新情報即座に反映
🔒 プライバシー	✅ 高い CAに閲覧先を通知しない匿名性が保たれる	❌ 低いアクセス先をCAに通知閲覧履歴が記録される
💰 運用コスト	サーバー負荷: 低帯域: 大	サーバー負荷: 高帯域: 小
🎯 適用シーン	証明書数が少ない環境オフライン検証	リアルタイム性重視大規模環境

OCSPレスポンダとは：どこに置かれ、誰が運用するのか

OCSPの説明で最も曖昧なまま流されやすいのが「OCSPレスポンダ」という登場人物です。午後試験のネットワーク構成図では、この箱が誰の管理下にあり、どのネットワークに置かれているのかを読み違えると、通信経路の設問がまるごと落ちます。

OCSPレスポンダの役割

OCSPレスポンダは、クライアントから受け取った「この証明書は失効していますか」というリクエストに対し、good / revoked / unknown のいずれかのステータスを返す応答専用のサーバーです。返す応答には署名が付与されるため、通信経路上で第三者が「good」に書き換えることはできません。

設置場所と運用主体

OCSPレスポンダは、原則として証明書を発行した認証局（CA）側が運用します。パブリックCAの証明書であればインターネット上のCAの設備、社内に構築したプライベートCAの証明書であれば社内のサーバーが応答元になります。

RFC 6960では、応答に署名する主体として次の形態が規定されています。試験では「CAの秘密鍵そのものを応答署名に使い回すのか」という論点になり得るため、区別しておきます。

CA自身：証明書を発行したCAの鍵で応答に署名する
Authorized Responder（権限を委譲されたレスポンダ）：CAから発行された専用証明書（拡張鍵用途に id-kp-OCSPSigning を持つ）の鍵で署名する
Trusted Responder：クライアント側があらかじめ信頼するよう設定したレスポンダ

問い合わせ先URLはどこに書かれているか

クライアントはレスポンダのアドレスを推測しません。検証対象の証明書の中に書かれているURLへ問い合わせます。具体的には、X.509証明書のAIA（Authority Information Access、機関情報アクセス）拡張にある id-ad-ocsp のURIです。CRLの場合は同じ発想でCRL配布点（CRL Distribution Points、CDP）拡張のURLを見に行きます。

つまり「失効確認URL」とは、証明書のAIA拡張またはCDP拡張に埋め込まれたURLのことです。この一点を押さえておくと、後述する通信要件やプロキシの設問が一気に読みやすくなります。

学び始めの人がつまずきやすいのは、OCSPレスポンダを「CAの本体サーバー」と同一視してしまうことです。実際には証明書の発行機能とは分離して運用されるのが一般的で、負荷分散のためCDNの背後に置かれることもあります。構成図では「CA」と「OCSPレスポンダ」が別の箱で描かれる前提で読んでください。

OCSPのメリット

リアルタイム性 次のリスト発行を待つ必要がなく、問い合わせた時点での最新ステータスを確認できます。

通信量の削減 やり取りされるデータはリクエストとレスポンスの数キロバイト程度であり、CRLに比べて圧倒的に軽量です。

OCSPの新たな問題点（試験重要ポイント）

しかし、OCSPも万能ではありません。以下の2つの問題は、次の技術「OCSPステープリング」への伏線として非常に重要です。

プライバシーの問題

クライアントがOCSPレスポンダに「example.com の証明書は有効ですか？」と問い合わせることは、CAに対し「私は今、example.com を見ています」と自己申告しているのと同じです。つまり、ユーザーの閲覧履歴（行動履歴）がCA側に筒抜けになるというプライバシー上の懸念があります。

可用性とパフォーマンスへの懸念

世界中のすべてのクライアントが、Webサイトにアクセスするたびに、CAのOCSPレスポンダへ接続しに行くと、レスポンダへのアクセス負荷は甚大になります。

もしOCSPレスポンダがダウンしたり、応答が遅かったりした場合、Webサイト自体の表示も遅延します。最悪の場合、検証ができずに接続エラーとなる可能性があります。

OCSPステープリング：現在の最適解

OCSPの「プライバシー問題」と「レスポンダへの負荷集中」を解決する技術として登場し、現在の主流となっているのがOCSPステープリング（TLS Certificate Status Request拡張）です。

「ステープリング（Stapling）」とは、ホチキスで留めるという意味です。証明書に失効情報を「ホチキス留め」して一緒に送るイメージです。

OCSPステープリングの動作フロー

従来のOCSPでは「クライアント」が問い合わせを行っていましたが、OCSPステープリングでは「Webサーバー」が代理で問い合わせを行います。

事前取得（キャッシュ） ： Webサーバーは、定期的（例：数時間おき）にCAのOCSPレスポンダへ問い合わせを行い、自身の証明書に対するOCSPレスポンス（署名付き）を取得し、サーバー内に保存（キャッシュ）しておきます。

ハンドシェイク時の送付 ：クライアントからアクセス（Client Hello）があり、ステープリング対応を示唆された場合、Webサーバーは「Server Hello」や証明書送付のタイミングで、保存しておいたOCSPレスポンスを一緒にクライアントへ送ります。

クライアントによる検証 ：ライアントは、送られてきたOCSPレスポンスを検証します。このレスポンスにはCAの正規のデジタル署名が付与されているため、Webサーバーが内容を改ざんすることはできません。クライアントはCAへ問い合わせる必要がなく、その場で安全性を確認できます。

従来のOCSPとの違い

項目	従来のOCSP	OCSPステープリング
CAへの問い合わせ	クライアントが都度	Webサーバーが事前
クライアント処理時間	+数百ms〜1秒	+0ms(追加なし)
プライバシー	❌ CAにアクセス先が記録	✅ CAにアクセス先が通知されない
CA負荷	高(全クライアント分)	低(証明書数分のみ)

情報処理安全確保支援士試験記述対策：OCSPステープリングの3大メリット

午後試験で「なぜOCSPステープリングを採用するのか」「どのような効果があるか」を問われた場合、以下の3点を組み合わせて解答できるようにしておきましょう。

プライバシー保護

クライアントがCAと直接通信しないため、閲覧先ドメインなどの情報がCAに漏洩しません。

パフォーマンス向上（レイテンシの短縮）

クライアント側でのDNS名前解決や、OCSPレスポンダへのTCP接続・待機時間が不要になります。SSL/TLSハンドシェイクの中で検証が完結するため、Webページの表示が高速化します。

可用性の向上（耐障害性）

仮にCAのOCSPレスポンダが一時的にダウンしても、Webサーバーが有効期限内のOCSPレスポンスをキャッシュしていれば、検証を継続できます。

OCSPベースの失効確認のために必要な設定と通信要件

ここまでで仕組みは押さえました。ここからは「OCSPベースの失効確認を実際に成立させるために、何が揃っていなければならないのか」を、証明書・クライアント・サーバー・通信の4つの層に分けて整理します。午後試験で「失効確認ができていない原因を答えよ」と問われたとき、この4層のどこが欠けているかを探すのが最短ルートです。

① 証明書側の要件：AIA拡張にOCSPレスポンダのURIがあること

前提として、検証対象の証明書のAIA拡張にOCSPレスポンダのURIが入っていなければ、クライアントはOCSPで問い合わせようがありません。この場合はCRL配布点のURLを使った確認に切り替わるか、失効確認そのものが行われないことになります。

また、OCSPで確認すべき対象はサーバー証明書だけではありません。証明書チェーンに含まれる中間CA証明書についても失効確認の対象になります。「サーバー証明書だけ見ればよい」と考えていると、中間CAの危殆化シナリオの設問で足元をすくわれます。

② クライアント側の要件：失効確認が有効で、応答を検証できること

失効確認機能が有効になっていること：ブラウザやOS、ミドルウェアによっては既定で無効、あるいは限定的にしか行わない設定になっています
応答の署名を検証できること：レスポンダの署名を検証するために、CA証明書（必要に応じてOCSP署名用証明書）を信頼できる状態で持っている必要があります
時刻が正しいこと：応答に含まれる thisUpdate / nextUpdate と現在時刻を比較して鮮度を判定するため、端末の時刻が大きくずれていると正当な応答が拒否されることがあります
名前解決ができること：AIA拡張のURIはホスト名で書かれているため、DNSが引けない環境では問い合わせが成立しません

③ サーバー側の要件：ステープリングで代理取得する場合

OCSPステープリングを使う場合、問い合わせの主体はクライアントではなくWebサーバーに移ります。したがって必要な設定もサーバー側に移動します。ステープリングの有効化、取得した応答の署名検証に使うCAチェーンの指定、そしてレスポンダのホスト名を解決するための名前解決設定が揃って初めて機能します。具体的な設定項目は後述の「具体的な設定例（Nginx）の読解」で扱います。

④ 通信要件：OCSPはHTTPで、GETとPOSTを使い分ける

OCSPのメッセージはHTTP上でやり取りされます。RFC 6960の付録A.1では、符号化後のリクエストが255バイト未満であればHTTPキャッシュを効かせるためにGETを使ってよく、キャッシュが重要でない場合や255バイトを超える場合はPOSTを使うべきである、と規定されています。GETが選べるのは、CDNなどのHTTPキャッシュでレスポンダの負荷を下げられるためです。

ここで、学び始めの人がほぼ必ず引っかかる点があります。「失効確認がHTTPの平文なのは危険ではないか」という疑問です。答えは「問題ない」です。OCSP応答にはCA、またはCAから権限を委譲されたレスポンダの署名が付いているため改ざんは検知できますし、失効確認をHTTPSで行おうとすると、その通信で使う証明書の失効確認のためにまた失効確認が必要になるという入れ子が発生します。この理由を説明できるようにしておくと、記述問題で差がつきます。

従来のOCSP：クライアント（社内LANなど）からOCSPレスポンダ宛のHTTP通信
OCSPステープリング：Webサーバー（DMZなど）からOCSPレスポンダ宛のHTTP通信
CRL：確認する側からCRL配布点宛のHTTP通信（応答が数MB規模になることがある）

この「誰が、どこへ、何で出ていくのか」が、次に説明するファイアウォールとプロキシの設問にそのまま接続します。

試験対策：ネットワーク構成とトラブルシューティング

より実戦的な知識として、ネットワーク構成図問題や高度な設定問題への対策を整理します。

ファイアウォールとプロキシ経由の通信経路：失効確認URLへ到達できるか

午後試験のネットワーク構成図では、「どのサーバーからどこへの通信を許可すべきか」が頻出です。失効確認方式によって、許可すべき通信経路が変化することに注意してください。

CRL / 従来のOCSPの場合

主体：クライアントPC（社内LANなど）
宛先：インターネット上のCA（CRL配布点または OCSPレスポンダ）
必要なFW設定：社内LAN -> インターネット（HTTP/80 または HTTPS/443）の許可
注意点：企業のプロキシサーバーなどでこの通信をブロックすると、証明書エラーが発生します

OCSPステープリングの場合

主体：自社のWebサーバー（DMZなど）
宛先：インターネット上のCA（OCSPレスポンダ）
必要なFW設定：DMZ（Webサーバー） -> インターネットへのHTTP/HTTPS許可
注意点：通常、公開サーバーからインターネットへの発信はセキュリティ上制限されることが多いですが、ステープリングを行うためには、この通信穴を開ける必要があります

プロキシ経由での失効確認：失効確認URLへの到達性

社内PCが直接インターネットへ出られず、プロキシサーバー経由でしか通信できない環境は珍しくありません。この構成では、AIA拡張やCRL配布点に書かれた失効確認URLへ、プロキシを通して到達できるかが論点になります。

許可リストの漏れ：業務で使うサイトはプロキシの許可リストに登録されていても、証明書に埋め込まれた失効確認URLのホストは登録から漏れがちです
URLフィルタリングのカテゴリ判定：失効確認URLのホストが「未分類」として扱われ、既定の拒否ルールでブロックされることがあります
プロキシ認証：プロキシ認証が必要な環境では、失効確認を行うコンポーネントが認証に対応していないと、そこだけ通信に失敗します
プロキシ設定を参照しないコンポーネント：利用者のブラウザ設定やPACファイルを読まないサービス（バックグラウンドで動くサーバープロセスなど）は、プロキシを経由せずに直接インターネットへ出ようとして失敗します

厄介なのは、失効確認だけが失敗しても画面上はほとんど何も起きない点です。次項で解説するソフトフェイル動作であれば接続は成立してしまい、失効確認が実質的に行われていない状態が放置されます。逆にハードフェイル動作の機器では、Webサイト自体は生きているのに接続だけができないという切り分けの難しい障害になります。

切り分けの定石は、プロキシやファイアウォールのログに、証明書のAIA拡張／CRL配布点のホスト宛の通信が記録されているかを確認することです。記録が無ければ経路の問題、拒否として記録されていればフィルタリングの問題と切り分けられます。

講師として新卒エンジニアを見ていて多かったのが、この種の通信エラーに対して安易に「全部許可」で通してしまう対応です。失効確認を通したいだけであれば、必要なのはAIA拡張とCRL配布点に書かれたホストへの許可であって、全面許可ではありません。設問でも、必要最小限の許可を答えさせる形で問われます。

「ソフトフェイル」と「ハードフェイル」のジレンマ

セキュリティ運用設計において難しいのが、「失効確認サーバーに繋がらない（タイムアウトする）場合、どう判断するか？」という問題です。

ハードフェイル（Hard Fail）

挙動：確認が取れない場合、「失効している可能性がある」とみなして接続を拒否する
メリット：安全性が高い
デメリット：CA側の障害やネットワーク遅延で、正常なWebサイトが見られなくなる（可用性への悪影響）

ソフトフェイル（Soft Fail）

挙動：確認が取れない場合、「とりあえず有効」とみなして接続を許可する
メリット：可用性が高く、ユーザー体験を損なわない
デメリット：攻撃者がネットワーク的にOCSP通信を妨害すれば、失効した証明書でも接続できてしまう（セキュリティリスク）

現在の主要なWebブラウザ（Chromeなど）は、ユーザー利便性を優先し、デフォルトではソフトフェイル（あるいは独自の集中管理型リストであるCRLSetsなどを使用し、都度のOCSPを行わない）挙動をとることが一般的です。

しかし、情報処理安全確保支援士試験のシナリオで「高いセキュリティレベルが求められる金融システム」などが題材の場合、あえてハードフェイル的な挙動や、閉域網内での厳格なCRLチェックを設計させる問題が出る可能性があります。

具体的な設定例（Nginx）の読解

午後試験では、設定ファイル（httpd.confやnginx.conf）の抜粋が表示され、その意味を問われることがあります。OCSPステープリングに関連する代表的な設定項目を見てみましょう。

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/ca-chain.pem;
resolver 8.8.8.8;

ssl_stapling on; ステープリング機能の有効化スイッチです。

ssl_stapling_verify on; サーバー自身が、CAから取得したOCSPレスポンスの署名を検証するかどうかの設定です。「on」にすることで、破損したレスポンスや偽のレスポンスをクライアントに送ってしまう事故を防げます。

ssl_trusted_certificate OCSPレスポンスの署名を検証するためには、CAの証明書が必要です。中間CA証明書を含むチェーンファイルを指定します。

resolver サーバーがOCSPレスポンダのURL（ホスト名）をIPアドレスに変換するためのDNSサーバー指定です。これを忘れると、サーバーはOCSPレスポンダを見つけられず、ステープリングが機能しません。盲点になりやすい設定です。

証明書の検証プロセス全体像

最後に、証明書の検証プロセス全体を整理します。失効確認は、このプロセスの一部として機能します。

検証の5つのステップ

信頼の起点（トラストアンカー）の確認 送られてきた証明書を発行した「ルート認証局」が、ブラウザやOSの「信頼されたルート証明書ストア」に含まれているかを確認します。

署名の検証 上位のCAの公開鍵を使って、証明書のデジタル署名を復号し、ハッシュ値を比較して改ざんがないことを確認します。これをルートCAにたどり着くまで繰り返します（証明書チェーンの検証）。

有効期限の確認 現在時刻が Not Before（開始日）と Not After（終了日）の間にあるか確認します。

失効確認（CRL / OCSP） ここで今回解説した技術が使われます。チェーンに含まれるすべての中間CA証明書とサーバー証明書に対して、失効していないかを確認します。

ドメイン名の整合性確認 証明書の CN（コモンネーム）または SAN（サブジェクト代替名）に記載されたドメイン名が、ブラウザのアドレスバーに入力したURLと一致しているか確認します。

これらすべてをクリアして初めて、ブラウザのアドレスバーに「鍵マーク」が表示されます。

情報処理安全確保支援士試験における出題パターンと対策

本節では、これまで解説した内容が、実際の情報処理安全確保支援士試験でどのように問われるかを整理します。

実際に出題された失効確認の過去問

失効確認は、午前Ⅱの用語問題だけでなく午後試験の題材としても繰り返し登場しています。出典が確認できるものを挙げます。

午後Ⅰ：空欄補充でOCSPそのものが問われた例

令和2年度 10月情報処理安全確保支援士試験午後Ⅰ 問2 設問1(2)では、S/MIMEを使った電子メールシステムの設計を題材に、証明書の失効状態を確認するプロトコルとしてOCSPを答えさせる空欄補充が出題されました。IPAの採点講評には「SSHやFTPといった解答が散見された」と記載されており、プロトコル名の丸暗記では取りこぼす問題であったことが分かります。

午後Ⅰ：鍵の危殆化発生時の対応として失効が問われた例

平成29年度秋期情報処理安全確保支援士試験午後Ⅰ 問3 設問2(1)では、サーバーの鍵の危殆化を題材に、対応として「利用」の停止と証明書の「失効」を答えさせる問題が出題されました。採点講評でも、危殆化が明らかとなった場合は関係するサーバー証明書の利用を停止し、かつ当該証明書の失効を遅滞なく行わなければならないと述べられています。

午後Ⅱ：失効情報が開示されるまでの時間差が問われた例

平成28年度秋期情報セキュリティスペシャリスト試験午後Ⅱ 問1 設問2(3)では、利用者認証システムの運用を題材に、改善すべき不備として「失効の申請がされてから失効情報の開示まで最短でも2日掛かる」点を指摘させる問題が出題されました。CRLの発行間隔がそのまま失効情報の鮮度になるという、本記事で解説したタイムラグの論点そのものです。

午前Ⅱ：OCSPの利用目的

午前Ⅱでは「PKIを構成するOCSPを利用する目的はどれか」という問題が、平成25年度春期問3（前身の情報セキュリティスペシャリスト試験）、平成29年度秋期問2、平成31年度春期問2と繰り返し出題されています。正解はいずれも「ディジタル証明書の失効情報を問い合わせる」です。鍵の再発行や証明書の更新の進捗確認といった選択肢に引っ張られないよう注意してください。

午前問題での出題傾向

午前問題では、用語の定義や基本的な仕組みを問う問題が中心です。

CRLとOCSPの違いを問う選択肢問題
OCSPステープリングのメリットを問う問題
失効確認の手順を問う問題
ハードフェイルとソフトフェイルの違いを問う問題

これらは用語と概念を正確に理解していれば確実に得点できます。

午後問題での出題傾向

午後問題では、より実践的なシナリオが提示されます。

ネットワーク構成図問題

企業のネットワーク構成図が提示され、「OCSPステープリングを導入する場合、どのサーバーからどこへの通信を許可すべきか」といった問題が出題されます。ファイアウォールのルール設定や、DMZからインターネットへの通信許可の必要性を問われることがあります。

設定ファイル読解問題

Webサーバーの設定ファイル（Apache、Nginxなど）の一部が提示され、「この設定でOCSPステープリングは正しく動作するか」「不足している設定項目は何か」を問われます。特にresolverの設定忘れなど、見落としやすいポイントが狙われます。

セキュリティインシデント対応問題

「秘密鍵が漏洩した疑いがある」といったシナリオが提示され、「どのような手順で対応すべきか」を記述させる問題です。失効手続きの緊急性や、失効後のクライアント側での確認方法についての理解が問われます。

トレードオフ判断問題

「高いセキュリティを求める金融システムと、高い可用性を求めるECサイトで、それぞれどのような失効確認方式を採用すべきか」といった、状況に応じた判断を問う問題です。ハードフェイルとソフトフェイルのメリット・デメリットを理解し、適切に説明できる必要があります。

記述問題の解答テクニック

午後試験の記述問題では、字数制限がある中で要点を的確に表現する必要があります。

「理由を述べよ」系の問題

「OCSPステープリングを導入する理由を述べよ」といった問題では、以下の3点から2つ程度を選んで記述します。

クライアントがCAと直接通信しないため、プライバシーが保護される
SSL/TLSハンドシェイク内で検証が完結し、ページ表示が高速化される
OCSPレスポンダの障害時もキャッシュにより検証を継続でき、可用性が向上する

「設定すべき項目を答えよ」系の問題

設定ファイルの穴埋めや、不足している設定項目を問う問題では、以下のような項目が狙われます。

ssl_stapling（ステープリング有効化）
ssl_stapling_verify（レスポンス検証）
ssl_trusted_certificate（CA証明書チェーン）
resolver（DNSサーバー指定）

特にresolverは見落としやすいため、要注意です。

「対策を述べよ」系の問題

セキュリティインシデント発生時の対応を問う問題では、以下のような手順を記述します。

直ちに対象の証明書をCAに失効申請する
新しい秘密鍵と証明書を生成・取得する
Webサーバーの設定を更新し、新しい証明書をデプロイする
失効情報がクライアントに伝播するまでの期間を考慮し、監視を強化する

実務における失効確認の現状と課題

試験対策を超えて、実務における失効確認の現状についても触れておきます。

ブラウザごとの実装の違い

実は、主要なWebブラウザは、従来のOCSP/CRLによる失効確認を積極的には行っていません。これには以下のような理由があります。

パフォーマンスへの影響 すべてのWebサイトアクセス時にOCSP問い合わせを行うと、ページ表示が遅くなりすぎる。

プライバシーへの懸念 ユーザーの閲覧履歴がCAに筒抜けになる。

可用性の問題 OCSPレスポンダの障害時に、多くのWebサイトが閲覧できなくなる。

そのため、多くのブラウザは独自の仕組みを採用しています。

Google Chromeの場合

Chromeは「CRLSets」という独自の仕組みを使用しています。これは、Googleが独自に収集した失効情報を小さなデータセットにまとめ、ブラウザの自動更新時に配布する方式です。リアルタイム性は低いものの、パフォーマンスとプライバシーのバランスが取れています。

Mozilla Firefoxの場合

Firefoxは「OneCRL」という仕組みを採用しており、Chromeと似た方式です。ただし、EV証明書については、より厳格なOCSP確認を行う場合があります。

OCSPステープリングの重要性

このようなブラウザの実装状況を踏まえると、OCSPレスポンダを提供しているCAの証明書を使う場合、サーバー側でOCSPステープリングを有効にしておく意味は大きくなります。ステープリングが有効であれば、ブラウザ側が都度問い合わせを行わなくても、サーバーが取得した失効情報を受け取れるためです。

Let’s Encryptとの関係

無料SSL証明書を提供するLet’s Encryptは、短期間（90日）の証明書を発行することで、失効確認の重要性を相対的に下げるアプローチを取っています。短期間で証明書が自動更新されるため、失効手続きの必要性自体が減少します。

さらにLet’s Encryptは、この方向をもう一歩進めました。2024年12月にOCSPサポートの終了を予告し、2025年5月に発行する証明書からOCSPのURLを削除、2025年8月6日にOCSPレスポンダのサービスを終了しています。現在、Let’s Encryptの失効情報はCRLで提供されています。

理由として挙げられているのは、まさに本記事で解説したOCSPのプライバシー上の懸念と、レスポンダ運用の負荷です。試験対策としては「OCSPステープリングが最新で唯一の正解」と単純化せず、短命な証明書とCRLの組み合わせという揺り戻しも起きていると押さえておくのが安全です。

なお、証明書にOCSPのURLが含まれていなければ、サーバー側でOCSPステープリングの設定を残していても取得は成功しません。この場合はステープリングを無効化するのが実務上の対応になります。ただし、秘密鍵の危殆化などの緊急時に失効手続きが必要である点そのものは変わりません。

理解度チェック！OCSPとCRLの仕組みに関する練習問題

本記事で解説した「証明書の失効確認（CRL、OCSP、OCSPステープリング）」に関する練習問題（全10問）をご用意しました。
記事の内容がしっかり定着しているか、ぜひチェックしてみてください。選択肢をクリックすると、その場で正誤と詳しい解説が表示されます。正解以外の選択肢がなぜ誤りなのかも併せて確認できるため、知識の整理に役立ててください。

【演習】OCSP・CRL・OCSPステープリング理解度チェック（全10問）

まとめ

本記事では、PKIにおける「信頼の取り消し」である失効確認技術について解説しました。

3つの方式の特徴

CRL：確実だが重く、リアルタイム性に欠ける「リスト配布型」 定期的に発行されるブラックリストをクライアントがダウンロードする方式。確実だが、ファイルサイズが大きく、リアルタイム性に欠けます。

OCSP：リアルタイムだがプライバシーと負荷に課題がある「都度問い合わせ型」 クライアントが必要な時にCAへ問い合わせる方式。リアルタイムだが、プライバシーの問題とレスポンダへの負荷集中が課題です。

OCSPステープリング：サーバーが代理取得することで高速・安全・プライベートを実現した「現在のベストプラクティス」 Webサーバーが事前にOCSPレスポンスを取得し、証明書と一緒にクライアントへ送る方式。プライバシー保護、パフォーマンス向上、可用性向上という3つのメリットを実現します。

試験対策のポイント

試験対策としては、単に用語を覚えるだけでなく、「誰が（クライアントかサーバーか）」「どこへ（CAかWebサーバーか）」通信を行うのかというフロー図を頭に描けるようにすることが重要です。

特に午後試験の記述問題では、「なぜステープリングが有効なのか」を、パフォーマンス、プライバシー、可用性の観点から論理的に説明できる力が求められます。

また、ネットワーク構成図問題では、失効確認方式によってファイアウォールで許可すべき通信経路が変わることを理解しておく必要があります。

設定ファイル読解問題では、resolver設定の有無など、見落としやすいポイントに注意しましょう。

次回予告

次回は、いよいよ認証技術のもう一つの柱、「ユーザー認証」の世界に入ります。

パスワードだけでは守りきれない現代において必須となる「多要素認証（MFA）」や、パスワードレスを実現する「FIDO/FIDO2」、そしてSSO（シングルサインオン）の仕組みまで、一気に解説していきます。

デジタル証明書による「サーバー認証」の理解に続き、「ユーザー認証」の技術を習得することで、PKIと認証技術の全体像が完成します。次回もお楽しみに。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP（https://www.rfc-editor.org/rfc/rfc6960.html）
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile（https://www.rfc-editor.org/rfc/rfc5280.html）
RFC 6066: TLS Extensions（Certificate Status Request＝OCSPステープリング）（https://www.rfc-editor.org/rfc/rfc6066.html）
IPA 情報処理技術者試験過去問題（令和2年度）（https://www.ipa.go.jp/shiken/mondai-kaiotu/2020r02.html）
IPA 情報処理技術者試験過去問題（平成29年度）（https://www.ipa.go.jp/shiken/mondai-kaiotu/2017h29.html）
IPA 情報処理技術者試験過去問題（平成28年度）（https://www.ipa.go.jp/shiken/mondai-kaiotu/2016h28.html）
Let’s Encrypt: OCSP Service Has Reached End of Life（https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/）
CA/Browser Forum: Ballot SC-081v3 Introduce Schedule Reducing Validity and Data Reuse Periods（https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/）
nginx: ngx_http_ssl_module（ssl_stapling ほか）（https://nginx.org/en/docs/http/ngx_http_ssl_module.html）