CRLとは：証明書失効リストの構造と配布点、opensslでの発行とTomcat・nginxでの検証設定【2026年】

CRL（Certificate Revocation List、証明書失効リスト）は、認証局が有効期限より前に無効にした証明書を一覧にし、署名して配るリストです。この記事では、RFC 5280が定めるCRLの項目と失効理由、証明書に書かれたCRL配布点の読み方、CA/Browser Forumが決めたCRLの発行頻度を整理します。そのうえで、opensslで社内認証局のCRLを発行して検証するコマンド、Tomcat・nginx・Javaでクライアント証明書のCRL検証を効かせる設定、2026年9月に公表されたTomcatのCRL無視の脆弱性までを順に扱います。

まとめ：CRLは公開TLSで必須の方式に戻り、社内CAでは検証設定まで自分で確かめる

公開TLS証明書の失効確認は、OCSPからCRLへ主役が戻りました。CA/Browser Forumの規則でCRLの公開は認証局の義務になり、OCSPは任意になっています。Let’s Encryptは2025年3月から証明書にCRLのURLを入れ、同年8月にOCSPを止めました。証明書を検証するソフトウェアを作る側は、CRLを取得して照合できることが前提になります。

社内の認証局でクライアント証明書を発行する場合も、まず検討するのはCRLです。レスポンダーのような常時稼働のサーバーが要らず、ファイルを配れば照合できます。ただし、CRLを設定したつもりでも照合されていない事例は2026年にもTomcatで出ました。失効させたテスト用証明書で接続が拒否されることを、自分の環境で確かめるまでが設定作業です。

CRLとは何か、RFC 5280が定める失効一覧の中身とフィールドを読む

シリアル番号と失効日時を並べ、認証局が署名して配る一覧という仕組み

CRLの形式は、2008年5月公開のRFC 5280の5章で定められています。中身は単純で、認証局が失効させた証明書のシリアル番号と失効日時を並べ、その一覧全体に認証局の鍵で署名したものです。

証明書を受け取った側は、発行元の認証局のCRLを取得し、相手の証明書のシリアル番号が一覧に載っていないかを照合します。載っていれば、有効期限内であっても信用しません。一覧には期限切れになった証明書を残す必要が無いため、失効させた証明書は有効期限を過ぎた時点でCRLから外すのが通常の運用です。照合の前提になる証明書チェーンの署名検証は、TLSの仕組みとハンドシェイクの流れで整理しています。

thisUpdate・nextUpdateとcRLNumberによる鮮度・世代の判定

CRLの主な項目は次のとおりです。

実装で気をつけるのはnextUpdateです。この時刻を過ぎたCRLは古いものとして扱われ、OpenSSLを使う検証では「CRL has expired」というエラーになります。CRLの再発行が止まると、失効していない証明書まで一斉に拒否される、という形で起きる障害です。cRLNumberは、手元のCRLと取得したCRLのどちらが新しいかを判定するのに使います。

reasonCodeの失効理由コードと、CA/B Forumが使ってよいと定めた値

一覧の各行には、失効理由（reasonCode）を付けられます。RFC 5280の5.3.1で値が定義され、公開TLS証明書では、CA/Browser ForumのBaseline Requirements（2026年10月時点の版は2.3.1）の7.2で使える値と場面が絞られています。

unspecifiedはreasonCodeを省略して表す決まりです。certificateHoldは失効を取り消せる「保留」の扱いで、公開TLS証明書では使えません。社内CAでも、失効を取り消す運用は照合側の実装差を生むため避け、必要なら証明書を発行し直すほうが安全です。

CRL配布点（CDP）と分割CRL・差分CRL、証明書からCRLを取り出す手順

証明書のCRL配布点拡張と、URLをopensslで読み取る操作

検証する側がCRLの取得先を知る手がかりは、証明書の「CRL配布点（CRL Distribution Points、CDP）」拡張です（RFC 5280の4.2.1.13）。Baseline Requirementsの7.1.2.11.2では、OCSPのURLを持たず短命証明書でもない加入者証明書にこの拡張を必須とし、URLはhttpに限ると定めています。httpsでないのは、CRLの取得にTLSの検証が必要になる循環を避けるためで、CRL自体は署名で改ざんを防ぎます。

# 公開中のサーバー証明書を取得して保存する
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -outform PEM > server.pem

# CRL配布点のURLを表示する（OpenSSL 3.0以降）
openssl x509 -in server.pem -noout -ext crlDistributionPoints

# URLを取り出してCRLを取得し、発行日時・次回更新・通し番号を確かめる
CRL_URL=$(openssl x509 -in server.pem -noout -ext crlDistributionPoints | grep -o 'http:[^ ]*' | head -n 1)
curl -s -o server.crl "$CRL_URL"
openssl crl -inform DER -in server.crl -noout -lastupdate -nextupdate -crlnumber

配布されるCRLは通常DER形式なので、openssl crlに-inform DERを付けて読みます。-textに変えれば、失効した証明書のシリアル番号と理由を一覧で表示できます。

分割CRLのissuingDistributionPointと差分CRLの位置づけ

失効の件数が多い認証局は、1つの巨大なCRLではなく、複数のCRLに分けて配ります。これが分割CRL（partitioned CRL、シャードCRLとも呼ばれます）です。証明書のCDPには、その証明書が載る1つのCRLのURLだけが書かれます。

分割CRLでは、CRL側に「どの配布点のCRLか」を示すissuingDistributionPoint拡張（RFC 5280の5.2.5）を必ず入れます。Baseline Requirementsは、この拡張の中に証明書のCDPと同じURLをバイト単位で一致させて入れるよう求めています。他の配布点のCRLを取り違えて照合し、失効を見落とす事故を防ぐためです。

前回からの差分だけを配る差分CRL（delta CRL、5.2.4）という仕組みもありますが、公開TLSではほぼ使われていません。照合する側の実装が少なく、社内CAで採用しても検証側が読まない可能性があるため、まず全量CRLか分割CRLで設計します。

Let’s Encryptの2025年CRL URL追加の経緯と社内FWへの影響

Let’s Encryptは、OCSP終了の告知に沿って、2025年3月12日から発行する証明書にCRLのURLを入れ始めました。同社コミュニティでの告知では、サーバー運用者の対応は不要とする一方、TLSクライアントがLet’s EncryptからCRLを取得し始める可能性があり、送信方向のファイアウォールを厳しくしている環境では影響が出うると注意しています。

業務システムのサーバーから外部APIへ接続する構成で、送信先をIPアドレスやドメインで絞っている場合は、接続先の証明書のCDPに書かれたホストへのhttp通信を許可するか確かめてください。CRLの取得がタイムアウトする設定だと、失効確認の失敗として接続ごと止まることがあります。

CRLとOCSPの違いと、Baseline Requirementsが決めた発行頻度と期限

一覧を配るCRLと1枚ずつ問うOCSP、CRLが必須側になった理由

OCSPは、証明書1枚ごとに認証局のレスポンダーへ状態を問い合わせる方式です。CRLの一覧が大きくなる問題を避けるために作られましたが、問い合わせのたびに接続先のサイトが認証局へ伝わるという欠点がありました。2023年7月に可決されたBallot SC063v4で、公開TLS証明書のOCSPは任意に、CRLは必須に変わっています。

CRLなら、検証する側は一覧をまとめて取得して手元で照合するため、どのサイトに接続したかは認証局に伝わりません。オフラインでも照合でき、配布はただのファイル置き場で済みます。OCSPの仕組みとstaplingの設定、soft-failとhard-failの選び方は、兄弟記事のOCSPとは：証明書の失効確認の仕組みとOCSP staplingの設定で扱っています。

加入者証明書のCRLは7日以内に更新し、nextUpdateは10日以内という規則

Baseline Requirementsの4.9.7と7.2は、CRLの出し方を次のように決めています。

• 加入者証明書向けのCRLは、全証明書にOCSPのURLがあれば7日以内、無ければ4日以内の間隔で更新する
• 失効を記録したら、24時間以内に新しいCRLを公開する
• nextUpdateは、加入者証明書向けならthisUpdateから10日以内、それ以外は12か月以内に置く
• CRLはv2形式とし、cRLNumberを必ず入れて発行のたびに増やす

社内CAはこの規則の対象外ですが、更新間隔と有効期限の考え方はそのまま参考にできます。更新を毎日行い、nextUpdateを7日程度先に置けば、配布が1回止まってもすぐには接続障害になりません。

opensslのcaコマンドで社内CAのCRLを発行し、失効させるまでの作業

設定ファイルにCRL配布点と通し番号を入れ、証明書を失効させてCRLを出す

openssl caでは、-revokeで証明書を失効扱いにし、-gencrlで失効の台帳（index.txt）からCRLを作ります。通し番号はcrlnumberファイルがあるときだけ入るため、最初に作っておきます。

# ca.cnf の該当部分（[ CA_default ] に追記）
crlnumber        = $dir/crlnumber
default_crl_days = 7
crl_extensions   = crl_ext

[ crl_ext ]
authorityKeyIdentifier = keyid:always

# 発行するクライアント証明書の拡張にCRL配布点を書く
[ usr_cert ]
crlDistributionPoints = URI:http://pki.example.com/crl/client-ca.crl

# 通し番号のファイルを初期化する（初回のみ）
echo 1000 > demoCA/crlnumber

# 証明書を失効扱いにする（理由に keyCompromise を付ける）
openssl ca -config ca.cnf -revoke certs/user01.pem -crl_reason keyCompromise

# CRLを発行する（nextUpdate は7日後）
openssl ca -config ca.cnf -gencrl -crldays 7 -out crl/client-ca-crl.pem

# 中身を確かめ、配布用にDER形式へ変換する
openssl crl -in crl/client-ca-crl.pem -noout -text
openssl crl -in crl/client-ca-crl.pem -outform DER -out crl/client-ca.crl

失効理由を付けた場合に生成されるCRLはv2形式です。-crl_reasonにはunspecified・keyCompromise・superseded・cessationOfOperationなどを指定できます。-gencrlはcronなどで毎日実行し、配布点のWebサーバーへ置き直す処理と組にしておきます。CRLの再発行を忘れることが、CRL運用で最も起きやすい障害です。

openssl verifyのcrl_checkで、失効した証明書が拒否されるか確かめる

発行したCRLが効いているかは、openssl verifyで確かめられます。-crl_checkは末端の証明書だけ、-crl_check_allは中間CAを含むチェーン全体をCRLと照合します。

# 失効させた証明書：error 23（certificate revoked）が出れば正しい
openssl verify -crl_check -CAfile ca.pem -CRLfile crl/client-ca-crl.pem certs/user01.pem

# 失効させていない証明書：OK が出ることも確かめる
openssl verify -crl_check -CAfile ca.pem -CRLfile crl/client-ca-crl.pem certs/user02.pem

# 証明書のCRL配布点から取得して照合する
openssl verify -crl_check -crl_download -CAfile ca.pem certs/user02.pem

「unable to get certificate CRL」と出た場合は、照合すべき発行者のCRLが渡されていません。中間CAを挟む構成では、中間CAが発行したCRLも必要です。検証結果は失効済み証明書の拒否だけで判断せず、未失効の証明書が正常に通ることも対にして確認してください。

TomcatとnginxとJavaで、クライアント証明書のCRL検証を効かせる設定

TomcatのCRLファイル指定と、CVE-2026-73581での修正

TomcatのSSLHostConfigの設定項目では、certificateRevocationListFileにPEM形式のCRLを連結したファイルを指定します。未設定ならクライアント証明書はCRLと照合されません。OpenSSL実装ではcertificateRevocationListPathでディレクトリも指定でき、JSSE実装ではURLも書けます。

<!-- conf/server.xml：クライアント証明書を必須にし、CRLで失効を確認する -->
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           SSLEnabled="true" maxThreads="150">
  <SSLHostConfig certificateVerification="required"
                 truststoreFile="conf/client-ca.p12"
                 truststorePassword="changeit"
                 certificateRevocationListFile="conf/crl/client-ca-crl.pem">
    <Certificate certificateKeystoreFile="conf/server.p12"
                 certificateKeystorePassword="changeit" type="RSA" />
  </SSLHostConfig>
</Connector>

この設定例のように、サーバー証明書をキーストアで指定する構成には注意が要ります。Tomcat 11.0系のセキュリティ情報によると、2026年は次の2件のCRL関連の脆弱性が公表されました。

CVE-2026-73581は重要度Moderateで、OpenSSLとOpenSSL-FFMの実装が、証明書をキーストアで指定するとCRLを無視するという内容です。影響は11.0.0-M1から11.0.25まで、2026年9月23日に公表されました。CRLを設定していても、失効したクライアント証明書が通っていた可能性があります。11.0.26以降へ上げたうえで、失効させたテスト用証明書で接続が拒否されることを確かめてください。2026年11月時点の11.0系の最新は11.0.27で、9.0系と10.1系の修正版は各系列のセキュリティ情報で確認します。版ごとのサポート期限はTomcatのバージョン一覧とサポート期限にまとめています。

nginxのssl_crlと、中間CAのCRLを同じファイルに束ねる注意点

nginxではngx_http_ssl_moduleのssl_crl（0.8.7以降）でPEM形式のCRLを指定します。中間CAを使う場合は、その中間CAのCRLも同じファイルに入れる決まりです。

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/nginx/tls/server-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/server.key;

    # クライアント証明書を必須にし、社内CAで検証する
    ssl_verify_client      on;
    ssl_verify_depth       2;
    ssl_client_certificate /etc/nginx/tls/client-ca-chain.pem;

    # ルートCAと中間CAのCRLを連結したPEMファイル
    ssl_crl /etc/nginx/tls/client-ca-crl-all.pem;
}

# ルートCAと中間CAのCRLを1つにまとめ、文法確認のあと再読み込みする
cat root-ca-crl.pem intermediate-ca-crl.pem > /etc/nginx/tls/client-ca-crl-all.pem
nginx -t && nginx -s reload

CRLファイルを差し替えたら、nginxを再読み込みして新しいCRLを読ませる手順が必要です。片方のCRLがnextUpdateを過ぎると検証が失敗するので、CRLの再発行と再読み込みは同じジョブで実行し、ファイルのnextUpdateを監視の対象にします。クライアント証明書の発行と配布の設計は、mTLSの仕組みとクライアント証明書の導入判断で扱っています。

Javaアプリが外部へ接続するときのenableCRLDPとPREFER_CRLSの指定

JavaのPKIX実装は、既定では証明書のCRL配布点を読みに行きません。Java PKIプログラマーズ・ガイドには、CRL配布点の対応は互換性のため既定で無効で、com.sun.security.enableCRLDPをtrueにすると有効になると書かれています。OCSPとCRLの両方を使う場合、既定ではOCSPを優先し、OCSPが失敗したときだけCRLへ切り替えます。

# TLS接続で失効確認を有効にし、CRL配布点からCRLを取得させる
java -Dcom.sun.net.ssl.checkRevocation=true \
     -Dcom.sun.security.enableCRLDP=true \
     -jar app.jar

// 証明書パス検証でCRLを優先させる（OCSPは補助に回す）
CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
PKIXRevocationChecker rc = (PKIXRevocationChecker) cpv.getRevocationChecker();
rc.setOptions(EnumSet.of(PKIXRevocationChecker.Option.PREFER_CRLS));
params.addCertPathChecker(rc);

OCSPを止めた認証局の証明書と通信するなら、CRLを優先する指定にしておくと、無駄なOCSPの問い合わせと失敗を避けられます。起動オプションでの失効確認の入れ方は、Oracle CSPUとは：Javaの月次パッチとCPUの違いでも触れています。

CRLを採用する場面と見送る場面、更新が止まったときの扱いの決め方

社内CAのmTLSではCRLを既定とし、nextUpdate切れを監視する条件

社内CAでクライアント証明書を発行するなら、失効確認の方式はCRLを既定にします。レスポンダーを冗長化して監視するOCSPに比べ、配布の仕組みが単純で、障害点が少ないからです。採用の条件は3つあります。

• CRLを毎日再発行し、配布先とサーバーへの反映まで自動で行う
• nextUpdateの残り時間を監視し、数日前に警告を出す
• 失効させたテスト用証明書で、拒否されることを定期的に確かめる

3点目はTomcatのCVE-2026-73581のように、設定が無視される不具合を早く見つけるための手順です。証明書の数が数千件に増えてもCRLの大きさは失効した分だけなので、有効期限を1年程度にしておけば一覧が膨らみすぎることはありません。

即時の無効化が要る場面ではOCSPや短命証明書を併用する判断

CRLの弱点は、失効を反映するまでに再発行の間隔だけ遅れることです。端末の紛失や退職者の証明書を数分以内に無効にしたい要件なら、CRLだけでは足りません。この場合は、レスポンダーを冗長化できるならOCSPを併用し、できないなら証明書の有効期間を数日単位に短くして自動更新する方式を選びます。公開TLSでも短命証明書は失効情報の提供を省ける扱いになっており、失効確認に頼らない方向へ進んでいます。

一方、社外の不特定の利用者が持つ証明書を検証する場面や、CRLの配布点に検証側から届かないネットワーク構成では、CRLを前提にした設計は見送ります。届かないCRLを必須にすると、接続できない利用者が出るだけで失効確認の効果は得られません。

CRL配布とクライアント証明書の認証基盤を外部に相談する目安

社内CAの構築、CRLの発行と配布の自動化、Tomcatやnginxでの検証設定、失効の即時性をどこまで求めるかは、認証基盤の設計として一体で決めるべき事項です。証明書で認証する端末や機器が数百台を超え、退職や紛失への対応を監査で説明する必要が出てきた段階が、設計を外部と詰める目安になります。一創の認証基盤・ID管理システム開発では、証明書による端末認証やSSO・ID連携を含めた認証基盤の設計と開発を支援しています。

よくある質問

CRLについて、実装や運用の場面でよく出る疑問をまとめます。

CRLとOCSPはどちらを使えばよいですか？

公開TLS証明書を検証するなら、CRLを読めることが前提です。Ballot SC063以降、CRLの公開は認証局の義務で、OCSPは任意になりました。社内CAでは、失効の反映が1日程度遅れても困らないならCRL、即時の無効化が必要でレスポンダーを冗長化できるならOCSPを併用します。

CRLのファイル形式と拡張子は何ですか？

配布点に置かれるCRLは、通常DER形式で拡張子は.crlです。TomcatやnginxにはPEM形式で渡すため、openssl crl -inform DER -in ca.crl -out ca-crl.pemで変換します。PEM形式は「BEGIN X509 CRL」で始まるテキストです。

CRLの有効期限が切れるとどうなりますか？

nextUpdateを過ぎたCRLは古いものとして扱われ、OpenSSLを使う検証では「CRL has expired」のエラーになります。nginxやTomcatのOpenSSL実装では、失効していない証明書も含めて接続が拒否されることがあります。再発行の自動化とnextUpdateの監視を必ず組にしてください。

失効させた証明書はいつまでCRLに載りますか？

通常は、その証明書の有効期限が切れるまでです。期限切れの証明書はどのみち信用されないため、一覧から外しても問題ありません。証明書の有効期間を短くしておくと、CRLの大きさも小さく保てます。

ブラウザはCRLを確認していますか？

ブラウザはCRLを接続のたびに取得しているわけではありません。ChromeはCRLSets、FirefoxはCRLiteという形で、認証局のCRLなどから作った失効情報をまとめて配っています。詳しい説明の参照先は、兄弟記事にあるOCSPの解説です。業務アプリやサーバー間通信では、この記事の設定で検証側が自らCRLを照合する必要があります。

関連記事

• OCSPとは：証明書の失効確認の仕組みとOCSP staplingの設定、CRLへ戻る流れと判断【2026年】：CRLと対になる問い合わせ型の失効確認と、soft-fail・hard-failの選び方。
• mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断：CRLで失効させる対象になる、クライアント証明書の運用。
• TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説：失効確認の前段にある、証明書チェーンの検証とハンドシェイクの流れ。
• 電子署名の仕組み：X.509証明書の検証からPAdES長期署名まで：署名検証の場面での失効情報の扱い。
• 電子証明書とは？仕組み・種類・有効期限と取得方法をわかりやすく解説：認証局と失効の考え方を非エンジニア向けに整理。