CRLとは？期限内の電子証明書が使えなくなる理由を、社員証の例から理解する

1. 電子証明書は『デジタルの社員証』

社員証には、氏名、所属、社員番号、有効期限などが書かれています。入口の係員は「発行元が本物か」「期限内か」「本人が持っているか」を確かめます。電子証明書も、これと似た役割を持ちます。

ただし、電子証明書に入っているのは顔写真の代わりに公開鍵です。認証局（CA）が「この名前とこの公開鍵を結び付けます」と電子署名したデータが証明書です。対応する秘密鍵は通常、証明書の中には含めず持ち主が安全に管理します。

もし社員PCが盗まれ、秘密鍵も使われる可能性があれば、期限内の証明書を引き続き信用するのは危険です。そこで「この証明書はもう使わない」という失効（revocation）が必要になります。

2. ITU-T、X.509、RFC 5280は何者？

ITUは国際電気通信連合、ITU-Tはその電気通信標準化部門です。通信で使う仕組みを、国・メーカー・組織が共通のルールで扱えるよう勧告を作っています。

X.509はITU-Tの勧告の一つで、公開鍵証明書や証明書失効リスト（CRL）などのデータ形式・検証に関わる枠組みを定めています。名前が「X」から始まるのは、Xシリーズの勧告だからです。X.509は規格名であり、暗号アルゴリズムの名前ではありません。

RFC 5280は、インターネット向けのX.509公開鍵証明書・CRLのプロファイルです。大づかみに言えば、X.509が枠組み、RFC 5280がインターネットでの具体的な使い方を示します。

3. CRLは『無効にした社員証の番号リスト』

CRLは Certificate Revocation List の略で、日本語では証明書失効リストです。あるCAなどのCRL発行者が、失効した証明書のシリアル番号などを列挙し、電子署名して公開します。

CRLは発行済みの全証明書を記載する名簿ではありません。基本的には失効した証明書を載せるものです。また、秘密鍵の中身を載せるものでもありません。

4. 会社のノートPCをなくしたら、何が起こる？

1. 紛失の連絡：営業社員が「会社のノートPCが見当たらない」と情報システム部門に連絡する。
2. 失効の依頼：管理者が対象の証明書番号を特定し、CAの運用手続に従って失効させる。
3. CRLの更新：CAまたは権限のあるCRL発行者が、失効したシリアル番号を含むCRLを署名・公開する。
4. 失効情報の確認：社内システム側が、適切な発行者による署名付きCRLを取得して検証する。
5. 利用拒否：提示された証明書の番号が掲載されていれば、アクセスを拒否する。

大事なのは、CAに失効登録することと、利用者側が更新された失効情報を参照することは別の処理だという点です。更新やキャッシュの時間差により、失効がすべての利用者に即座に伝わるとは限りません。

5. CRLにはどんな情報が入る？

RFC 5280に沿った典型的なCRLには、発行者、更新時刻、次の更新予定、失効した証明書の一覧などが含まれます。各失効項目にはシリアル番号と失効日時があり、失効理由が付く場合もあります。

次は説明用の擬似表示です。実際のCRLはASN.1に基づく形式で符号化されます。

CRL issuer: Example CA
thisUpdate: 2026-10-21 09:00
nextUpdate: 2026-10-22 09:00
revokedCertificates:
  serialNumber: 00:A1:72
  revocationDate: 2026-10-21 08:30
  reasonCode: keyCompromise
signature: (CA / CRL issuer signature)

6. 『認証局を信頼する』だけでは終わらない

信頼する認証局の公開鍵を持っていても、それだけでは個々のサーバ証明書が今も使えるとは限りません。証明書の確認は、複数のチェックの組み合わせです。

ただし、Webブラウザが毎回CRLファイルを直接ダウンロードするとは限りません。失効情報の取得方法や確認方針は、ブラウザ・OS・用途・設定によって異なります。「CAの公開鍵があるから失効確認は不要」も「必ずCRLに直接アクセスする」も正確ではありません。

7. 失効登録とCRL配布のタイムラグを操作してみる

ここからは模擬的な社内端末の証明書を使います。番号「00:A1:72」の端末を失効させた後、更新前のCRLでチェックするとどうなるでしょうか。実際に操作してみてください。

ポイントは、CRLに名前がない＝絶対安全、ではないこと。発行元と対象範囲が適切な新しいCRLかどうか、確認に使う情報が最新かどうかを見なければなりません。

8. CRLとOCSPはどう違う？

CRLは「失効番号の一覧表を取り寄せる」イメージです。一方、OCSP（Online Certificate Status Protocol）は「この証明書の状態はどうですか」と問い合わせる仕組みです。OCSPでは、応答に good / revoked / unknown などの状態が使われます。

OCSPの good も「発行済みで名前も用途も正しく、すべて安全」という意味ではありません。少なくとも照会された証明書について、失効しているとの情報がない状態を示すものであり、別の証明書検証も必要です。

9. 実運用では『最新性』『可用性』『失敗時の扱い』が重要

CRLは一定間隔で発行されることが多いため、失効登録から公開までに時間差があります。大量の証明書を扱うと配布コストも考えなければなりません。用途によっては差分CRLなども使われます。

また、CRLを取得できなかった場合、接続を拒否するフェイルクローズと、利用を継続させるフェイルオープンにはそれぞれ可用性・安全性のトレードオフがあります。重要システムの認証では、製品の既定値任せにせず失効確認の失敗時ポリシーを決める必要があります。

さらに失効させても、既に確立済みの通信セッションや別に発行された認証トークンまで自動的に破棄されるとは限りません。アカウント停止、端末隔離、鍵の再発行、セッション失効などは別途検討します。

10. 間違えやすい4つのポイント