IT用語集 2023/10/06

CRLとは？わかりやすく10分で解説

コラム

CRL（Certificate Revocation List：証明書失効リスト）の概要

CRL（Certificate Revocation List）とは、電子証明書が有効期限内であっても、秘密鍵の漏えい・紛失、証明書情報の誤り、利用停止などの理由で失効（revocation）された場合に、その失効情報をまとめて公開するためのリストです。CRLは認証局（CA）が発行・署名し、PKI（公開鍵基盤）における信頼性の維持に欠かせません。 :contentReference[oaicite:0]{index=0}

CRLとは何か？

CRLには、失効した証明書を識別するための情報（例：証明書のシリアル番号）と、失効日時（revocationDate）などが記録されます。失効理由（reasonCode）を含めることもあります。CRLはCAのデジタル署名により改ざん耐性が担保され、クライアントは署名検証を通じてCRLそのものの正当性を確認できます。 :contentReference[oaicite:1]{index=1}

CRLを必要とする状況

電子証明書は、TLS（HTTPS）やS/MIMEなどで「相手が正しい主体であること」と「通信を暗号化できること」を支える仕組みです。ところが、証明書が有効期限内でも、秘密鍵が漏えいした可能性がある、証明書に誤った情報が含まれていた、運用上の都合で利用を停止したい、といった事情で途中で無効化（失効）する必要が生じます。こうした失効をクライアント側が判断できるよう、失効情報を配布する代表的な仕組みがCRLです。 :contentReference[oaicite:2]{index=2}

CRLの働きと役割

CRLはCAによって一定間隔で更新され、HTTPやLDAPなどを通じて配布されます。クライアント（ブラウザ、OS、ミドルウェア等）は証明書検証の過程でCRLを参照し、対象証明書が失効済みであれば、原則として通信を継続しない（警告やブロックを行う）判断材料にします。これにより、失効済み証明書が使われ続けるリスクを低減し、PKI全体の信頼性を支えます。 :contentReference[oaicite:3]{index=3}

CRLの基本構造

CRLを正しく理解するには、「証明書」と「失効（revocation）」を分けて整理するのが近道です。また、CRLは標準化されたデータ形式で表現されます。

証明書とは

証明書はデジタル世界における身分証明書のようなもので、主体（サーバー、組織、個人など）と公開鍵の結び付きを第三者（CA）が署名によって保証します。クライアントは、CAの署名を検証することで「その証明書が（信頼できるCAにより）正しく発行されたものか」を確認します。 :contentReference[oaicite:4]{index=4}

失効とは

証明書には有効期限がありますが、有効期限前でも「もう信用できない」と判断すべき状況が起こり得ます。典型例は秘密鍵の漏えい・紛失です。こうした場合に、証明書を期限前に無効化する手続きが「失効（revocation）」です。失効した証明書の情報を配布する仕組みとしてCRLが利用されます。 :contentReference[oaicite:5]{index=5}

CRLの形式：ASN.1とDER

CRLはX.509の仕様に基づき、ASN.1で定義された構造をDER（Distinguished Encoding Rules）でエンコードした形式で表現されます。これにより、異なる実装・異なる環境でも同じ意味として解釈できます。 :contentReference[oaicite:6]{index=6}

PKIとCRL

公開鍵基盤（PKI）とは

公開鍵基盤（PKI）は、公開鍵暗号とデジタル署名を土台に、相手の真正性確認や暗号化通信を成立させる仕組みです。TLS（HTTPS）、S/MIMEなど、さまざまな用途で利用されています。

PKIにおけるCRLの重要性

PKIでは、CAが「主体と公開鍵の結び付きを保証する証明書」を発行します。ただし、証明書が発行された後に信頼性が失われるケース（秘密鍵漏えい等）もあるため、「この証明書は今も信用できるか」を判断する手段が必要です。CRLは、そのための失効情報の配布を担い、PKI全体の信頼性を支えます。 :contentReference[oaicite:7]{index=7}

CRLの作成と配布

CRLの発行元：認証局（CA）

CRLは認証局（CA）が発行し、CAの署名により正当性が担保されます。運用上、証明書の失効が発生すると、CAはCRLに失効情報を追加し、次回更新分として配布します。 :contentReference[oaicite:8]{index=8}

※なお、CAは「証明書（公開鍵と主体情報の結び付きを署名で保証するデータ）」を発行します。一般に、秘密鍵そのものをCAが配布するわけではありません（鍵生成は利用者側で行う場合が多く、CAは公開鍵等を含むCSRを受けて証明書を発行します）。

CRLの更新と配布

CRLは一定の頻度で更新されます（更新間隔はCAのポリシーによって異なります）。配布手段としてはHTTPやLDAPがよく用いられ、証明書内のCRL配布先情報（CRL Distribution Points）にURL等が記載される構成が一般的です。 :contentReference[oaicite:9]{index=9}

CRLの扱いと利用

ブラウザとOSでのCRLの扱い

CRL参照は、ブラウザ／OS／ミドルウェアの実装やポリシーに依存します。一般には証明書検証の一部としてCRL（またはOCSP）を参照し、失効済みと判断できれば警告やブロックの判断材料になります。ただし、オフライン時の扱い（失効確認ができない場合にどうするか）は実装差が大きいため、要件に応じて設計・運用方針を明確化することが重要です。

ユーザーがCRLを利用する方法

多くの場合、一般ユーザーがCRLを直接操作する場面は多くありません。一方で、企業・組織の管理者は、セキュリティポリシーや運用要件に応じて、端末やゲートウェイ、プロキシ等でCRL参照やキャッシュ、更新間隔などを設計・管理します。

CRLとOCSP

本章では、CRLとよく比較される「証明書の失効状態を確認する方式」であるOCSP（Online Certificate Status Protocol）について整理し、両者の違いをまとめます。

OCSP（Online Certificate Status Protocol）の概要

OCSPは、特定の証明書について「現在有効か（失効していないか）」をオンラインで問い合わせるためのプロトコルです。OCSPレスポンダーは、一般にCA（またはCAから委任された運用主体）により提供され、レスポンスとして「good / revoked / unknown」などの状態を返します。 :contentReference[oaicite:10]{index=10}

CRLとOCSPの比較

CRLは「失効した証明書の一覧」を定期配布する方式で、クライアントは入手したリスト内に対象証明書が含まれるかを確認します。OCSPは「この証明書は今どうか」を個別に問い合わせる方式です。 :contentReference[oaicite:11]{index=11}

一般論として、CRLはリストが大きくなるほど配布・検索の負荷が増えやすく、更新間隔によっては失効反映までのタイムラグが生じます。一方、OCSPは個別照会で最新状態を得やすい反面、レスポンダー可用性や遅延、さらに「どのサイトにアクセスしようとしたか」が推測され得るプライバシー面の論点が指摘されます（この点を緩和する代表例がOCSP Staplingです）。 :contentReference[oaicite:12]{index=12}

CRLの問題点と今後

CRLのスケーラビリティとパフォーマンス

CRLの課題として典型的なのは、証明書発行数・失効数が増えるほどリストが肥大化しやすい点です。CRLのサイズ増大は、配布（ダウンロード）やキャッシュ、検索処理の負担につながります。対策として、運用設計（更新頻度の最適化、配布基盤の強化）や、必要に応じた方式選択（OCSPやStaplingの併用）を検討します。 :contentReference[oaicite:13]{index=13}

CRLからOCSPへ：失効確認方式の発展

CRLの配布・検索負荷やタイムラグを補うため、OCSPのような個別照会方式が普及してきました。さらに、TLSハンドシェイク時にサーバー側がOCSPレスポンスを提示する「OCSP Stapling」により、クライアントが都度レスポンダーへ問い合わせる必要を減らし、遅延やプライバシー面の懸念を緩和できます。 :contentReference[oaicite:14]{index=14}

Must-Stapleなどの関連動向

証明書に「Staplingされた失効情報の提示」を要求する方向性として、TLS Feature拡張（いわゆるMust-Staple）の仕様が整理されています。これにより、クライアントはStaplingの提示を期待でき、失効確認の確実性向上に寄与します（ただし実際の効果はクライアント実装・運用状況に依存します）。 :contentReference[oaicite:15]{index=15}