CRLとOCSPの違いとは？電子証明書の「失効確認」の仕組みを解説

デジタル証明書の有効期限が残っていても、その証明書が「無効」になるケースがあることをご存知でしょうか。秘密鍵の漏洩や、組織の解散、あるいは証明書の誤発行などがその代表例です。

前回の「認証局（CA）」の記事で、認証局の重要な役割として「失効管理」を紹介しました。今回は、ブラウザがどのようにして「この証明書は今この瞬間も本当に有効か」をリアルタイムに検証しているのか、その2つの主要な仕組みであるCRLとOCSPについて詳しく解説します。

なぜ有効期限内の「失効確認」が重要なのか？

デジタル証明書には、通常1年程度の「有効期間」が定められています。しかし、以下のような事態が発生した場合、その証明書は直ちに信頼できないものとなります。

一度発行され、外部に渡された証明書データを、認証局が直接消去することはできません。そのため、「この証明書はもう無効です」という情報を外部から参照できる仕組みが必要になるのです。

CRL（Certificate Revocation List）は、最も古くから利用されている伝統的な失効確認の方法です。

認証局（CA）は、失効させた証明書のシリアル番号を一覧にした「ブラックリスト」を作成し、誰でもダウンロードできる場所に公開します。ブラウザなどのクライアントは、Webサイトにアクセスする際、以下の手順を踏みます。

CRLには「データの肥大化」という深刻な問題があります。

通信負荷： 失効した証明書が増えるほどリストは重くなり、数MBに達することもあります。これをアクセスするたびに取得（またはキャッシュ）するのは、Webサイトの表示速度を著しく低下させます。
即時性の不足： CRLは数時間〜数日おきに更新されるため、失効してからリストに反映されるまでに「空白の時間」が生じるリスクがあります。

CRLの弱点を克服するために登場したのが、OCSPです。

ブラウザはリスト全体をダウンロードする代わりに、「OCSPレスポンダ」と呼ばれる専用サーバーに対してピンポイントで問い合わせを行います。

OCSPはデータ量が極めて少なく、非常に高速です。しかし、新たな懸念も生まれました。

プライバシー問題： 「どのユーザーがどのサイトを見ようとしているか」という情報が、問い合わせ先の認証局に伝わってしまいます。
可用性の依存： もし認証局のOCSPレスポンダがダウンすると、証明書の検証ができなくなり、サイトにアクセスできなくなる（あるいは警告が出る）可能性があります。

プライバシーと速度の問題を同時に解決する決定打として、現在広く普及しているのが「OCSPステープリング」です。

これは、Webサーバー自身が、あらかじめ認証局から「この証明書は有効です」という署名付きの回答を取得しておき、SSL/TLSハンドシェイクの際に証明書と一緒にユーザーへ提示する仕組みです。

情報処理技術者試験（FE/AP）では、CRLとOCSPの「仕組みの違い」と「負荷の差」がよく問われます。

実務におけるサーバー構築時には、単に証明書を貼るだけでなく、「OCSPステープリング」を有効にすることが、SEO対策（表示速度）とセキュリティの両面で最善の選択となります。

これら失効管理の仕組みを含め、信頼を支えるすべての要素を統合した枠組みを「PKI（公開鍵基盤）」と呼びます。