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

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

CRL（Certificate Revocation List）とは、電子証明書が有効期限内であっても、秘密鍵の漏えい・紛失、証明書情報の誤り、利用停止などの理由で失効（revocation）された場合に、その失効情報をまとめて公開するためのリストです。CRLは認証局（CA）が発行・署名し、PKI（公開鍵基盤）の信頼性を保つために使われます。

CRLとは何か？

CRLには、失効した証明書を識別するための情報（例：証明書のシリアル番号）と、失効日時（revocationDate）などが記録されます。運用やポリシーにより、失効理由（reasonCode）を含める場合もあります。CRLにはCAのデジタル署名が付与されており、クライアントは署名検証を通じてCRL自体の正当性を確認できます。

CRLを必要とする状況

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

CRLの働きと役割

CRLはCAによって一定間隔で更新され、HTTPやLDAPなどを通じて配布されます。クライアント（ブラウザ、OS、ミドルウェア等）は証明書検証の過程でCRLを参照し、対象証明書が失効済みであれば、警告表示や接続拒否の判断に使います。これにより、失効済み証明書が使われ続けるリスクを抑え、PKI全体の信頼性を支えます。

CRLで分かること・分からないこと

CRLの基本構造

CRLを理解する際は、「証明書」と「失効（revocation）」を分けて整理すると把握しやすくなります。また、CRLは標準化されたデータ形式で表現されます。

証明書とは

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

失効とは

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

CRLの形式：ASN.1とDER

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

CRLの主な項目

PKIとCRL

公開鍵基盤（PKI）とは

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

PKIにおけるCRLの重要性

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

CRL確認の流れ

1. CAが証明書を発行する
2. 証明書失効が必要になった場合、CAまたはCRL発行主体が失効情報をCRLへ反映する
3. CRLが配布先（HTTP、LDAPなど）に公開される
4. クライアントが証明書検証時にCRLを取得または参照する
5. 対象証明書のシリアル番号がCRLに載っていれば、失効済みとして扱う

CRLの作成と配布

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

CRLは通常は認証局（CA）が発行し、署名により正当性が担保されます。運用によっては、CAがCRL発行責任を別主体へ委任する場合もあります。証明書の失効が発生すると、失効情報はCRLに反映され、次回更新分として配布されます。

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

CRLの更新と配布

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

CRLの扱いと利用

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

CRL参照は、ブラウザ／OS／ミドルウェアの実装やポリシーに依存します。証明書検証では、CRLやOCSPに加え、製品固有の失効情報配布機構が使われることもあります。失効済みと判断できれば警告やブロックの判断材料になりますが、失効確認ができない場合（オフライン、配布先に到達できない等）をどう扱うかには実装差があります。そのため、要件に応じて運用方針を先に決めておくことが重要です。

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

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

失効確認の設計ポイント

運用設計では、単にCRLやOCSPを参照するだけでなく、確認できなかった場合をどう扱うかまで決めておく必要があります。

CRLとOCSP

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

OCSP（Online Certificate Status Protocol）の概要

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

CRLとOCSPの比較

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

一般論として、CRLはリストが大きくなるほど配布・検索の負荷が増えやすく、更新間隔によっては失効反映までのタイムラグも生じます。一方、OCSPは個別照会で新しい状態を得やすい反面、レスポンダーの可用性や遅延の影響を受けます。また、問い合わせが発生する以上、プライバシー面の論点も残ります（この点を緩和する代表例がOCSP Staplingです）。

CRLの問題点と今後

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

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

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

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

Must-Stapleなどの関連動向

証明書に「Staplingされた失効情報の提示」を前提にできる仕組みとして、TLS Feature拡張（いわゆるMust-Staple）の仕様が整理されています。これにより、クライアントはStaplingの提示を前提に検証を進められますが、実際の効果はクライアント実装や運用状況に左右されます。

FAQ（よくある質問）

Q. CRLとは何ですか？

A. CRLは、失効した電子証明書の情報をCAがまとめて公開する「証明書失効リスト」です。証明書が期限内でも信頼できなくなった場合に、失効を周知する目的で使われます。

Q. 証明書は有効期限内でも失効するのですか？

A. はい。秘密鍵の漏えい・紛失、証明書情報の誤り、利用停止などの理由で、有効期限前に失効されることがあります。

Q. CRLにはどんな情報が載りますか？

A. 代表的には失効した証明書のシリアル番号と失効日時が載ります。運用によっては失効理由（reasonCode）も含まれます。

Q. CRLは誰が作って配布しますか？

A. 通常は認証局（CA）がCRLを作成し、署名して配布します。運用によってはCRL発行責任が別主体へ委任される場合もあります。配布はHTTPやLDAPなどが一般的です。

Q. CRLはどこから取得しますか？

A. 多くの場合、証明書内にCRL配布先（CRL Distribution Points）が記載されており、クライアントはそこから取得します。

Q. CRLとOCSPの違いは何ですか？

A. CRLは「失効した証明書の一覧」を配布する方式で、OCSPは「特定の証明書が今有効か」を個別に問い合わせる方式です。

Q. OCSPは常に高速で確実ですか？

A. 一般に最新状態を得やすい一方、レスポンダーの可用性や遅延の影響を受けます。運用・実装によっては失効確認ができない場合の扱いも課題になります。

Q. OCSP Staplingとは何ですか？

A. サーバー側がOCSPレスポンスを取得してTLSハンドシェイク時に提示する方式です。クライアント側の追加問い合わせを減らし、遅延やプライバシー面の懸念を緩和しやすくなります。

Q. Must-Stapleとは何ですか？

A. 証明書側で「Staplingされた失効情報の提示」を前提にできるTLS Feature拡張です。実際の効果は、クライアントの対応状況や運用設計によって変わります。

Q. 企業でCRL/OCSP運用を設計する際の注意点は？

A. 更新頻度、キャッシュ、オフライン時の扱い（失効確認ができない場合の判断）、レスポンダー可用性、監査・ログなどを要件として整理し、方式（CRL/OCSP/Stapling）を組み合わせて設計するのが現実的です。