この文書では OpenSSL を使った自己署名サーバー証明書の作成方法のメモを残す。
更新履歴
(2025.08.31) 作成。
(2025.09.01) OU フィールド禁止などを追記。
目次
1. はじめに
自己署名サーバー証明書は、信頼された証明書発行機関ではなく、自前で用意したルートCA局で発行したサーバー証明である。 オレオレ証明書とか呼ばれる。 自己署名サーバー証明書は Web サーバーのテストや閉じたネットワーク内のサーバー用に必要となる。
Web 上にはこの自己署名サーバー証明書の作成方法がいろいろ紹介されているが、ブラウザやシステムのセキュリティ要件が年々上昇しているため内容が古くなっている記事が多い。 そのため記事に従ってサーバー証明書を作成すると、一部システムで動作しないものができる。
- ルート証明書で直接署名したサーバー証明書は弾かれることがある。 中間CA局を作り中間証明書でサーバー証明書を署名する。
- Chrome と Firefox の両方で利用できるようにする。
- Chrome は CN(Common Name) フィールドだけのサーバー証明書を受理しないので SAN(Subject Alternative Name)フィールドを付ける。
- Firefox は CA フィールドが TRUE でないルート証明書をインポートできないのでこれに対応する。
- サーバー証明書のサブジェクトに OU(Organizational Unit) フィールドを指定することは禁止となっている。 2022年9月1日以降に発行する証明書に含めることができない。
この文書は、執筆時に最新のシステムで広く適用可能なサーバー証明書の作り方を説明する。
操作は OpenSSL がインストールされている Linux 系マシンで実行することを想定している。
2. 手順
2.1 準備
ルート証明書、中間証明書を作成するために以下の設定ファイルを作成する。
[ v3_ca ] basicConstraints = CA:TRUE keyUsage = keyCertSign, cRLSign subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer
これは Firefox がルート証明書を証明認証局用の証明書として取り込む際に、証明書に CA:TRUE という属性が必要になるためである。
Firefox はこの属性が埋め込まれないルート証明書をインポートできない。
X509v3 Basic Constraints:
CA:TRUE
2.2 ルートCA証明書の作成
2.2.1 ルートキーの作成
まずルートCA局のための暗号化キーを作成する。
openssl ecparam -out rootca.key -name prime256v1 -genkey
2.2.2 証明書署名要求(CSR)の作成
次にルート証明書の属性値を決める証明書署名要求(CSR)のファイルを作成する。
openssl req -new -sha256 -key rootca.key -out rootca.csr \
-subj "/C=JP/ST=Kanagaw/L=Kawasaki/O=Example Inc/OU=Dev/CN=rootca.example.com/emailAddress=rootca@example.com"
-subj がない場合には openssl コマンドが対話的に情報の入力を求めるが、-subj を指定するとこの情報入力を省略できる。
2.2.3 ルート証明書を自己署名する
最後にルートキーでルートキーを自己署名し、CSR やその他の情報を埋め込む。
openssl x509 -req -sha256 -days 3650 -in rootca.csr -out rootca.crt -signkey rootca.key -extfile openssl_ca.cnf -extensions v3_ca
-days 3650 はルート証明書の有効期限を決める。 ルート証明書の有効期限の上限には明確な決まりがないが 10 年としている。
-extfile openssl_ca.cnf -extensions v3_ca は、ルートCA証明書の中に CA:TRUE という属性を付与するために必要となる。
2.3 中間CA証明書の作成
2.3.1 ルートキーの作成
次に中間CA局のための暗号化キーを作成する。
openssl ecparam -out intermidateca.key -name prime256v1 -genkey
2.3.2 証明書署名要求(CSR)の作成
次に中間CA証明書の属性値を決める証明書署名要求(CSR)のファイルを作成する。
openssl req -new -sha256 -key intermidateca.key -out intermidateca.csr \
-subj "/C=JP/ST=Kanagaw/L=Kawasaki/O=Example Inc/OU=Dev/CN=intermidateca.example.com/emailAddress=intermidateca@example.com"
2.3.3 中間証明書をルート証明書で署名する
最後に中間CA局のキーを、ルート証明書で署名し、CSR やその他の情報を埋め込む。
openssl x509 -req -sha256 -days 1825 -in intermidateca.csr -out intermidateca.crt \
-CA rootca.crt -CAkey rootca.key -CAcreateserial \
-extfile openssl_ca.cnf -extensions v3_ca
-CA rootca.crt -CAkey rootca.key -CAcreateserial はルート証明書で署名することを指示している。
-days 1825 は中間証明書の有効期限を決める。 中間証明書の有効期限の上限にも明確な決まりがないが、ルート証明書の有効期限の半分の5年としている。
ルート証明書同様に -extfile openssl_ca.cnf -extensions v3_ca を付けて、CA:TRUE の属性を付与する。
中間証明書はブラウザに取り込むことはないので必須ではないが、一応付ける。
2.4 サーバー証明書の作成
ここからサーバー証明書を作成する。 Web サーバーが複数ある場合などは、この章の操作を何度か行う必要がある。
2.4.1 ルートキーの作成
次に中間C局のための暗号化キーを作成する。
openssl ecparam -out server.key -name prime256v1 -genkey
2.4.2 証明書署名要求(CSR)の作成
サーバー証明書の属性値を決める証明書署名要求(CSR)のファイルを作成する。
openssl req -new -sha256 -key server.key -out server.csr \
-subj "/CN=www.example.com"
-subj には CN(Common Name) フィールドのみを指定する方がよい。 Let's Encrypt などのサーバー証明書も CN フィールドのみとなっている。
それ以外に OU(Organizational Unit) フィールドは禁止となったので含めてはならない。
2.4.3 SANファイルの作成
CN(Common Name) フィールドに埋め込める FQDN は 1 つしかない。 そこで CN フィールドを拡張する形で、SAN(Subject Alternative Name) フィールドが作られた。 SAN には複数の FQDN や IP アドレスを列挙することができ、ワイルドカードにも対応している。
ただ SAN フィールドは現在必須のフィールドで、Google Chrome は CN フィールドを無視して SAN フィールドのみを参照するので必ず作成する必要がある。
subjectAltName = DNS: www.example.com
複数の値がある場合はカンマで区切って並べる。
subjectAltName = DNS: www.example.com, DNS: *.example.com, IP: 10.20.30.40
2.4.4 サーバー証明書を中間証明書で署名する
最後にサーバー証明書のキーを、中間証明書で署名し、CSR やその他の情報を埋め込む。
openssl x509 -req -sha256 -days 365 -in server.csr -out server.crt \
-extfile SAN.txt \
-CA intermidateca.crt -CAkey intermidateca.key -CAcreateserial
-extfile SAN.txt で SAN フィールドを設定している。
-CA intermidateca.crt -CAkey intermidateca.key -CAcreateserial は中間証明書で署名することを指示している。
-days 365 はサーバー証明書の有効期限を決める。 サーバー証明の有効期限は現在は 398 日だが、今後だんだん短縮され 2029年3月15日以降は 47 日となる となるので注意が必要だ(参考: サーバートラストの記事)
サーバー証明書は CA:FALSE となる必要がある。
-extfile openssl_ca.cnf -extensions v3_ca は付けない。
2.4.5 サーバー証明書の確認を行う
完成したサーバー証明書のチェックを行う。
openssl x509 -in server.crt -text -noout
3. ブラウザへのルート証明書の取り込み
rootca.crt がルート証明書になる。 自己署名サーバー証明書を使った Web サーバーなどにアクセスするためには、rootca.crt をブラウザに取り込む必要がある。 その手順を説明する。
3.1 Google Chrome へのルート証明書の取り込み
Google Chrome は OS の証明書ストアを使っているので、そこに rootca.crt を取り込む。 Chorme を Windows 10/11 で動かしている場合の手順を説明する。
- Chrome の右上の「…」を横にしたボタンを押しメニューを表示し、「設定」を選択する。
- 左メニューから「プライバシーとセキュリティ」をクリックする。
- 「セキュリティ(セーフブラウジング(危険なサイトからの保護機能)などのセキュリティ設定)」をクリックする。
- 「セキュリティ」画面のかなり下の方にある「証明書の管理」をクリックする。
- 「ローカル証明書」の中の「Windowsからインポートした証明書を管理する」をクリックする。 ここからは Chrome ではなく Windows の設定画面が表示される。
- 「証明書」ダイアログが表示されるので、「インポート」をクリックする。
- 「証明書のインポートウィザードの開始」ダイアログが表示されるので、「次へ(N)」をクリックする。
- 「インポートするファイルを指定してください。」とでるので、rootca.crt を取り込む。rootca.crt が出てこない場合は拡張子を「すべてのファイル(*.*)」にすること。 rootca.crt を指定できたら「次へ(N)」をクリックする。
- 「証明書をすべて次のストアに配置する(P)」を選択した後、「信頼されたルート証明機関」と選択し、「次へ(N)」をクリックする。
- 「証明書のインポート ウィザードの完了」とされるので「完了(F)」をクリックする。
- 「証明書」ダイアログの「信頼されたルート証明期間」に追加分があるか確認する。この例では発行先が rootca.example.com となる。
3.2 Firefox へのルート証明書の取り込み
Firefox はブラウザ独自の証明書ストアがあり、そこに rootca.crt を取り込む。
- Chrome の右上の横棒3本のボタンを押しメニューを表示し、「設定」を選択する。
- 左メニューから「プライバシーとセキュリティ」をクリックする。
- 「ブラウザープライバシー」画面のかなり下の方にある証明書セクションの「証明書の管理…(C)」をクリックする。
- 「証明書マネージャー」ダイアログが表示されるので、「認証局証明書」タグに移動し、「インポート…(M)」のクリックする。
- ファイルエクスプローラーで rootca.crt を選択する。
4. Web サーバーなどへのサーバー証明書の配備
4.1 Nginx への配備
Web サーバーの代表として nginx にサーバー証明を配備する例を説明する。
Nginx にサーバー証明を設定する場合、サーバー証明書と中間証明書を結合したフルチェイン証明書を作成する必要がある。
cat server.crt intermidateca.crt > fullchain.crt
結合の順序は重要である。 中間CA局を複数作っている場合には、末端 → ルートに近い方の順序で並べること。
作成できた fullchain.crt と server.key を nginx サーバーに転送し、nginx から
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate "/path/to/fullchain.crt";
ssl_certificate_key "/path/to/server.key";
// 省略
}
SELinux の制限により転送したファイルが nginx から読み込みを禁止されている可能性がある。 その場合は以下のコマンドを実行する。
- restorecon -v /path/to/fullchain.crt、restorecon -v /path/to/server.key を実行する。
- /path/to/ が /home だった場合、setsebool -P httpd_read_user_content 1 を実行する。
設定されている SELinux のラベルは ls -Z server.key などで確認できる。
4.1 PFX ファイルへの変換
Azure Application Gateway などでは PFX ファイルを使ってサーバー証明書を配備する。
openssl pkcs12 -export -inkey server.key -in server.crt -certfile intermidateca.crt -out server.pfx
PFX ファイルを作成時にパスワードの設定を求められるが、必ずパスワード文字列を指定すること。 パスワードが空の PFX ファイルは登録できないシステムが多い。
TOP