CSRデコーダー

CAに送る前にPKCS#10の証明書署名要求をデコード — サブジェクト、要求SAN、鍵長、アルゴリズム、署名検証まで確認できます。

CSRデコーダーはブラウザー内で完結します。要求は端末内でデコードされ、アップロードされることはありません。

X.509証明書デコーダーを開く

CSRデコーダー について

CSRデコーダーは、認証局に提出する前に、証明書署名要求が何を求めているかを正確に見せます。PEMブロックを貼り付ければ、サブジェクトの識別名をフィールドごとに、要求されたサブジェクト代替名（SAN） — ブラウザーはCNを無視するため、証明書がどのホスト名を守るかを実際に決める部分 — を、公開鍵の種類と長さ、署名アルゴリズムとともに読めます。デコーダーはCSR自身の署名も検証します。これは古典的な失敗 — 生成したサーバーと貼り付けフォームの間で切り詰められたり改変されたりした要求 — を捕まえる最速の方法です。CAが弾くもの — 2048ビット未満のRSAとSANの欠如 — には警告が出ます。

機能

CSRデコーダー の使い方

  1. CSRのPEMを貼り付け（またはサンプルを読み込み）
  2. サブジェクトと、特にSANの一覧を確認
  3. 鍵長とアルゴリズムがCAの基準を満たすか確認
  4. 緑の署名バッジは貼り付けが無傷で届いた証拠

例

入力

CSR for example.com

出力

CN=example.com · SANs: example.com, www.example.com · RSA 2048 · SHA256withRSA · signature verifies

SANの一覧こそ、証明書が実際に守る対象です。

よくあるエラーとトラブルシューティング

よくある質問

CSRとは何で、何が入っていますか？
PKCS#10の証明書署名要求です：あなたの公開鍵、主張する身元（サブジェクトとSAN）、そして秘密鍵の所持を証明する自己署名。CAはそれを検証して証明書を発行します — 秘密鍵はサーバーを離れません。
なぜCNよりSANが重要なのですか？
ブラウザーはホスト名をSANの一覧だけで検証し、CNは過去の遺物です。SANのないCSRから作られた証明書はどのドメインでも受け入れられません — 最も多いCSRの失敗であり、ここで最初に確認すべき点です。
署名検証は何を証明しますか？
要求が内部的に一貫していること：埋め込まれた公開鍵がCSR自身の署名を検証するので、バイト列は秘密鍵の持ち主が作ったものと正確に一致します。失敗はほぼ常に貼り付けの切り詰めか改変で、暗号攻撃ではありません。
ブラウザーのツールにCSRを貼っても安全ですか？
CSRは設計上、公開情報しか含みません — そしてこのデコーダーはアップロードなしで端末上で解析します。一緒に生成された秘密鍵は別の話です：それはどこにも行きません、決して。

関連ツール

すべての ArrayKit ツール