CSRと秘密鍵と証明書、どれを渡してどれを保管する？
証明書を申し込むときにCSRを作り、あとから証明書が届く。手元に似た見た目のファイルが増えると、どれがどの鍵と組になっているのか迷いやすくなります。共通して入っている公開鍵を軸にすると、それぞれの役割と照合方法がつながります。
3つのファイルは、別の役割を持つ
鍵ペアを作ると、秘密に保つ秘密鍵と、相手へ渡せる公開鍵ができます。CSRは公開鍵などを含む証明書の申請情報です。CAは申請者やドメインの確認などを行い、認めた内容を証明書にします。CSRを作っただけでは証明書の発行も、ドメインを管理していることの確認も終わりません。
何が入っているか
CSRの構造と発行の流れはRFC 2986 §3–4に定義されています。CSRにも組織名や内部名などが含まれ得るため、秘密鍵がないことと無条件に公開してよいことは別です。
| 種類 | 主な内容 | 扱い |
|---|---|---|
| 秘密鍵 | 署名などを行うための秘密の鍵材料 | 管理下の環境で保管。通常の証明書申請ではCAに送らない |
| CSR（PKCS #10） | 公開鍵、Subject、属性、申請者の鍵による署名 | 発行申請先へ送る。秘密鍵自体は含まない |
| 証明書 | 公開鍵、名前、有効期間、発行者など | 接続相手に提示する。秘密鍵自体は含まない |
CSRの署名が正しくても、申請内容の承認ではない
CSRは申請情報を対応する秘密鍵で署名します。署名が検証できれば、申請内の公開鍵と整合する鍵でその情報が署名されたことを確かめられます。ただし、書かれた会社名が本当か、www.example.comを管理しているかは別の確認が必要です。
名前の入力と、発行結果を比べる
これはCSRの読取り項目を示した例です。SANの2つの名前は申請内容で、CAがそのまま発行する保証ではありません。発行後は証明書のSANを別に読みます。現在のTLS名照合ではCNだけに頼れないため、申請画面にCNを入れたことで必要なSANが自動的にそろうとは考えない方が確実です。
Subject: CN=www.example.com
Requested SAN: DNS:www.example.com, DNS:example.com
Public key: RSA, 2048 bits手元でCSRの内容と署名を読む
OpenSSLがある管理下の環境なら、次のコマンドでCSRの内容を表示し、申請内の署名も検証できます。request.csrは調べたいCSRのファイル名です。秘密鍵を入力する必要はありません。
CSRを入力する例
Subject、Public Key、Requested Extensions内のSANなどを読みます。署名の検証成功はCSRの内部整合性についての結果です。CAの発行審査、有効なTLS証明書、ドメインの所有を認定するメッセージではありません。オプションはOpenSSL reqの公式説明に対応します。
openssl req -in request.csr -noout -verify -text公開鍵だけを取り出して、組み合わせを照合する
ファイル名に同じドメインが入っていても、更新前後の鍵を取り違えることがあります。同じOpenSSLで各ファイルから公開鍵をPEM形式へ取り出し、3つの出力を比べると対応を調べられます。以下の出力先は、既存ファイルと重ならない名前で用意します。
秘密鍵そのものを表示しない抽出例
3つのPUBLIC KEYブロックが一致すれば、その表現で同じ公開鍵を持つ組み合わせです。暗号化された秘密鍵のパスワードは対話入力し、コマンドへ直接書きません。各コマンドが成功して空でない出力を得たことも合わせて見ます。公開鍵の一致だけでは証明書の期限、信頼チェーン、秘密鍵の漏えいがないことまでは分かりません。
openssl pkey -in private-key.pem -pubout -out key-public.pem
openssl req -in request.csr -pubkey -noout -out csr-public.pem
openssl x509 -in certificate.pem -pubkey -noout -out cert-public.pemオンラインではテスト用の鍵で流れを試す
Online ToolsのCSRツールは、鍵とCSRをサーバーで生成します。CSRの解析入力もサーバーへ送信します。例えばテストとしてCNにwww.example.com、SANにwww.example.com,example.comを入れ、結果に両方の名前があるか読む使い方ができます。本番用の秘密鍵は、管理下の信頼できる環境で生成・保管します。
鍵マッチャーの一致が示す範囲
鍵・証明書マッチャーは証明書、秘密鍵、パスワードをサーバーへ送るため、テスト用の組み合わせに使います。RSA・ECについて、秘密鍵から得た公開鍵と証明書の公開鍵を比較します。鍵が一致しても証明書の有効性まで保証するものではありません。チェーンの表示はIssuerとSubjectの並びの比較で、署名や信頼の検証ではありません。
仕様と、発行後に読む項目
RFC 2986 §4：CSR構造、RFC 5958 §2：秘密鍵情報の構造、OpenSSL pkey、OpenSSL x509。発行後の接続エラーを調べるならTLS証明書チェーン・SAN・信頼、ファイル形式の違いはPEM・DER・P7B・PFXの準備へ。