CSRとは

詳細な図解

CSRを読むときの前提

CSR（Certificate Signing Request）は、証明書発行を依頼するために作る要求データです。秘密鍵に対応する公開鍵、CN、SAN、組織情報などを含みますが、秘密鍵そのものは含みません。

実務では、CSRを作る前に接続名、SAN、鍵長、アルゴリズム、秘密鍵の保存先、申請先CA、証明書用途、所有者を確認します。

証跡には、CSR作成者、作成日時、鍵長、アルゴリズム、CN、SAN、秘密鍵保管先、申請チケット、CA、発行後の証明書フィンガープリントを残します。

秘密鍵との対応を確認する

CSRは秘密鍵から作ります。発行後の証明書は、その秘密鍵と対応していなければTLS終端点で使えません。CSRだけを渡しても、秘密鍵をどこで保管したか分からないと配備時に詰まります。

秘密鍵を再生成した場合は、古いCSRで発行された証明書と一致しなくなります。鍵の取り違えを防ぐため、CSR、秘密鍵、発行証明書を同じ管理単位で扱います。

• CSRと秘密鍵の対応を確認する。
• 秘密鍵の保存先と権限を記録する。
• 発行後に証明書と秘密鍵の一致を確認する。

SANを実利用名で確認する

近年のTLS検証では、CNよりSANが重視されます。CSR作成時に、利用者が接続するFQDN、API名、管理画面名、ワイルドカードの範囲を洗い出します。

CNAME先の名前、内部名、短縮名、ロードバランサー名をそのまま入れるべきかは設計次第です。実際にブラウザやクライアントが接続する名前で確認します。

• 利用者が入力するFQDNを列挙する。
• ワイルドカードで覆える範囲を確認する。
• 不要なSANを入れない。

CA申請と承認を残す

CSRをCAへ提出するときは、証明書用途、所有者、申請理由、期限、発行先環境を添えます。社内CAでも公開CAでも、誰が承認したかを残すと監査に耐えやすくなります。

CAAが設定されているドメインでは、許可されていないCAからの発行が失敗します。CA切替時はDNS側の制御も事前に確認します。

• 申請先CAと承認者を記録する。
• 証明書用途と所有者を明記する。
• CAAによる発行制限を確認する。

変更証跡と引き継ぎ

CSR対応では、CSR内容、秘密鍵保管先、発行証明書、配備先、更新予定、失効時の連絡先を残します。CSRファイルだけ残っても、秘密鍵や用途が追えなければ再利用できません。

引き継ぎでは、Web基盤担当、PKI管理者、DNS管理者、関連語としてSAN、秘密鍵、CA、CAAを残すと確認しやすくなります。

• CSR内容と証明書内容を比較する。
• 秘密鍵の保管先だけを共有し、鍵そのものは貼らない。
• 次回更新時に使う手順をRunbookへ残す。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能