CSR（証明書署名要求）デコーダー
PEM形式のCSR（証明書署名要求）を貼り付けるだけで、申請予定のCN・SAN・組織名・公開鍵アルゴリズムをCA提出前に確認。入力ミスの事前発見に役立つ無料ツール。
CSRデコーダーとは
CSRデコーダーは、PEM形式のCSR（Certificate Signing Request、証明書署名要求）を貼り付けるだけで、申請予定のSubject（CN・組織名等）・SAN（Subject Alternative Name）・公開鍵アルゴリズム・署名アルゴリズムを一覧表示する無料ツールです。CA（認証局）へ提出する前に、入力した内容が意図通りかをその場で確認できます。
隣接ツールの「X.509証明書デコーダー」が発行済みの証明書を解析するのに対し、本ツールはCA審査・発行より前の段階にあるCSRそのものが対象です。証明書がまだ発行されていない、あるいは秘密鍵を再生成する前の最終確認用途で使えます。
CSRデコーダーの使い方
- PEM形式のCSRを貼り付ける 「-----BEGIN CERTIFICATE REQUEST-----」から始まるテキストを入力欄にそのまま貼り付けます。
- 複数CSRもそのまま貼り付け可能 複数のCSRをまとめて貼り付けると、ブロックごとに自動検出されます。
- 「解析する」ボタンを押す 検出されたCSRの件数を確認したら、ボタンを押してサーバー側で解析します。
- 結果を確認する Subject・SAN・公開鍵アルゴリズム等が一覧表示されます。
使いこなすためのヒント
- CN（コモンネーム）とSANの両方に、実際に発行してほしいすべてのホスト名が含まれているかを提出前に必ず確認してください。SANの記載漏れは再発行の手間につながります。
- 公開鍵アルゴリズムがRSA 2048bit未満、またはECの非推奨曲線になっていないかをこのタイミングで確認しておくと、CAの審査で差し戻される事態を避けやすくなります。
- 複数のサーバーに同じCSRを使い回す前に、SubjectとSANの組織名・ドメインが実際の申請対象と一致しているかを再確認しましょう。
- 本ツールで確認できるのはCSRに書かれた申請内容のみです。CAが実際にどのSANを発行するかは審査結果次第で変わる場合があります。
こんな場面で使えます
CA提出前の最終確認
有料のSSL証明書を購入する前に、CSR生成時に入力したCN・SANが正しいかを確認できます。
社内システムでのCSR生成手順の検証
openssl req 等で生成したCSRの内容が想定通りかを、コマンドライン操作に慣れていない担当者でも視覚的に確認できます。
過去に発行依頼したCSRの内容確認
ファイルとして保管しているCSRの中身を、秘密鍵を扱わずに安全に再確認できます。
マルチドメイン証明書のSAN漏れチェック
複数ホスト名を1枚の証明書でまとめて申請する際、SANに漏れがないかを申請前に洗い出せます。
用語集
- CSR（証明書署名要求）
- Certificate Signing Requestの略。CAに証明書の発行を依頼する際に提出する、公開鍵と申請情報（Subject・SAN等）をまとめたデータです。
- CA（認証局）
- Certificate Authorityの略。CSRの内容を審査し、実際のSSL/TLS証明書を発行する第三者機関です。
- CN（コモンネーム）
- 証明書の主対象となるホスト名やサービス名を表すSubjectの一項目。かつてはブラウザがCNのみを見て検証していましたが、現在はSANが優先されます。
- SAN（Subject Alternative Name）
- 証明書が有効なホスト名やIPアドレスを追加で列挙する拡張フィールド。CSRの段階では「Requested Extensions（要求された拡張）」として記録されます。
- Requested Extensions
- CSRの申請者が「発行時にこの拡張を含めてほしい」と要求する属性。SANはこの中に含まれますが、CAが必ずしもそのまま反映するとは限りません。
- 公開鍵アルゴリズム
- CSRに含まれる公開鍵の生成方式。RSA・EC（楕円曲線暗号）等があり、鍵長・曲線によって強度が変わります。
よくある質問
余談ですが ― CSRはなぜ「署名」を含むのか
CSRの中身をよく見ると、Subject・公開鍵情報に続いて署名アルゴリズムと署名値が格納されています。これは一見奇妙に思えるかもしれません。CAに「私を証明してください」と依頼する書類が、なぜ自分自身の署名を含んでいるのでしょうか。答えは「Proof of Possession（秘密鍵の保有証明）」という考え方にあります。CSR全体（Subject・公開鍵等）を、CSRに記載した公開鍵と対になる秘密鍵で署名することで、「この公開鍵に対応する秘密鍵を確かに持っている申請者本人である」ことをCAに示しているのです。他人の公開鍵を勝手に含めたCSRを作っても、対応する秘密鍵を持っていなければ正しい署名を作れないため、なりすまし申請を防げます。
CSRという仕組みは、RSAが開発した公開鍵暗号標準群PKCS（Public-Key Cryptography Standards）のうちPKCS#10として1986年に規定されました。現在はIETFがRFC 2986として再定義していますが、実務上は今もPKCS#10という呼び方が広く使われています。TLS証明書の世界では地味な存在ですが、証明書発行フロー全体の起点となる、なくてはならない仕組みです。
CSRのRequested Extensions（要求された拡張）にSANを含める仕組みが標準化されたのは、実はそれほど古い話ではありません。もともとCSRの標準（PKCS#10）にはSubjectとCN程度しか想定されておらず、マルチドメイン証明書やワイルドカード証明書が普及するにつれて、CAごとに独自の方法でSANを受け付けるようになりました。現在ではopenssl等の主要ツールがRFC 2985のExtension Requestという仕組みでSANをCSRに含める方法を標準サポートしており、本ツールもこの標準的な位置（Attributes内のextensionRequest属性）からSANを読み取っています。