CRL デコーダー (X.509)
X.509 の証明書失効リストを DER でも PEM でも解析し、クライアントが見る内容をそのまま表示します。概要にはバージョン、署名アルゴリズム、CRL 番号、thisUpdate と nextUpdate の期間、まだ有効かどうか、そして完全なリストか、基準 CRL 以降の変更だけを載せた差分かが出ます。その下に発行者名、リストを特定の CA 鍵に結び付ける発行者鍵識別子、このリストがどの証明書について語れるかを定める発行配布点が並びます。失効項目ごとにシリアル番号、失効時刻、CA が記録した理由、そしてより重要な無効化時点を示します。revocationDate は CA が処理した時刻、invalidityDate は鍵が漏れたと考えられる時刻で、その差が署名を信頼してはいけない期間です。発行元 CA 証明書を貼り付ければ WebCrypto でリストの署名を検証します。RSA と ECDSA に対応し、そもそもその署名を作れない種類の鍵であれば「確認不能」ではなく不一致として報告します。注意が二つ。シリアルがここにある事実は、これがその証明書に対する正しいリストである場合にのみ意味を持ち、それは発行者と配布点が教えてくれます。そして数十万件に及ぶ大きな CRL も件数は全部数えますが、描画は先頭 500 行までです。残りを描いてもタブが固まるだけで、それ以上のことは分からないからです。
使い方
- .crl ファイルを枠にドロップするか、PEM のリストを貼り付けます。.crl は生の DER なのでテキストエディターでは開けません。
- まず期間を確認します。nextUpdate を過ぎたリストは古く、多くのクライアントはそのまま信頼するのではなく拒否します。
- CRL 番号と範囲を見ます。差分 CRL は示された基準番号以降の変更だけなので、それ単独では全体像になりません。
- 表でシリアル番号を探し、隣の理由を読みます。certificateHold は解除できる一時停止で、それ以外は恒久的です。
- 完全に管理していない経路から来たリストなら、発行元 CA 証明書を貼って署名を検証してください。
よくある質問
- 失効時刻と無効化時点はどう違いますか。
- 失効時刻は CA がその事実を公表した時点で、任意項目の無効化時点は証明書が実際に信頼できなくなったと考えられる時点、多くは鍵が漏れた時刻です。漏洩は数日後に判明することも多いため、両者は大きく離れることがあります。古い署名を判断するときに効いてきます。無効化時点より前に作られた署名はなお受け入れられる一方、後のものは受け入れられません。どちらも失効そのものより前でありえます。
- certificateHold と出ました。この証明書は失効しているのですか。
- 失効ではなく一時停止です。certificateHold は唯一取り消せる理由コードで、後続の CRL が同じシリアルを removeFromCRL の理由で載せると停止が解け、証明書は再び使えるようになります。そのためクライアントは keyCompromise のように恒久的なものとしてキャッシュできません。公開 CA はほとんど使わないので、目にしたら私設や社内の PKI であることが多いです。
- 差分 CRL とは何で、それだけで使えますか。
- 使えません。差分は Delta CRL Indicator 拡張に示された特定の基準 CRL 以降の変更だけを載せ、その基準の上に重ねて使うためのものです。大きな CA の完全なリストは巨大になりうるので、数件しか変わらないのに毎時間全体を取り直すのは無駄だから存在します。この道具が差分と表示したら、見えている項目は直近の変更であって失効シリアルの全体ではありません。
- シリアルが載っていなければその証明書は正常ですか。
- これが正しいリストで、期限内で、その証明書がこの CA の発行である場合に限ります。CRL は定められた範囲についてのみ語ります。発行者名と、あれば発行配布点がその範囲を限定します。無関係な CA のリストに載っていないことは何も意味しません。新しさも必要です。期限切れのリストは探している失効より前のものかもしれず、クライアントが古いリストを読まずに拒否するのはまさにそのためです。
- 署名はどのように確認し、失敗は何を意味しますか。
- リストの署名対象部分を、貼り付けた証明書の公開鍵で、リストが示すアルゴリズム(RSA PKCS#1 v1.5 または ECDSA)に従いブラウザーの WebCrypto で検証します。成功すればその CA 鍵が確かにこのバイト列に署名しており、改変がないという意味です。失敗はリストが改変されたか、貼った証明書が発行元でないかのどちらかです。鍵の種類からしてその署名を作れない場合は、対応していないアルゴリズムではなく不一致として報告します。
- ファイルはどこかにアップロードされますか。
- されません。リストも貼り付けた証明書もページ内で読み取って解析し、署名検証もブラウザー自身の WebCrypto で動きます。サーバーに送りませんし、送る先の仕組みもありません。失効リストは公開情報ですが、私設 PKI のものはそうとは限らず、すべてクライアント側で動かしている理由がそこにあります。
関連ツール
SSL 証明書デコーダ(X.509 / PEM)
PEM 証明書を貼り付けると、サブジェクト、発行者、有効期限、SAN、鍵、フィンガープリント、拡張をブラウザ内で読み取ります。
CSR デコーダー (PKCS#10)
証明書署名要求を送る前に確認します。サブジェクト、SAN、鍵長、署名アルゴリズム、そして自己署名が検証できるかまで。
OCSP レスポンス・リクエストデコーダー
OCSP のレスポンスとリクエストをブラウザーで解析します。ステータス、レスポンダー、鮮度、ノンス、失効理由、同梱証明書まで表示します。
PKCS#12 キーストア インスペクター
.p12 / .pfx をブラウザーで開きます。パスワード前に MAC と暗号方式、入力後は証明書チェーン・秘密鍵・鍵の一致を確認できます。
ポート番号リファレンス
約 60 個の標準 TCP / UDP ポート番号の検索可能なチートシート — 22 (SSH)、80 (HTTP) から 6379 (Redis)、27017 (MongoDB) まで。
NumPy .npy / .npz インスペクター
.npy・.npz のヘッダーをブラウザで読み取ります。dtype、shape、バイト順、フィールド配置、先頭の値まで。NumPy もアップロードも不要です。