ZeroTool Workbench

CSR デコーダー

PKCS#10 証明書署名要求をブラウザで解析。Subject・公開鍵・要求された SAN と拡張を表示し、自己署名を検証して CA 提出前に不備を発見。アップロード不要。

100% クライアントサイド データはブラウザ外に出ません 無料 · 登録不要

関連ツール

SSL 証明書デコーダー X.509 PEM 証明書をオンラインで解析。Subject・Issuer・有効期間・SAN・公開鍵・署名アルゴリズム・SHA-256/SHA-1/MD5 フィンガープリントを表示。完全ブラウザ完結。 RSA 鍵ペアジェネレーター RSA鍵ペア（2048/4096ビット）をPEM/JWK形式でブラウザ内生成。鍵はブラウザ外に出ません。 ハッシュジェネレーター テキストからMD5・SHA-1・SHA-256・SHA-384・SHA-512ハッシュを生成。 Basic Auth Header ジェネレーター HTTP Basic Authentication ヘッダーをブラウザで生成・デコード。Authorization header、token、cURL、Fetch 例をアップロードなしでコピー。 パスワードジェネレーター 暗号学的に安全なパスワードを生成。長さと文字セットをカスタマイズ可能。エントロピー計測付き。 AES 暗号化 / 復号 ユーザー指定パスワードでAES-GCM暗号化・復号。Web Crypto API使用で100%クライアントサイド処理。

CSR を点検する手順

  1. BEGIN 行と END 行を含めて PEM 要求を貼り付けます。
  2. デコードを押すか、テキストエリアで Ctrl / Cmd + Enter を押します。
  3. まず提出前チェックを読みます。却下につながりやすい順に並んでいます。
  4. Subject と要求された SAN の一覧が、取得しようとしている証明書の内容と一致するか確認します。一覧にある名前はすべて発行証明書に入り、書き忘れた名前は入りません。

提出前チェックの判断基準

チェック項目CA が重視する理由
自己署名所持証明。署名が検証できない要求は、転送中に破損したか、噛み合わない部品から組み立てられています。
鍵強度CA/Browser Forum ベースライン要件の下限は RSA 2048 ビットまたは 256 ビット楕円曲線です。これを下回れば即座に拒否されます。
署名ハッシュSHA-1 は 2016 年に公的発行から撤廃されました。SHA-1 や MD5 で署名した要求は提出した時点で無効です。
subjectAltNameSAN のない証明書は何も保護しません。ブラウザはホスト名照合で Common Name を読まなくなったためです。
CN の SAN 収載CN を SAN にも書いていなければ、まさにその指定したホスト名を守らない証明書ができあがります。
ワイルドカードの位置ワイルドカードは最左ラベル全体としてのみ有効です。*.example.com は可、api.*.example.com と w*.example.com は不可。
公開解決可能な名前.local や .internal などの内部サフィックス、ドットのない単一ラベル名、プライベート IP は公的に信頼される証明書に記載できません。

CSR の中身

PKCS#10 要求の実体は、DER で包まれた 3 つの要素です。要求される情報、それを署名したアルゴリズム、そして署名そのもの。情報ブロックには Subject 識別名、公開鍵、任意の属性集合が入ります。興味深い内容はほぼすべて属性集合の中にあり、extensionRequest 属性が SAN 一覧・key usage・extended key usage を運びます。

CSR に入っていないのは秘密鍵です。要求内のどの情報もなりすましには使えないため、通常の経路で CA に送っても安全です。唯一の例外が challengePassword で、これは一部の CA が後日の失効手続きに使う共有秘密です。本デコーダーはこの属性の有無だけを報告し、値は意図的に一切表示しません。

署名検証の仕組み

デコーダーは DER から CertificationRequestInfo のバイト範囲を正確に切り出し、埋め込まれた SubjectPublicKeyInfo を crypto.subtle.importKey で読み込み、要求に記された アルゴリズムで crypto.subtle.verify を呼びます。RSA PKCS#1 v1.5、RSA-PSS、および P-256 / P-384 / P-521 上の ECDSA がこの経路で検証されます。ECDSA 署名は DER の SEQUENCE{r,s} 形式から、Web Crypto が要求する固定長形式へ変換されます。

Ed25519 と Ed448 も同様に試行し、成否はブラウザが Web Crypto にこれらを公開しているかに依存します。ブラウザが読み込みを拒否した場合、チェックは「署名が不正」ではなく「検証できなかった」と報告します。アルゴリズム未対応と署名破損は別の問題であり、心配すべきは後者だけだからです。その場合はローカルで openssl req -in req.pem -verify -noout を実行してください。

SPKI ピンの使いどころ

要求のフィンガープリントに加えて、SubjectPublicKeyInfo から計算した sha256/… ピン（公開鍵ピンニング設定で使う RFC 7469 形式）も表示します。この値は鍵のみに依存するため、同じ鍵ペアで発行されたすべての証明書で同一です。openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64 の出力と突き合わせれば、受け取った証明書がこの要求から発行されたものかを確認できます。

対応範囲

本ツールが読むのは PEM 形式の PKCS#10 要求だけです。要求の生成は行わず、秘密鍵は読み取りも受け付けもせず、ネットワーク通信も一切しません。実行するチェックは、目の前のバイト列だけで判断できるものに限られます。証明書チェーンの検証、CT ログの確認、発行ポリシーの適用は CA の職掌であり、ローカルでの等価コマンドは openssl req -in req.pem -noout -text です。

FAQ

CSR はどこかにアップロードされますか？

されません。ASN.1 解析・ハッシュ計算・署名検証はすべてページ内のインライン JavaScript と Web Crypto API で完結し、要求の内容が端末から出ることはありません。Web 上の CSR デコーダーの多くは証明書販売業者の集客ページで、貼り付けた内容が相手のサーバーに届く点は意識しておく価値があります。

自己署名の検証は何を証明しますか？

PKCS#10 要求は、その中の公開鍵と対になる秘密鍵で署名されています。この署名を検証できれば、鍵ペアが確かに対であること、そして生成後に 1 バイトも改変されていないことが確かめられます。CA が受領時に行う所持証明と同じ処理なので、ここで失敗する要求は CA でも失敗します。原因の多くは PEM の切れ、メールクライアントによる改行の入れ直し、手作業での編集です。

問題なさそうな CSR が CA に却下されるのはなぜですか？

よくある 4 つの原因はすべてここで検査します。RSA 鍵が 2048 ビット未満、SHA-1 署名、subjectAltName が皆無、Common Name が SAN に重複記載されていない、の 4 点です。ブラウザは長年 SAN のみでホスト名を照合しているため、ホスト名を CN にしか書いていない CSR は、どのブラウザも受け入れない証明書を生みます。

対応する入力形式は？

PEM のみです。-----BEGIN CERTIFICATE REQUEST----- と、Windows certreq が出力する -----BEGIN NEW CERTIFICATE REQUEST----- の両形式に対応します。DER バイナリは直接読み込みません。openssl req -inform DER -in req.der -out req.pem で変換してください。

このツールで CSR を作成できますか？

できませんし、できるべきでもありません。CSR の作成は秘密鍵の生成を伴い、Web ページが生成した秘密鍵はそのページが控えを取り得る鍵です。openssl req -new -newkey rsa:2048 -nodes -keyout key.pem -out req.pem をローカルで実行し、生成された要求をここに貼り付けて点検してください。