3. PKIと認証技術

OCSPとCRL徹底解説！証明書の失効確認方法とOCSPステープリングの仕組み

2025年12月17日

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

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

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

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

デジタル証明書には、X.509規格に基づき必ず「有効期間（Validity Period）」が設定されています。現在、一般的なサーバー証明書の有効期間は最長で397日（約13ヶ月）程度ですが、この期間内でも証明書を無効にすべきケースが存在します。

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

SC試験の問題で以下のケースが描かれた場合、即座に「失効手続きが必要」と判断する必要があります。

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

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

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

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

② 登録情報の変更

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

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

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

③ CA側の事情や過失

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

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

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

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

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

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

CRLの動作フロー

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

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

クライアントの確認

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

CRLの構造的な欠点

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

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

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

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との違い

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

SC試験記述対策：OCSPステープリングの3大メリット

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

プライバシー保護

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

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

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

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

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

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

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

ファイアウォールと通信経路

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

CRL / 従来のOCSPの場合

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

OCSPステープリングの場合

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

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

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

ハードフェイル（Hard Fail）

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

ソフトフェイル（Soft Fail）

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

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

しかし、SC試験のシナリオで「高いセキュリティレベルが求められる金融システム」などが題材の場合、あえてハードフェイル的な挙動や、閉域網内での厳格な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と一致しているか確認します。

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

SC試験における出題パターンと対策

本節では、これまで解説した内容が、実際のSC試験でどのように問われるかを整理します。

午前問題での出題傾向

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

  • 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ステープリングを有効にすることの重要性が増しています。ステープリングが有効であれば、ブラウザは確実に最新の失効情報を受け取ることができます。

Let's Encryptとの関係

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

しかし、それでも秘密鍵の危殆化などの緊急事態には失効が必要であり、Let's EncryptもOCSPに対応しています。

学んだ知識を定着させよう

ここまでの内容が理解できたか、簡単なクイズで確認してみましょう。

【演習】OCSPとCRL 失効確認メカニズム（全10問）

まとめ

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

3つの方式の特徴

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

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

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

試験対策のポイント

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

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

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

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

次回予告

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

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

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

-3. PKIと認証技術