Loading article…
暗号学において、証明書失効リスト（CRL ）とは、「発行認証局（CA）によって予定された有効期限前に失効され、もはや信頼できないデジタル証明書のリスト」である。 [ 3 ]
Web PKI の公的に信頼されている CA は、証明書の CRL を発行することが義務付けられており ( CA/Browser フォーラム[ 4 ]を含む)、広くそうしています。[ 5 ]
ブラウザやその他の依拠当事者は、証明書の失効状態を確認するために、CRL を使用するか、代替の証明書失効技術 ( OCSPなど) [ 6 ] [ 7 ]または CRLSets (CRL から派生したデータセット[ 8 ] ) を使用する場合があります。プライバシーとパフォーマンスの懸念から OCSP の人気が低下しており[ 9 ] [ 10 ] [ 11 ] 、 CRL への回帰につながっていることに注意してください。[ 12 ] [ 13 ]
加入者やその他の関係者もARIを利用できます。[ 14 ]
取り消しには2つの異なる状態があります: [ 1 ]
RFC 5280 [ 15 ]によると、証明書を失効、保留、または非公開にする理由は以下のとおりです。
unspecified（0）keyCompromise（１）cACompromise（２）affiliationChanged（３）superseded（４）cessationOfOperation（５）certificateHold（６）removeFromCRL（８）privilegeWithdrawn（9）aACompromise（１０）値7は使用されないことに注意してください。
CRLは定期的に生成され、多くの場合、定められた間隔で公開されます。CRLは、証明書が失効した直後に公開されることもあります。CRLはCRL発行者によって発行されます。CRL発行者は通常、対応する証明書を発行した認証局（CA）ですが、他の信頼できる認証局である場合もあります。すべてのCRLには有効期間があり、この期間は多くの場合24時間以下です。CRLの有効期間中は、PKI対応アプリケーションが証明書を使用する前に、CRLを参照して証明書を検証することができます。
なりすましやサービス拒否攻撃を防ぐため、CRL（証明書失効リスト）には通常、発行元の認証局（CA）に関連付けられたデジタル署名が付与されています。特定のCRLを信頼する前にその妥当性を検証するには、対応するCAの証明書が必要です。
CRL（証明書失効リスト）を維持すべき証明書は、多くの場合、X.509 /公開鍵証明書です。これは、この形式がPKI（公開鍵基盤）スキームで一般的に使用されているためです。
有効期限はCRL（証明書失効リスト）の代わりにはなりません。有効期限切れの証明書はすべて無効とみなされますが、有効期限内の証明書がすべて有効であるとは限りません。証明書の検証や鍵管理におけるミスは実際の運用において発生することが予想されるため、CRLやその他の証明書検証手法は、適切に運用されるPKI（公開鍵基盤）に不可欠な要素です。
注目すべき例として、Microsoftの証明書が、 ActiveXの「発行者証明書」システム（VeriSign）の保守を委託されている認証局（CA）に対して Microsoft になりすました未知の人物に誤って発行されたケースがある。 [ 16 ] Microsoft は、証明書を信頼する前にその状態を確認するように暗号化サブシステムにパッチを適用する必要性を認識した。短期的な解決策として、関連する Microsoft ソフトウェア（最も重要なのは Windows）にパッチが適用され、問題の 2 つの証明書が「失効済み」として明示的にリストされた。[ 17 ]
ベストプラクティスでは、証明書の状態がどこでどのように維持されているかにかかわらず、証明書に依拠する場合には必ずその状態を確認する必要があります。これを怠ると、失効した証明書が誤って有効とみなされる可能性があります。つまり、PKIを効果的に使用するには、最新のCRLにアクセスできる必要があります。このオンライン検証の要件は、PKIが対称暗号プロトコルに対して持つ本来の大きな利点の1つ、すなわち証明書が「自己認証」できるという利点を無効にしてしまいます。Kerberosのような対称暗号システムも、オンラインサービス（Kerberosの場合は鍵配布センター）の存在に依存しています。
CRL（証明書失効リスト）の存在は、ポリシーを執行し、運用ポリシーに反すると判断された証明書を失効させる担当者（または組織）が必要であることを意味します。証明書が誤って失効された場合、重大な問題が発生する可能性があります。認証局は証明書発行に関する運用ポリシーを執行する役割を担っているため、通常、運用ポリシーを解釈することで、失効が適切かどうか、またいつ失効させるべきかを判断する責任を負います。
証明書を受け入れる前にCRL（またはその他の証明書ステータスサービス）を参照する必要があるため、 PKIに対するサービス拒否攻撃のリスクが生じます。有効なCRLが利用できない状態で証明書の受け入れが失敗すると、証明書の受け入れに依存する操作は一切実行できなくなります。この問題はKerberosシステムにも存在し、最新の認証トークンを取得できない場合はシステムへのアクセスが阻止されます。
CRL（証明書失効リスト）の代替手段として、オンライン証明書ステータスプロトコル（OCSP）と呼ばれる証明書検証プロトコルがあります。OCSPの主な利点は、必要なネットワーク帯域幅が少なく、大量または高価値の取引においてリアルタイムまたはほぼリアルタイムのステータスチェックが可能になることです。
Firefox 28 以降、Mozilla は CRL を廃止し OCSP を優先すると発表しました。[ 6 ]特にOCSP ステープリング[ 18 ] Firefox 142 では、 CRLiteへのさらなる移行が発表されました。[ 19 ]
CRL ファイルは時間の経過とともにかなり大きくなる可能性があり、例えば米国政府では、特定の機関では数メガバイトになることがあります。そのため、増分 CRL が設計されており[ 20 ]、「デルタ CRL」と呼ばれることもあります。しかし、それを実装しているクライアントはごくわずかです。[ 21 ]
認証局失効リスト（ARL）は、失効したエンドエンティティ証明書を含むCRLとは異なり、認証局に発行された失効証明書を含むCRLの一種です。 [ 22 ] [ 23 ]
を補完するために、証明書の失効状態に関するタイムリーな情報を取得する必要がある場合があります。... OCSP は、CRL で可能なよりもタイムリーな失効情報を提供するという運用上の要件の一部を満たすために使用でき、追加のステータス情報を取得するためにも使用できます。