CSR デコーダー (PKCS#10)

使い方

1. CSR を貼り付けるか、.csr または .pem ファイルを枠にドロップします。-----BEGIN CERTIFICATE REQUEST----- で始まります。
2. まず SAN の一覧を確認します。証明書が覆うべきホスト名はすべてそこに載っている必要があり、コモンネームに書いたものも含みます。
3. 自己署名が検証できることを確かめます。できないなら送らずに要求を作り直してください。
4. 鍵長と署名アルゴリズムを読みます。公的 CA は最低でも 2048 ビットの RSA（または任意の EC 曲線）と SHA-256 以上の署名を求めます。
5. オレンジ色の項目は提出前に解消してください。CA に拒否されると、たいてい数時間の往復になります。

よくある質問

コモンネームがあるのに、なぜ SAN が要るのですか。

クライアントがコモンネームを見なくなったからです。RFC 2818 は 2000 年にホスト名照合での利用を非推奨とし、Chrome は 2017 年のバージョン 58 で対応を打ち切り、他のブラウザーも続きました。いまでは CA/Browser Forum の基本要件が、CA にすべての名前を subjectAltName 拡張へ入れるよう義務づけています。ホスト名がコモンネームにしかない CSR は、CA に拒否されるか、現代のブラウザーがすべて ERR_CERT_COMMON_NAME_INVALID で拒む証明書を生みます。それでもツール類はコモンネームを表示し続けるので、この誤りは見落としやすいのです。

CSR の自己署名は何を証明するのですか。

要求を作った側が、その中の公開鍵に対応する秘密鍵を持っていることです。要求はその鍵で自分の中身に対して署名されているので、CA は要求だけで検証できます。誰かがあなたの公開鍵を入れた CSR を提出してあなたの名前の証明書を得る、ということを防ぐ仕組みがこれです。ドメインの所有権は証明せず、それは CA が別途確認します。署名が検証できないなら、署名後にファイルが改変されたということで、たいていは転送中に壊れたか手で編集されたかです。

ここに CSR を貼り付けても安全ですか。

安全です。CSR に入っているのは公開情報だけ——要求する名前と鍵ペアの公開側だけ——で、そもそも CA に渡すためのものです。それでもこのページはどこにも送りません。ASN.1 の解析も署名の検証も WebCrypto でブラウザー内で動き、ページを開いてからネットワークを切って要求を貼り付ければ確かめられます。秘密鍵はまったく別の話です。どこにも貼り付けないでください。ここに入れた場合、ツールは拒否します。

署名が検証されないことがあるのはなぜですか。

検証にはブラウザーが公開鍵を読み込める必要があり、WebCrypto が対応するアルゴリズムは決まっているからです。RSA と NIST 曲線上の ECDSA はどこでも動き、Ed25519 は新しいブラウザーでのみ動いて古いものでは飛ばされます。鍵の種類を読み込めないとき、このツールは通ったかのように見せず、検証していないと述べます。検証していない署名と有効な署名はまるで別物であり、その二つを混同することこそ、このツールがやり得る本当に危険なことだからです。

証明書もここで復号できますか。

できません。証明書と証明書署名要求は別の構造で、このツールは PKCS#10 の要求だけを読みます。CSR は CA に送るもの、証明書は返ってくるもので、証明書には発行者・有効期間・CA の署名がありますが、要求にはそのいずれもありません。-----BEGIN CERTIFICATE----- のブロックは証明書デコーダーに入れてください。

チャレンジパスワードは何のためのものですか。

元の PKCS#10 仕様にある任意の属性で、後から CA に証明書の失効を頼むための共有秘密として意図されたものです。いまや公的 CA はほとんど使いません。失効は認証したアカウント経由で処理されるからです。ただし一部の企業環境や SCEP による登録では依然として求められ、マイクロソフトの証明書サービスはこの値を読みます。設定されていればこのツールが表示します。要求の中を平文で流れるものなので、知っておく価値があります。

関連ツール