証明書失効リスト(CRL).

CRL は、秘密鍵の漏えい、所有者の変更、誤発行などの理由でもはや信頼すべきでなくなった証明書のシリアル番号と失効日を列挙し、CA が署名した文書です。フォーマットは RFC 5280 で定義されており、thisUpdate/nextUpdate のタイムスタンプと、エントリごとの失効理由コード(例:keyCompromise、cessationOfOperation、affiliationChanged)を持つ署名構造です。依存当事者は証明書の CRLDistributionPoints 拡張に記載された URL から CRL をダウンロードし、シリアル番号がそこに載っている証明書をすべて拒否します。

CRL には鮮度とサイズという 2 つの構造的な弱点があります。クライアントはキャッシュした CRL を nextUpdate まで信頼するため、サイクルの途中で失効した証明書が数時間から数日にわたって受け入れられ続けることがあります。これがほぼリアルタイムの状態確認を目的として OCSP(RFC 6960)と OCSP ステープリングが導入された理由です。サイズは大規模失効イベントで深刻になります。Heartbleed(2014)の後、事業者は証明書を大量に再発行・失効させ、Cloudflare は、その結果生じた CRL の公開によって、ある CA の帯域幅コストが月あたり約 40 万ドル増えたと報告しました。Mozilla は約 3,000 個の CRL、合計 ~300 MB を計測しており、これがブラウザが接続ごとの取得ではなく集約方式へ移行した理由です。

現代の運用では、圧縮されプッシュ配信される失効データが好まれます。Chrome は CRLSets を搭載し、Firefox は CRLite を有効化しました。これは Certificate Transparency ログから得た WebPKI のすべての失効情報を Bloom filter のカスケードとして符号化したもので、12 時間ごとに更新され、ローカルかつプライバシーを保った形で照会されます。Firefox 137 ですべてのデスクトップユーザーに提供されました。CA/Browser Forum が短命証明書へと進める動き(2029 年までに最大有効期間を 47 日へ引き下げる)は、失効そのものへの依存をさらに減らします。すぐに期限切れになる証明書は、ほとんど失効させる必要がないためです。

flowchart TD
  A[秘密鍵の漏えい / 証明書の誤発行] --> B[CA がシリアル番号を CRL に追加]
  B --> C[CA が thisUpdate / nextUpdate を付けて CRL に署名]
  C --> D[CRLDistributionPoints の URL に公開]
  D --> E[TLS クライアント / ブラウザが CRL を取得]
  E --> F{シリアル番号はリストにある?}
  F -->|はい| G[接続を拒否]
  F -->|いいえ| H[受け入れ - nextUpdate まで信頼]
  C -.大きなリスト, 古いキャッシュ.-> I[OCSP stapling / CRLite / 短命証明書]
  style G fill:#c0392b,color:#fff
  style H fill:#27ae60,color:#fff