CRLとOCSP徹底比較！PKIにおける失効証明書管理の重要性 - 城咲子｜情シスセキュリティ担当のつぶやき（ぼやき）

こんにちは、情報セキュリティ担当の城咲子です。

前回の記事では、PKIの基本的な仕組みと、デジタル証明書、公開鍵、秘密鍵の役割について解説しました。今回は、PKIを運用する上で非常に重要な「証明書の失効管理」について深掘りしたいと思います。

デジタル証明書は、有効期限内であれば常に信頼されるわけではありません。例えば、証明書とペアになる秘密鍵が漏洩したり、証明書の所有者が組織を離脱したりした場合、その証明書は「失効」させる必要があります。

もし失効した証明書が放置されれば、なりすましや不正利用のリスクが大幅に高まります。そのため、PKIにおいて、どの証明書が失効したかを効率的に、かつ確実に通知する仕組みが不可欠です。

本記事では、この失効証明書の管理方法として主に用いられる「CRL」と「OCSP」について、その仕組み、メリット、デメリットを徹底的に比較し、どちらがより優れているのか、そして実際の運用ではどう使い分けるべきかを、私の専門的な知見から解説します。

この記事が、あなたの組織のセキュリティ運用を強化する一助となれば幸いです。

1. 証明書の失効管理とは？なぜ必要なのか

証明書の失効管理とは、有効期限内であっても何らかの理由で信頼できなくなった証明書を無効化し、その情報を関係者に周知するプロセスです。

失効が必要になる主なケースは以下の通りです。

失効管理が適切に行われないと、不正な証明書がいつまでも有効なものとして扱われ、セキュアな通信が脅かされます。この問題を解決するために登場したのが、次に解説するCRLとOCSPです。

CRL (Certificate Revocation List) は、その名の通り、失効した証明書のリストです。

認証局（CA）は、失効した証明書の情報（シリアル番号など）をリストにまとめ、定期的にデジタル署名を付与して公開します。
このリストは、通常、WebサーバーやLDAPサーバーなどで一般に公開されます。
証明書の検証を行うクライアント（Webブラウザなど）は、通信相手から証明書を受け取った際、公開されているCRLをダウンロードして、その証明書がリストに含まれていないか確認します。

メリット:
- オフラインでの検証が可能: 一度リストをダウンロードすれば、その後はオフラインでも検証が可能です。
- シンプルな仕組み: 比較的古くから使われている技術であり、広く普及しています。
デメリット:
- リアルタイム性の低さ: リストは定期的に（例えば1日1回）更新されるため、リスト更新前の失効情報が反映されません。
- リストサイズの増大: 失効証明書が増えるにつれてリストのサイズが大きくなり、ダウンロードに時間がかかることがあります。

OCSP (Online Certificate Status Protocol) は、証明書の失効状態をリアルタイムで確認するためのプロトコルです。

クライアント（Webブラウザ）は、通信相手から証明書を受け取った際、その証明書の情報（シリアル番号など）を添えて、OCSPレスポンダーと呼ばれる専用のサーバーに問い合わせを行います。
OCSPレスポンダーは、リアルタイムな失効情報を確認し、証明書が「有効」「失効」「不明」のいずれであるかをクライアントに返答します。
クライアントは、レスポンダーの返答に基づいて、通信を続行するかどうかを判断します。

メリット:
- リアルタイム性の高さ: 問い合わせる度に最新の失効情報を確認できるため、CRLのデメリットを補います。
- 通信量の少なさ: リスト全体をダウンロードするCRLに比べて、個別の証明書についてのみ問い合わせるため、通信量が少なくて済みます。
デメリット:
- オンライン環境が必須: 常にOCSPレスポンダーと通信できる環境が必要です。
- プライバシーの問題: どの証明書をいつ検証したかという情報がOCSPレスポンダーに記録されるため、プライバシー上の懸念があります。