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

CRL (Certificate Revocation List) の概要

CERTIFICATE REVOCATION LIST（CRL）とは、電子証明書の有効期間中に、秘密鍵の紛失 ･ 盗難等の事由により、発行した電子証明書を失効した際に、認証局 (CA) 毎に作成される、失効情報が記載されているリストです。CRLは、電子証明書の信頼性を保つために欠かせないものです。

CRL とは何か？

CRLは、各デジタル証明書のシリアル番号と失効の日付、失効の理由を記録しています。CRLに記録された情報は公開鍵基盤（PKI）の一部として公開され、証明書を検証する際に参照可能です。

CRL を必要とする状況

電子証明書はウェブサイトのセキュリティに不可欠な要素であり、ユーザ・サーバー間の情報の暗号化と、ウェブサイトが本物で表示されている情報が正しいことの証明のために使用されます。しかし、証明書が何らかの理由で信頼性を失った場合や、証明書の責任者によってその有効性が取り消された場合、その証明書情報はCRLに追加されます。あるウェブサイトにアクセスしようとしたとき、サイトの証明書がCRLに記載されていた場合、ウェブサイトの信頼性が識別されて警告が表示され閲覧しないように、適切な行動をとることができます。

CRL の働きと役割

CRLは証明書認証局（CA）によって定期的に更新され、その情報はインターネットを通じてアクセスできるように公開されます。つまり、CRLの主な役割は、失効した証明書の情報提供による、ネットワーク上でのデジタル証明書の信頼性維持です。CRLにより、ユーザーは安全にウェブサイトを利用でき、機密情報の保護やインターネット犯罪からの防御に役立ちます。

CRL (Certificate Revocation List) の基本構造

CRLの理解を深めるためには、まず証明書とその失効についての理解が重要です。また、CRL自身がどのような形式で表現されるのかも確認しておきましょう。

証明書とは

証明書はデジタル世界における身分証明のようなものです。財布などに入れている運転免許証や身分証と同じく、その人の存在を証明するために使われます。証明書には、その証明書の所有者の情報だけでなく、その証明書を発行した信頼できる第三者、つまり証明書認証機関（CA）の情報も含まれています。証明書の有効性を検証する際には、このCAのデジタル署名がチェックされます。

失効とは

証明書には有効期限が存在します。しかし、有効期限が来る前に、もし証明書の所有者の秘密鍵が漏洩した場合や情報が間違っていた場合など、証明書を無効にしなければならない事情が生じることがあります。証明書を無効にすることを、「失効」または「リボケーション」と呼びます。失効した証明書の情報はCRLという形で公開され、証明書をチェックする際にはCRLも参照されます。

CRLの形式：ASN.1とDER

CRLは、複雑なデータ構造を持つ証明書の情報を一意に表現するための言語であるASN.1（Abstract Syntax Notation One）フォーマットで表現されます。そして、そのASN.1データがさらにバイト列として一意に表現される、DER（Distinguished Encoding Rules）エンコーディングが用いられます。これによって、どのシステムでも同じようにCRLのデータを解釈でき、証明書の失効状況を確認することができます。 CRLは、どんなコンピュータやシステムでも証明書の情報を読み取り失効状況を確認できるように、ASN.1フォーマットという言語で表現されます。

PKIとCRL

公開鍵基盤(PKI)とは

公開鍵基盤（PKI）は、安全なデジタル通信のための重要な仕組みです。PKIとは、公開鍵と秘密鍵という2つの鍵を使って、情報を暗号化したり反対に暗号化を解いたり（復号化）するシステムのことを指し、情報の安全な送受信に利用されます。PKIは、S/MIMEのメール暗号化、SSL< / strong>のウェブサイト保護など、さまざまな場面で使用されている技術です。

PKIにおけるCRLの重要性

PKIにおいてCRLは重要な役割を持っています。公開鍵と秘密鍵のペアを発行するのが認証局（CA）で、CAが発行した証明書が信頼できなくなった場合、その事実をすぐにすべての関連者に伝えるのに使われるのがCRLです。証明書失効リスト（CRL）は、CAによって発行・管理され、信頼できない証明書をすべて記録しています。一度証明書がCRLに載せられたら、正当な公開鍵情報として利用できません。

したがって、CRLはPKIシステム全体の信頼性を保つために非常に重要な役割を果たします。CRLが正確かつ迅速に更新され、広く配布されることによって、信頼できない証明書による不正アクセスや情報漏れなどのリスクを防止できます。

CRLの作成と配布

ここでは、CRLの作成と配布について詳しく説明します。まずはCRLを発行・管理する証明書認証機関（CA）の理解を深めましょう。

CRL発行元：証明書認証機関（CA）

証明書認証機関（CA）は、CRLの発行元です。 まず、CAは公開鍵とその関連情報を含む証明書を発行し、秘密鍵とペアで配布します。証明書は、公開鍵を使うためのIDカードのようなものといえるでしょう。所有者は、公開鍵で情報を暗号化したり、秘密鍵で情報を復号化したりできます。これは、鍵を使って情報を金庫に入れたり、金庫から出したりするイメージです。

しかし、万が一その鍵を落としたり鍵が盗まれたりした場合や、金庫そのものが危険な状態に晒された場合には、証明書の信頼を剥奪する必要があります。この証明書の信頼剥奪がCRLであり、CRLの発行はCAの役割です。証明書への不正なアクセスがあったり、証明書の所有者が信頼性を失ったりした場合に、その証明書をCRLに登録して失効させます。

CRLにより、情報を安全にやりとりできる環境と信頼性は維持されているといえます。誤った鍵や不正な鍵を使えないようにするイメージです。

CRLの更新と配布

次に、CRLの更新と配布について説明します。CRLの頻繁な更新により、失効した証明書が使われるリスクを仁族に失くせます。逆に、更新が滞ると失効した証明書を使った不正アクセスのリスクがあるといえるでしょう。

通常、CAは一定の頻度でCRLを更新します。更新頻度はCAのポリシーにより異なりますが、一般的には1日から数日程度です。その際、CAは新しいCRLを生成し、信頼できる場所（通常はウェブサーバー）に配布します。CRLを必要とするクライアントは、所定の場所からCRLをダウンロードして利用します。

CRLの配布にはLDAP（Lightweight Directory Access Protocol）やHTTPが用いられるのが一般的です。これらのプロトコルを通じて、クライアントは定期的にCRLを確認し、必要に応じて更新します。これにより、クライアントは常に最新の証明書の状態を把握し、安全な通信が可能です。CRLは、なんらかの事情で証明書を失効させる必要が出てきた場合に、速やかな対応を可能にします。

CRLの扱いと利用

ここでは、CRLの使用について、特にブラウザやオペレーティングシステム（OS）でどのようにCRLが扱われるか、一般のユーザーが具体的にCRLをどのように利用するかについて見ていきます。

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

CRLは、主にブラウザとOSの間で重要な役割を果たします。ブラウザやOSは信頼できる証明書を持つすべてのウェブサイトと通信するために用いられます。しかし、サイトの証明書が何らかの理由で無効化されたとき、対策としてCRLが登場します。

ブラウザとOSは、通信を開始する前に証明書の有効性を確認するためにCRLを参照します。証明書がCRLに含まれている場合、つまり証明書が無効であると判断された場合、ブラウザはそのサイトとの通信を拒否します。これにより、偽のサイトや危険なサイトからユーザーを保護可能です。

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

CRLはブラウザとOSが自動的に調査・管理するため、一般のユーザーがCRLを直接利用することはほとんどありません。ユーザーはブラウザを使ってウェブサイトに安全にアクセスするだけで、CRLは証明書の有効性をチェックしています。

ただし、特定の需要がある場合には、端末を手動で設定すればCRLの直接管理も可能です。たとえば、企業のシステム管理者は、特定の証明書をブロックしたい場合など、CRLを更新したり、カスタマイズしたりすることがあります。

要するに、一般的なユーザーがCRLを意識することはほとんどないものの、CRLはバックグラウンドでユーザーのセキュリティを保護するための重要な道具として働いています。

CRLとOCSP

本章では、CRLとよく比較される認証書の失効状態を確認するプロトコルであるOCSP（Online Certificate Status Protocol）について詳しく見ていきます。また、両者の主要な違いと利点・欠点も紹介します。

OCSP（Online Certificate Status Protocol）の概要

OCSPは、リアルタイムで証明書の失効状態をオンラインで問い合わせることができるプロトコルです。OCSPは、証明書を使用する際にそれが有効かどうかを確認するために用いられます。

具体的には、OCSPクライアント（例えば、ウェブブラウザ）がOCSPレスポンダー（通常は証明書認証機関）に対し、特定の証明書のステータスを問い合わせます。レスポンダーはその証明書が有効（すなわち、失効していない）ならば"good"、失効していれば"revoked"、そして認証機関が該当証明書について情報を持っていない場合は"unknown"というレスポンスを返します。

OCSPを使えば証明書の失効状態をリアルタイムで知ることができ、失効リストのダウンロードと検索が必要なCRLと比べて、効率的に最新の情報を得られる場合があります。

CRLとOCSPの比較

CRLとOCSPの違いは、証証書のステータスを確認する方法です。CRLでは、証明書の失効リストを配布し、受け取ったユーザーが自身の持つ証明書がそのリストに含まれていないかを確認します。つまり、CRLは証明書の失効状況を「一括確認」する方式です。

一方、OCSPでは、ユーザーが特定の証明書のステータスだけをリアルタイムで確認できます。OCSPは「個別確認」なので、更新頻度や通信負荷の観点からCRLと比較して大きな利点があることが特徴です。

ただし、OCSPでは、CAなどのOCSPレスポンダーに「どのクライアントがどの証明書について問い合わせたか」を知られてしまうため、「プライバシー問題」が発生すると指摘されています。個々のユーザーの行動が把握されてしまう問題点には留意が必要です。

逆に、CRLではプライバシー問題は生じません。しかし、CRLは定期的にすべての失効した証明書をダウンロードし、その全リストに対する検索が必要であるため、「処理負荷」や「更新遅延」などの課題があります。

それぞれの特徴を理解した上での適切な方式の選択が、安全なネットワーク通信の実現にとって重要です。

CRLの問題点と今後

このセクションでは、CRL のいくつかの課題点とそれがどのように進化してきたのか、そして将来どう変わるかについて説明します。

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

CRLの主な課題の一つはスケーラビリティとパフォーマンスです。 CRLsは時間とともに大きくなりがちで、非常に大きなものがあります。例えば、それらが数百メガバイトに達したり、それを超えたりすることがあります。主な理由は、大規模な組織が多数の証明書を発行し、それらが頻繁に失効されるためで、これらすべてがCRLに蓄積されます。大きなリストを定期的にダウンロードする必要があるため、ネットワーク帯域やストレージ、処理能力に負担がかかる可能性があります。

CRLからOCSPまで：CRLの進化

これらのスケーラビリティとパフォーマンスの課題に対処するため、証明書の状態を確認する別の方法が生まれました。それがOCSP（Online Certificate Status Protocol）です。 OCSPは特定の証明書の状態だけを問い合わせるため、すべてのCRLをダウンロードして処理するCRLを使う方法と比べて、ネットワーク・ストレージ・処理負荷を大幅に削減できます。CRLは失効情報全体を提供するのに対し、OCSPは「この証明書は現在も有効ですか？」という直接的な質問への回答を提供します。

今後のCRLとセキュリティの動向

デジタル証明書の重要性と共に、CRLとOCSPは今後も重要な役割を果たし続けるでしょう。しかし、CRLやOCSPには依然として課題があります。例えば、OCSPには前述のプライバシー問題に加え、OCSPレスポンダー側の処理遅延などによって要求が無効化されるケースがあります。これらへの対策として、一部のブラウザは「OCSPステイプリング」という方式を採用しています。また新しいプロトコルとしてOCSP Expect StapleとMust-Stapleが提案され実装が進んでいます。

その他に、ブロックチェーンのような新たな技術も今後、証明書の失効管理に役立つ可能性があります。これらの新技術は、CRLやOCSPを補完または置換する可能性を持ち、より効率的で確実な証明書失効管理の方法を提供できることでしょう。