SSLサーバー証明書の発行手順について説明します。
サーバー証明書について「なんとなくは分かるけど、実際よく分かっていない」という方向けの内容になっています。
目次
1. SSL/TLS についての簡単な説明
SSL/TSL プロトコル
Webで利用される HTTP プロトコルは暗号化されないため、どこかの経路で通信内容を覗かれてしまうとすべての内容が筒抜けになります。これを防ぐため HTTP の暗号化に利用されるプロトコルが TLS/SSL です(HTTP以外の暗号化にも使われています)。
現在では TLS (Transport Layer Security) という名前で呼ぶのが正しいのですが、TLS の元となったプロトコルが SSL であり、こちらの名前が普及しているため SSL と呼ばれることが多いです。
また、HTTPS と呼ばれることもありますが、厳密には HTTTPS はプロトコルではなく URL におけるスキーム (scheme) の名前です(URL におけるコロンの前の部分)。
SSL/TSL プロトコルに対応するには、サーバー証明書が必要
ウェブサイトを SSL/TSL プロトコルに対応させるには、そのウェブサイトのドメイン(例: www.example.com
)に対して発行されたサーバー証明書が必要で、これをウェブサーバーに設定することになります。
では、自分で勝手にサーバー証明書を発行して使えばよいのかというとそうではなく、自分のドメインの正当性を第三者に担保してもらわなければいけません。サーバー証明書は暗号化(盗聴防止)だけでなく、認証機能(なりすまし防止)も持っているのです(改ざん防止機能もあります)。その第三者に誰がなってくれるのかというと、「信頼のおける第三者機関」である 認証局 (CA) です。認証局が発行している ルート証明書 と呼ばれる信頼済みの証明書が主要なブラウザには組み込まれているのですが、認証局の署名が入ったサーバー証明書であれば、証明書の関係をたどることによってルート証明書につながり、ドメインの正当性を確認してもらうことができます。
ということで、サーバー証明書は 認証局 (CA) を運営する企業から購入する必要があります。本記事ではそのための手順を説明します。
※ 最近では Let’s Encrypt というサービスを利用することにより、無料でサーバー証明書を発行することができます。
2. 証明書の概要図
まず最初に、サーバー証明書がどのようなものなのかについての概要図を載せておきます。
この後の説明で分からないところがありましたら、こちらの図に戻って、「その説明はこの図のどこにあたるのか?」を考えてみてください。
※「利用者」というのは、サーバーの管理者のことを指します。
※ 中間CA証明書はない場合もありますし、複数階層ある場合もあります。
※「検証」はブラウザが行います。
※ 秘密鍵で「証明書の内容」を暗号化しておき(これが署名です)、それをペアとなる公開鍵で復号できれば「検証」ができたことになります。
3. SSLサーバー証明書の発行手順
1. 秘密鍵の作成
openssl genrsa -des3 -out path/to/server.key 2048
- ファイルとしては、秘密鍵のみが生成されますが、この秘密鍵を元に公開鍵を生成することができます。
des3
オプション- DES3アルゴリズムで秘密鍵を暗号化します。
- パスフレーズが求められますので、推測されにくい文字列を入力してください。
- 今後、秘密鍵にアクセスするにはパスフレーズが必要になります。
- パスワードで保護された秘密鍵をテキストエディタで表示すると、以下のような箇所があります。
- Proc-Type: 4,ENCRYPTED
- DEK-Info: DES-EDE3-CBC,050xxxxxxx
- 他の暗号化アルゴリズムを使用したい場合は、
man genrsa
コマンドでマニュアルを読んでください。
秘密鍵の内容を閲覧するには、以下のコマンドを実行します。
openssl rsa -text -in server.key
あまり必要はないと思いますが、この秘密鍵ファイルを元にして公開鍵を生成するには、以下のコマンドを実行します。
openssl rsa -in server.key -pubout -out server.pub
2. 秘密鍵のパスフレーズ解除
この後、CSR(*) を生成するために必要であるため、秘密鍵からパスフレーズを解除したファイルを生成しておきます。
* Certificate Signing Request、認証局に提出する署名リクエスト
# 元の秘密鍵ファイルをコピーしておきます
$ cp -p server.key server.key.orig
# パスフレーズなしのファイルを、元のファイル名で上書きします
$ openssl rsa -in server.key.orig -out server.key
3. CSRの作成
server.csr というファイル名で、CSR ファイルを生成します。
CSR とは、認証局に提出するファイルの1つで、ここで設定した情報がサーバー証明書に書き込まれます。
openssl req -new -key server.key -out server.csr
以下の項目に対して入力が求められます。これは証明の対象を識別するための情報です。
識別名項目 | 略称 | 説明 | 例 |
---|---|---|---|
Common Name (コモンネーム) | CN | 認証される名前 SSL接続するURL |
CN=www.example.com |
Organizational Name(組織名) | O | 団体の正式英語組織名 | O=Example Japan K.K. |
Organizational Unit Name (部門名) | OU | 部署名など | OU=Customer Service |
Localty Name (市区町村) | L | 所在してる市区町村 | L=Sapporo |
State or Provice Name (都道府県) | ST | 所在してる都道府県 | ST=Hokkaido |
Country Name (国) | C | 所在している国名の ISO コード 日本の場合 JP |
C=JP |
※ 引用元:SSL/TLS 暗号化: はじめに – Apache HTTP サーバ バージョン 2.4
※ これ以外の項目もありますが、それらは必須ではありません。
CSRファイルの内容を確認するには以下のコマンドを実行します。
openssl req -text -noout -in server.csr
4. SSL証明書の発行
認証局にSSLサーバー証明書を発行して貰う場合
認証局にSSLサーバー証明書を発行して貰うには、CSR ファイルを認証局業者に渡します。滞りなく手続きが済めば、CRTファイル(証明書)を発行して貰えます。
自分で署名する場合
既存の認証局からサーバー証明書を発行して貰うのではなく、自分の秘密鍵でサーバー証明書を署名する(自己証明書)には、以下のコマンドを実行します。
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
オプション | 説明 |
---|---|
-req |
CRTの生成を指定します。 |
-days |
有効期限を日数で指定します。 |
-in |
CSRファイルを指定します。 |
-signkey |
署名に使う秘密鍵ファイルを指定します。 |
-out |
出力ファイル名(証明書ファイル)を指定します。 |
サーバー証明書の内容を確認する
サーバー証明書ファイルの内容を確認するには、以下のコマンドを実行します。
openssl x509 -text -noout -in server.crt
特に確認しておくところは、以下です。
項目 | 説明 |
---|---|
Issuer (発行者の情報) |
|
Subject (サブジェクト) (主体の情報) |
|
有効期限 | 設定した有効期限になっているか確認します。 |
※ CN, OU, O, L, S, C は、CSR を作成した時に指定した項目です。
「どの発行者」が「誰」に対して発行した証明書なのか確認しましょう。
4. サーバ証明書をWebサーバに設定する
通常は Webサーバーの設定の一部として、サーバー証明書を指定する項目があります。
Apache の関連情報
Nginx の関連情報
5. サーバ証明書が問題なく設定できているかテストする
サーバ証明書が設置できたら、問題なく設定できているかテストします。
外部のサービスを利用する
セキュリティ関連企業・組織が証明書のテストサービスを提供しています。調査したドメインを入力してボタンを押すだけで、証明書をチェックしてくれます。
- SSL Server Test (Powered by Qualys SSL Labs)
- かなり詳細なテスト
- Check Website Security | DigiCert SSLTools
- 少し詳細なテスト
- SSL Certificate Checker – Diagnostic Tool | DigiCert.com
- シンプルなテスト
※ サービスによっては、調査したドメイン名がそのサイトに表示されてしまうこともありますので注意しましょう(ドメイン名をサイトに表示しないようなオプションが用意されていることもあります)。
ブラウザ側のSSL/TLS対応状況確認は、以下のサイトで可能です。
コマンドを利用する
openssl
コマンドを使って証明書をテストすることもできます。
openssl s_client -connect コモンネーム:443
SNIを利用している場合は、-servername
オプションを追加します。
openssl s_client -connect コモンネーム:443 -servername コモンネーム
証明書チェーン
チェックするポイントはいろいろありますが、大切なポイントの1つは 証明書チェーン です。
ここでは、Chrome ブラウザで証明書チェーンについて説明します。
まず、Chrome で twitter.com にアクセスし、アドレスバーの左側にある鍵アイコンをクリック → [証明書] をクリックします。
以下のように [全般]タブには、「発行先」「発行者」「有効期間」など主な項目が表示されますが、この証明書について詳しく知るには他のところを見ないといけません。
[詳細]タブの [サブジェクト] には、このサーバー証明書の「主体の情報」がセットされています。
[発行者] には、このサブジェクトに対して署名を行った発行者の情報がセットされています。
ということで、[詳細] タブでは、どの[発行者] がどの[サブジェクト] に署名を行っているかが分かります。
そして、[証明のパス]タブに表示されるのが、証明書チェーン(証明のパス)です。
ここには、ルートCA証明書から末端の サーバー証明書 までの階層が表示されます。
ルートCA証明書や中間CA証明書を選択し、[証明書の表示]ボタンを押せばそれぞれの証明書も見ることができますので、そちらの [発行者], [サブジェクト] も確認してみましょう。
この画面上に、改めてそれぞれの証明書の関係を書いてみました。
ルートCA証明書 (DigiCert) は、ブラウザに元から入っており(既に信頼されているという扱い)、中間CA証明書 (DigiCert SHA2 High Assurance Server CA) とサーバー証明書 (twitter.com) は、ウェブサイトにアクセスした時にウェブサーバから送られてきます。ですので、twitterサイトにアクセスした時に、
- サーバー証明書(twitter.com) が、中間CA証明書(DigiCert SHA2 High Assurance Server CA) から発行されている。
- 中間CA証明書(DigiCert SHA2 High Assurance Server CA) が、ブラウザが持っている ルートCA証明書(DigiCert) から発行されている
ことが確認できれば、ルートCA証明書 から twitter.com のサーバー証明書 までがつながり、サーバー証明書は OK ということになります。
openssl
のコマンドの実行結果が分かりやすいので見てましょう。
実行するコマンド
openssl s_client -connect twitter.com:443
出力の中にある「Certificate chain(証明書チェーン)」を見てください。
(省略)
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=tsa_m Point of Presence/CN=twitter.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
(省略)
※ 1つ目(0)は、サーバー証明書(twitter.com)
※ 2つ目(1)は、中間CA証明書 (DigiCert SHA2 High Assurance Server CA)
※ i は Issuer (発行者)、s は Subject(サブジェクト) を表しています。
この表示の分かりやすい点は、「上側の証明書の発行者(i)」と「その下の証明書のサブジェクト(s)」が必ず同じになるという点です。つまり、同じ識別情報が必ず2行続きます(一番上と下は除く)。中間CA証明書が何段階あっても同じことが言えますです。証明書がチェーンされていることがよく分かる表示です。(一番下はルートCAの識別情報になります)
6. おわりに
最初に載せた概要図を理解すると、サーバー証明書についての各種操作がかなりやりやすくなるのではないかと思いますので、是非参考にしてみてください。
この記事のおかげで中間証明書の理解が深まりました。
質問させて頂きたいのですが、「利用者のサーバからクライアントに送るデータ」に「利用者の署名」が必要な理由はなんでしょうか?
サーバ証明書の中にある「中間CAの署名」の検証が成功したら、サーバ証明書の公開鍵が正当であることが証明されるので、そこまでで十分かと思いました。
コメントありがとうございます
この図において、利用者の署名は「本人確認」のために使用しています(改ざん防止にも使えますが)。
サーバ証明書は公開されるものですが、「利用者の秘密鍵」は本人しか持っていません。その秘密鍵で署名し、クライアント側で検証して貰うことにより「図中の「利用者」のサーバと通信している」ことが確認できます。サーバ証明書だけでは、第三者のサーバと通信している可能性もありますので「本人確認」が必要です。