CSR デコーダー / CSR 確認

拒否のほとんどは、次のいずれかに行き着きます。CAが認証できない名前、広すぎるワイルドカード、予約済みのIPアドレス、小さすぎる鍵、古すぎる署名ハッシュ、署名が検証できない要求です。

認証局は内部名に対して発行できません。内部名とは、「does not end with a Top-Level Domain registered in IANA's Root Zone Database」である名前のことです。server.local、intranet、ドットがまったくない単一ラベルの名前、架空のサフィックスはすべてこれに当たります。ラベルに使えるのは英字、数字、ハイフンだけなので、ホスト名のアンダースコアは拒否され、名前の末尾にドットを付けることもできません。ワイルドカードで置き換えられるのは左端のラベル全体だけで、パブリックサフィックスには使えません。*.example.com は有効ですが、*.co.uk は無効です。IPアドレスは含められますが、予約済みのものは不可です。10.0.0.0/8、192.168.0.0/16、127.0.0.1、fc00::/7 は使えません。

鍵については、Baseline Requirements は厳密です。8で割り切れる2048ビット以上のRSAモジュラス、または P-256、P-384、P-521 上の点のいずれかで、「no other algorithms or key sizes are permitted」とされています。CAは、素因数分解できる鍵も拒否しなければならず、「which can be factored within 100 rounds using Fermat's factorization method」のものも含まれます。このページは、要求内の鍵にこの検査を実行します。また、CSR 自身の署名ハッシュは証明書のものとは別ですが、Let's Encrypt は2022年に SHA-1 の自己署名を受け付けなくなったため、いまも SHA-1 で署名する古いツールの要求は拒否されます。

秘密鍵は秘密です。CSR は、その鍵を持っていると証明する要求です。証明書はCAが署名した回答で、3つのうち、もともと公開される前提なのはこれだけです。

3つのファイルは、紛らわしく似た名前で同じフォルダーに入っていることがよくあります。秘密鍵は -----BEGIN PRIVATE KEY----- または -----BEGIN RSA PRIVATE KEY----- で始まり、認証局を含め、誰にも送ってはいけません。証明書署名要求は -----BEGIN CERTIFICATE REQUEST----- で始まり、その鍵で署名されていて、送っても安全です。証明書は -----BEGIN CERTIFICATE----- で始まり、CAが署名していて、サイトの訪問者全員にどのみち送られます。

証明書が発行されたあと、要求はもう使いません。インストール、更新、失効のいずれにも不要です。保管しなければならないのは鍵で、安全に保管してください。上の欄に3つのどれを貼り付けても、このページがどれかを教えます。

ECDSA P-256 の鍵は、RSA 3072ビットと同じ強度で、サイズはずっと小さいため、より良いデフォルトです。RSA 2048 も引き続き、どこでも受け付けられます。

NIST は P-256 と RSA-3072 を同じ128ビットのセキュリティ強度としており、その表には RSA-4096 の行がそもそもありません。次の行は RSA-7680 で、192ビット、つまり P-384 が到達するレベルです。したがって4096ビットのRSA鍵は、3072ビットに対して文書化された利点がないまま、訪問者全員のハンドシェイクに余分な負荷をかけます。Baseline Requirements は P-521 も許可していますが、Let's Encrypt は拒否します。そのため P-521 の要求は、規則上は完全に有効でも、使うつもりだったCAで失敗することがあります。

Ed25519 は、アルゴリズムとしてどれほど優れていても、現在は公的なTLS証明書では使えません。Baseline Requirements が挙げているのはRSAと3種類のNIST曲線で、「no other algorithms or key sizes are permitted」と続きます。ポスト量子鍵も同様です。公的TLSで ML-DSA を許可するはずだった投票案は、2026年10月にマージされないままクローズされました。Ed25519 と ML-DSA は、SSH、署名、プライベートCAでは引き続き有用で、このページはそれらを使った要求も読み取ります。

今日発行される公的なTLS証明書は、200日を超えられません。これは2027年3月に100日、2029年3月に47日へ短縮されます。

このスケジュールは、2025年4月に採択された CA/Browser Forum の投票案 SC-081v3 によるもので、CSR では変えられません。有効期間が要求から決まることはないためです。各段階には2つの数字があり、SHOULD NOT はMUST NOTより1日短くなります。現在は199日と200日、2027年3月15日からは99日と100日、2029年3月15日からは46日と47日です。日数の数え方は「a day is measured as 86,400 seconds」で、次の1日のうち少しでも超えた分は、1日全体として数えます。

実際には、更新を自動化する必要があるということです。毎年 CSR を手作業で作っているなら、いまが ACME に移行する時期です。ACME ではクライアントが要求を作ってくれます。ちなみに、Baseline Requirements 自体が求めているのは「a certificate request in a form prescribed by the CA」だけですが、ACME では PKCS#10 が実際に必須です。