SSLサーバー証明書の発行手順

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

以下の項目に対して入力が求められます。これは証明の対象を識別するための情報です。

※ 引用元：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

特に確認しておくところは、以下です。

※ CN, OU, O, L, S, C は、CSR を作成した時に指定した項目です。

「どの発行者」が「誰」に対して発行した証明書なのか確認しましょう。

4. サーバ証明書をWebサーバに設定する

通常は Webサーバーの設定の一部として、サーバー証明書を指定する項目があります。

Apache の関連情報

• mod_ssl – Apache HTTP Server Version 2.4
• SSL/TLS 暗号化: はじめに – Apache HTTP サーバ バージョン 2.4

Nginx の関連情報

• Configuring HTTPS servers

5. サーバ証明書が問題なく設定できているかテストする

サーバ証明書が設置できたら、問題なく設定できているかテストします。

外部のサービスを利用する

セキュリティ関連企業・組織が証明書のテストサービスを提供しています。調査したドメインを入力してボタンを押すだけで、証明書をチェックしてくれます。

• SSL Server Test (Powered by Qualys SSL Labs)
  • かなり詳細なテスト
• Check Website Security | DigiCert SSLTools
  • 少し詳細なテスト
• SSL Certificate Checker – Diagnostic Tool | DigiCert.com
  • シンプルなテスト

※ サービスによっては、調査したドメイン名がそのサイトに表示されてしまうこともありますので注意しましょう（ドメイン名をサイトに表示しないようなオプションが用意されていることもあります）。

ブラウザ側のSSL/TLS対応状況確認は、以下のサイトで可能です。

• Qualys SSL Labs – Projects / SSL Client Test

コマンドを利用する

openssl コマンドを使って証明書をテストすることもできます。

openssl s_client -connect コモンネーム:443

SNIを利用している場合は、-servername オプションを追加します。

openssl s_client -connect コモンネーム:443 -servername コモンネーム

証明書チェーン

チェックするポイントはいろいろありますが、大切なポイントの１つは 証明書チェーン です。

ここでは、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. おわりに

最初に載せた概要図を理解すると、サーバー証明書についての各種操作がかなりやりやすくなるのではないかと思いますので、是非参考にしてみてください。