はじめに
業務でSSL/TLS証明書を申請する機会があり、CSR（証明書署名要求）を自分で作成してCA認証局に提出する作業を担当しました。
CSRという単語は聞いたことがあったものの、実際に作るのは初めてだったので、仕組みから調べ直しました。この記事はそのときに調べたことのまとめです。
CSRとは何か、秘密鍵やCAとの関係、opensslコマンドでの具体的な作成手順まで、一通り書いています。同じように初めてCSRを作ることになった方の参考になれば幸いです。
そもそもCSRとは何か
CSRはCertificate Signing Request（証明書署名要求）の略で、CA（認証局）に「この内容で証明書を作ってください」と依頼するための申請書ファイルです。
SSL/TLS証明書を取得するまでの流れは、大きく3ステップあります。
- 自分で秘密鍵とCSRを作成する
- CSRをCA認証局に提出する
- CAが署名した証明書が返ってくる
ここで重要なのは、「鍵を作るのは自分、署名するのはCA」という役割分担です。
秘密鍵・公開鍵・CA署名の関係
CSRの仕組みを理解するには、秘密鍵と公開鍵の関係を押さえておく必要があります。
秘密鍵を生成すると、そこから対応する公開鍵が自動的に導出されます。CSRにはこの公開鍵と、組織名やドメイン名などの情報が含まれています。
秘密鍵（自分だけが持つ）
↓ 導出
公開鍵 + 組織情報 + ドメイン名
↓ まとめたもの
CSR（認証局に送る）
↓ CAが署名
証明書（ブラウザに信頼される）
CAはCSRの内容を確認し、自身の秘密鍵で署名を行います。これが「証明書」です。ブラウザはCAの署名を検証することで、その証明書が正当なものかどうかを判断します。
つまり、自分で秘密鍵を作ること自体はオレオレ証明書と同じですが、署名するのが信頼されたCAであるという点が異なります。
| 秘密鍵を作るのは | 署名するのは | ブラウザに信頼される？ | |
|---|---|---|---|
| オレオレ証明書 | 自分 | 自分 | いいえ |
| CA発行の証明書 | 自分 | CA認証局 | はい |
プライベートCA と パブリックCA の違い
CA認証局には大きく分けて2種類あります。
パブリックCAは、Let's EncryptやDigiCertなどが該当します。これらのCAが発行した証明書は、ChromeやEdgeなどの主要ブラウザにルートCAとして事前登録されているため、誰がどの端末からアクセスしても信頼されます。
プライベートCAは、企業や組織が独自に運用するCAです。社内のルートCA証明書がインストールされた端末からは信頼されますが、それ以外の端末からアクセスするとブラウザに「この接続は安全ではありません」という警告が表示されます。
どちらを選ぶかは、証明書を使うサービスに誰がアクセスするかで決まります。
| CA種別 | 信頼される範囲 | ユースケース |
|---|---|---|
| パブリックCA | インターネット上の全端末 | 一般公開するWebサイト |
| プライベートCA | CA証明書をインストール済みの端末のみ | 社内システム、VPN経由のアクセス |
社内専用のシステムであればプライベートCAで十分です。一方、社外のユーザーもアクセスするサービスであればパブリックCAが必要になります。
CSRの作成手順自体は、どちらのCAに提出する場合も同じです。
SANとワイルドカード証明書
1枚の証明書で複数のドメインをカバーしたい場合、SANとワイルドカードの2つの仕組みを使います。
SAN（Subject Alternative Name）
SANは、1枚の証明書に複数のドメイン名を登録する仕組みです。たとえば、以下の3つのドメインを1枚の証明書でカバーできます。
DNS.1 = app.example.com
DNS.2 = api.example.com
DNS.3 = admin.example.com
CSRを作成する際にSANを指定しておくと、CAが発行する証明書にもそのSANが含まれます。
ワイルドカード証明書
ワイルドカード証明書は、*.example.com のようにアスタリスクを使って、同一階層のサブドメインをまとめてカバーする証明書です。
*.example.com であれば、app.example.com や api.example.com など、任意のサブドメインに対応できます。
ただし、ワイルドカードが有効なのは1階層分だけです。*.example.com は sub.app.example.com のような2階層のサブドメインにはマッチしません。階層が異なるドメインをカバーする必要がある場合は、SANで複数のワイルドカードを登録します。
DNS.1 = *.example.com
DNS.2 = *.app.example.com
DNS.3 = *.admin.example.com
SANに含められるドメイン数はCA認証局によって上限が異なるため、CSR作成前に確認しておくと安心です。
このあたりごっちゃになりそうですが、SANは「招待者名簿」でワイルドカードは「リストへの書き方の一つ」と覚えるとよいかもしれません。
CSR作成の手順
ここからは、opensslコマンドを使ってCSRを作成する具体的な手順を説明します。
今回は以下の要件を想定します。
- RSA 2048bitの秘密鍵
- ワイルドカード証明書
- SANで複数ドメインをカバー
Step 1: 秘密鍵の生成
まず、RSA 2048bitの秘密鍵を生成します。
openssl genrsa -out server.key 2048
このコマンドで server.key というファイルが作成されます。この秘密鍵は証明書とペアで使うものなので、紛失すると証明書が使えなくなります。安全な場所に保管してください。
Step 2: 設定ファイルの作成
CSRに含める情報を設定ファイル（CNF形式）にまとめます。
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = v3_req
distinguished_name = dn
[dn]
C = JP
ST = Tokyo
L = Chiyoda
O = Example Corp
OU = Engineering
CN = *.example.com
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.example.com
DNS.2 = *.app.example.com
DNS.3 = *.admin.example.com
各項目の意味は以下のとおりです。
[dn] セクション（組織情報）
| 項目 | 意味 | 例 |
|---|---|---|
| C | 国コード（2文字） | JP |
| ST | 都道府県 | Tokyo |
| L | 市区町村 | Chiyoda |
| O | 組織名 | Example Corp |
| OU | 部署名 | Engineering |
| CN | コモンネーム（主ドメイン） | *.example.com |
[alt_names] セクション（SAN）
カバーしたいドメインを DNS.1, DNS.2, ... と列挙します。CNに指定したドメインもSANに含めておくのが一般的です。
この設定ファイルを csr.cnf として保存します。
Step 3: CSRの生成
秘密鍵と設定ファイルを指定してCSRを生成します。
openssl req -new -key server.key -out server.csr -config csr.cnf
server.csr が作成されます。これがCA認証局に提出するファイルです。
Step 4: 内容の確認
提出前にCSRの中身を確認しておきます。
openssl req -text -noout -in server.csr
出力から、以下の項目が意図どおりか確認します。
- Subject: 組織名やCNが正しいか
- Subject Alternative Name: SANに必要なドメインが全て含まれているか
- Public-Key: 鍵長が2048bitか
Subject: C=JP, ST=Tokyo, L=Chiyoda, O=Example Corp, OU=Engineering, CN=*.example.com
...
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:*.app.example.com, DNS:*.admin.example.com
この内容に問題がなければ、CSRの作成は完了です。
CSRを作成したら
CSRを作成したあとの流れと、注意点をまとめます。
CAに提出するもの・しないもの
| ファイル | 内容 | CAに送る？ |
|---|---|---|
server.csr |
証明書署名要求 | 送る |
server.key |
秘密鍵 | 絶対に送らない |
CSRには公開鍵が含まれていますが、秘密鍵は含まれていません。CAが必要とするのはCSRだけです。秘密鍵を外部に送る必要は一切ありません。
秘密鍵の保管
秘密鍵を紛失すると、CAから証明書が返ってきても使えません。CSR作成からやり直しになります。
ローカルのファイルシステムに置いたままだとPCの故障やクリーンアップで消える可能性があるため、AWS Secrets ManagerやHashiCorp Vaultなどのシークレット管理サービスに保管しておくことをお勧めします。
証明書が返ってきたら
CAから署名済みの証明書ファイル（.crt や .pem）が届きます。この証明書を秘密鍵とペアでWebサーバーやロードバランサーに設定すれば、HTTPS通信が有効になります。
秘密鍵（server.key） + 証明書（server.crt）
↓
Webサーバーに設定 → HTTPS有効化
まとめ
CSR作成の流れを振り返ります。
-
openssl genrsaで秘密鍵を生成する - 組織情報とSANを記載した設定ファイル（CNF）を作成する
-
openssl reqでCSRを生成する - CSRの中身を確認し、CAに提出する
- 秘密鍵は送らずに安全な場所で保管する
やっていることは「CAへの申請書を作る」だけです。opensslコマンド3つで完了するので、一度やってしまえば次回からは迷わないと思います。
CAの種類（パブリック/プライベート）やSANの構成は環境によって異なりますが、CSRの作成手順自体は共通です。この記事が初めてCSRを作る方の参考になれば幸いです。