CSR（証明書署名要求） - 暗号化全般

暗号化全般 | IT用語集

CSR（証明書署名要求）とは

CSR（Certificate Signing Request / 証明書署名要求）は、SSL/TLS証明書を認証局（CA）から取得するために提出するファイルです。CSRには公開鍵と組織情報が含まれており、CAはこれを検証した上で証明書を発行します。

CSRに含まれる情報：

  • 公開鍵：サーバーの公開鍵
  • Common Name (CN)：証明書を使用するドメイン名
  • Organization (O)：組織名
  • Organizational Unit (OU)：部門名
  • Locality (L)：市区町村
  • State (ST)：都道府県
  • Country (C)：国コード（JPなど）

CSRの生成方法

基本的なCSR生成

# 秘密鍵とCSRを同時に生成
openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr

# 対話形式での入力
# Country Name (2 letter code) [AU]: JP
# State or Province Name (full name) [Some-State]: Tokyo
# Locality Name (eg, city) []: Shibuya
# Organization Name (eg, company) []: Example Inc.
# Organizational Unit Name (eg, section) []: IT Department
# Common Name (e.g. server FQDN) []: www.example.com
# Email Address []: admin@example.com

非対話形式でのCSR生成

# -subj オプションで一括指定
openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/C=JP/ST=Tokyo/L=Shibuya/O=Example Inc./CN=www.example.com"

SAN（Subject Alternative Name）付きCSR

# 設定ファイル（san.cnf）
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[dn]
C = JP
ST = Tokyo
L = Shibuya
O = Example Inc.
CN = www.example.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = www.example.com
DNS.2 = example.com
DNS.3 = api.example.com

# CSR生成
openssl req -new -key server.key -out server.csr -config san.cnf

AIエンジニアとしての実体験

AIサービスのAPI基盤を構築する際、ワイルドカード証明書のCSRを生成しました。サブドメインが動的に増えるマルチテナントアーキテクチャでは、ワイルドカード証明書が効率的です。

# ワイルドカード証明書用CSR
openssl req -new -newkey rsa:2048 -nodes \
  -keyout wildcard.key -out wildcard.csr \
  -subj "/C=JP/ST=Tokyo/O=AI Company/CN=*.example.com"

CSRの内容確認

# CSRの内容を人間が読める形式で表示
openssl req -in server.csr -noout -text

# CSRの内容確認（要約）
openssl req -in server.csr -noout -subject

# CSRに含まれる公開鍵の確認
openssl req -in server.csr -noout -pubkey

自社サーバー運用への応用

秘密鍵の安全な管理

CSR生成時に作成される秘密鍵は、サーバーに残しておき、絶対に外部に漏らさないようにします。認証局に送るのはCSRのみです。

# 秘密鍵のパーミッション設定
chmod 600 server.key
chown root:root server.key

鍵とCSRの一致確認

# 秘密鍵のmodulus
openssl rsa -noout -modulus -in server.key | openssl md5

# CSRのmodulus
openssl req -noout -modulus -in server.csr | openssl md5

# 発行された証明書のmodulus
openssl x509 -noout -modulus -in server.crt | openssl md5

# 3つのMD5ハッシュが一致すれば、鍵と証明書が対応している

CSRのメリット・デメリット

メリット

  • 秘密鍵をCA（認証局）に一切送信せずに証明書を申請できる（公開鍵のみを含むため秘密鍵の漏洩リスクがない）
  • PKCS #10という標準フォーマット（RFC 2986）に準拠しており、どのCAでも共通の手順で申請できる
  • ドメイン名・組織情報を1つのファイルにまとめられるため、申請内容の管理・監査がしやすい
  • SAN（Subject Alternative Name）を含めることで、1枚の証明書で複数ドメインをまとめて申請できる

デメリット

  • CSR生成時にCNやSANを誤入力すると、証明書発行後に再発行が必要になり手戻りが発生する
  • CSRとペアになる秘密鍵を紛失・破棄してしまうと、発行された証明書が使用できなくなる
  • 手動でのCSR管理はヒューマンエラーが起きやすく、有効期限管理を怠ると証明書切れによる障害につながる
  • OV/EV証明書のCSRでは組織の実在確認に数日かかる場合があり、緊急時のスピード対応に向かない

類似技術との違い：DV証明書 vs OV証明書 vs EV証明書

CSRを提出した後、CAがどこまで審査するかによって発行される証明書の種類（検証レベル）が異なります。CSR自体の形式は同じでも、申請時に提出する追加情報や審査プロセスが変わります。

種類 審査内容 発行時間 主な用途
DV（ドメイン認証） ドメインの所有権のみ確認 数分〜数十分（自動化可能） 個人サイト、Let's Encryptによる一般的なWebサイト
OV（組織認証） ドメイン所有権に加え、組織の実在性を確認 数日 企業サイト、社内システム
EV（拡張認証） 組織の法的実在性を厳格に審査（登記情報等の確認） 数日〜数週間 金融機関、ECサイトなど高い信頼性が求められるサービス

いずれの種類でもCSRの生成手順自体は共通ですが、OV・EV証明書では申請時にCAへ登記簿謄本などの追加書類提出が求められる点が異なります。

実務での活用シーン・導入時の注意点

主な活用シーン

  • 新規Webサーバー・ロードバランサーへのSSL/TLS証明書導入
  • ワイルドカード証明書によるマルチテナント・サブドメイン運用
  • コード署名証明書やクライアント証明書（mTLS用）の申請
  • 証明書更新時の鍵ローテーション（新しい鍵ペアでCSRを再生成）

導入時の注意点

  • 鍵長・アルゴリズムの選定：RSAなら2048ビット以上、ECDSAならprime256v1（P-256）以上を選択する
  • SANの網羅：CNだけでなく必要なすべてのドメイン・サブドメインをSANに含める（主要ブラウザはCNを無視しSANのみを検証する）
  • 秘密鍵の保管：CSR生成時に作成される秘密鍵はサーバー外に持ち出さず、パーミッションを適切に制限する（chmod 600）
  • 自動化の検討：DV証明書であればACMEプロトコル（Certbot等）による自動更新を導入し、手動によるCSR管理・有効期限切れのリスクを減らす

関連ブログ記事

最新動向（2026年）

ACMEプロトコルによる自動化

Let's Encryptなどで使用されるACMEプロトコルでは、CSRの生成から証明書の取得まで自動化されています。手動でのCSR管理は減少傾向にありますが、EV証明書など一部では依然必要です。

楕円曲線暗号（ECC）の普及

# ECDSA鍵でのCSR生成
openssl ecparam -genkey -name prime256v1 -out server-ec.key
openssl req -new -key server-ec.key -out server-ec.csr \
  -subj "/C=JP/ST=Tokyo/O=Example Inc./CN=www.example.com"

トラブル事例と対策

⚠️ 秘密鍵の紛失

問題：発行された証明書があっても秘密鍵がないと使用できない

対策：CSR生成時に秘密鍵を安全にバックアップ。紛失した場合は証明書を再発行

⚠️ CNの間違い

問題：Common Nameにタイポがあると証明書が使えない

対策：CSR生成前にドメイン名を二重確認。openssl req -in server.csr -noout -subjectで確認

権威あるリソース

関連用語

よくある質問（FAQ）

Q. CSR（Certificate Signing Request）とは何ですか？

CSR（証明書署名要求）は、TLS/SSL証明書の発行を認証局（CA）に依頼するためのデータです。ドメイン名・組織情報・公開鍵を含み、申請者の秘密鍵で署名されています。CAはCSRを検証し、問題なければTLS証明書を発行します。openssl req -new -key private.key -out request.csrコマンドで生成できます。

Q. CSRとはどの情報が必要ですか？

CSRに必要な主な情報：CN（Common Name）はFQDN（例：example.com）、O（Organization）は組織名、C（Country）はISO国コード2文字（例：JP）、ST（State）は都道府県、L（Locality）は市区町村、SANs（Subject Alternative Names）は追加ドメイン名です。SANsはマルチドメイン証明書で重要で、現代の証明書ではCNよりSANsが優先されます。

Q. Let's Encryptを使えばCSRの手動作成は不要ですか？

Certbotを使用すればCSRの手動作成・送信は自動化されます。certbot --nginx -d example.comで証明書取得から更新まで自動化できます。カスタムCSR（特定の鍵ペアを使用する場合等）を使いたい場合はcertbot certonly --csr custom.csrオプションで指定できます。

この用語についてもっと詳しく

CSRに関するご質問や証明書取得のご相談など、お気軽にお問い合わせください。