CRL（Certificate Revocation List）

概要

CRL（Certificate Revocation List） は、認証局（CA）が失効させた証明書のシリアル番号を一覧にして公開するリストです。RFC 5280 Section 5 で X.509 CRL のフォーマットが定義されています。

SSL/TLS 証明書は有効期限前でも失効させる必要が生じる場面があります。秘密鍵の漏洩、ドメインの所有権移転、CA による誤発行などです。CRL は 1990 年代から使われている失効確認の仕組みであり、後に登場した OCSP（RFC 6960、2013 年）よりも歴史が長い手法です。

CRL の課題はサイズです。大規模な CA が運用する CRL は数 MB に達することがあります。クライアントが CRL 全体をダウンロードして検索する必要があるため、帯域とメモリの消費が大きくなります。この問題を解決するために OCSP が開発されましたが、OCSP にもプライバシーとレイテンシの問題がありました。

現在のブラウザーは、CRL も OCSP もリアルタイムに問い合わせるのではなく、独自の圧縮リスト方式を採用しています。Chrome は CRLSets、Firefox は CRLite を使っています。Let’s Encrypt は 2025 年 8 月に OCSP サービスを終了し、失効情報の提供を CRL のみに戻しています。

仕組み

CRL は CA が署名した失効証明書のリストを HTTP 経由で配布し、クライアントがダウンロードして検証する仕組みです。

CRL の構造

CRL は CA の秘密鍵で署名された ASN.1 構造体です。主要なフィールドは次のとおりです。

• Issuer — CRL を発行した CA の識別名
• This Update — この CRL が発行された日時
• Next Update — 次回の CRL が発行される予定日時。この日時を過ぎた CRL は無効
• Revoked Certificates — 失効した証明書のシリアル番号と失効日時のリスト
• Signature — CA の秘密鍵による署名

各エントリーには失効理由（Reason Code）が含まれる場合があります。RFC 5280 では keyCompromise（鍵漏洩）、affiliationChanged（所属変更）、cessationOfOperation（運用停止）などの理由コードが定義されています。

CRL の配布と更新

CA は定期的に CRL を更新し、HTTP 経由でダウンロード可能な URL（CRL Distribution Point）に公開します。証明書の CRL Distribution Points 拡張フィールドにこの URL が記録されています。

X509v3 CRL Distribution Points:
    Full Name:
        URI:http://crl.example-ca.com/example-ca.crl

CRL の更新間隔は CA によって異なります。数時間ごとに更新する CA もあれば、1 日ごとの CA もあります。Next Update の日時までは前回の CRL が有効であるため、失効から実際にクライアントが検知するまでにタイムラグが発生します。

Delta CRL

RFC 5280 では、前回の CRL からの差分だけを配布する Delta CRL も定義されています。完全な CRL（Base CRL）のサイズが大きい場合に、差分のみをダウンロードすることで帯域を節約できます。ただし、Delta CRL を実装している CA は少なく、ブラウザーの対応も限定的です。

ブラウザーの失効確認の実態

現代のブラウザーは CRL をリアルタイムにダウンロードしません。各ブラウザーは独自の方法で失効情報を管理しています。

Chrome は CRLSets を使用します。Google が主要な CA の CRL を定期的に収集・圧縮し、Chrome のアップデートとともに配布します。CRLSets には全失効証明書が含まれるわけではなく、Google がセキュリティ上の影響が大きいと判断した失効のみが収録されます。

Firefox は CRLite を使用します。Certificate Transparency ログの情報と CA の CRL を組み合わせ、ブルームフィルターに圧縮した失効データを配布しています。CRLite は CRLSets よりも網羅性が高く、全 CA の失効情報をカバーします。

Safari は従来 OCSP を使用していましたが、macOS では CRL の確認も行っています。

確認方法

openssl で証明書の CRL Distribution Points を確認するには次のコマンドを使います。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A3 "CRL Distribution"

X509v3 CRL Distribution Points:
    Full Name:
        URI:http://crl.example-ca.com/example-ca.crl

CRL をダウンロードして内容を確認するには次のコマンドを使います。

curl -sO http://crl.example-ca.com/example-ca.crl

openssl crl -in example-ca.crl -inform DER -noout -text | head -30

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Example CA, CN = Example CA Intermediate
        Last Update: Apr 11 00:00:00 2026 GMT
        Next Update: Apr 12 00:00:00 2026 GMT
Revoked Certificates:
    Serial Number: 0123456789ABCDEF
        Revocation Date: Apr 10 12:00:00 2026 GMT

外部の視点からも確認したい場合は、Labee Dev Toolbox の SSL Cert API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/ssl-cert?hostname=example.com"

{
  "success": true,
  "data": {
    "hostname": "example.com",
    "port": 443,
    "reachable": true,
    "status": 200
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

data.reachable が true であれば HTTPS 接続が成立しています。証明書が CRL に登録されて失効している場合、ブラウザーは接続を拒否しますが、サーバーサイドからの接続チェックでは CRL の確認は行われないため、reachable: true でも失効していないことの証明にはなりません。

よくある問題

CRL のサイズ、更新タイムラグ、配布 URL の可用性が運用上の課題になります。

CRL のサイズが大きくダウンロードに時間がかかる

大規模な CA の CRL は数 MB に達します。ネットワーク帯域が限られた環境では CRL のダウンロードに数秒かかり、TLS ハンドシェイクが遅延します。現代のブラウザーは CRL をリアルタイムにダウンロードしないため、ブラウザーユーザーにはこの問題は発生しません。ただし、サーバーサイドで証明書検証を行うアプリケーション（API クライアント、メールサーバーなど）では CRL のダウンロードがボトルネックになることがあります。

CRL の更新タイムラグ

証明書が失効してから CRL に反映されるまでにタイムラグがあります。CA の CRL 更新間隔が 24 時間の場合、最悪で 24 時間の間は失効した証明書が有効として扱われます。秘密鍵の漏洩など緊急性の高い失効では、このタイムラグがセキュリティリスクになります。

CRL Distribution Point の URL がダウン

CRL の配布 URL がダウンしている場合、CRL をダウンロードできません。ブラウザーの多くは CRL のダウンロード失敗を soft-fail として処理し、証明書を有効として扱います。攻撃者が CRL の URL への通信を遮断することで、失効した証明書を有効に見せかける攻撃が理論的に可能です。