Server

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

投稿日:2019年2月26日 更新日:

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
(発行者の情報)
  • その証明書の発行者の情報
  • 通常は認証局のルート証明書もしくは中間CA証明書の情報がセットされます。
  • 例えば、twitter.com の証明書の発行者は以下です(これは中間CA証明書です)。
Subject
(サブジェクト)
(主体の情報)
  • その証明書が証明している主体(対象)の情報
  • 通常はあなた(のドメイン)の情報がセットされます(CSR作成時に入力した内容)。
  • 例えば、twitter.com の証明書のサブジェクト以下です。
有効期限 設定した有効期限になっているか確認します。

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

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

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

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

Apache の関連情報

Nginx の関連情報

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

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

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

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

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

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

コマンドを利用する

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

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

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

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

証明書チェーン

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

ここでは、Chrome ブラウザで証明書チェーンについて説明します。

まず、Chrome で twitter.com にアクセスし、アドレスバーの左側にある鍵アイコンをクリック → [証明書] をクリックします。

Chromeブラウザで証明書を表示
Chromeブラウザで証明書を表示

以下のように [全般]タブには、「発行先」「発行者」「有効期間」など主な項目が表示されますが、この証明書について詳しく知るには他のところを見ないといけません。

[全般]タブ
[全般]タブ

[詳細]タブの [サブジェクト] には、このサーバー証明書の「主体の情報」がセットされています。

サブジェクトの確認
サブジェクトの確認

[発行者] には、このサブジェクトに対して署名を行った発行者の情報がセットされています。

発行者の確認
発行者の確認

ということで、[詳細] タブでは、どの[発行者] がどの[サブジェクト] に署名を行っているかが分かります。

[発行者] が [サブジェクト] に署名しています
[発行者] が [サブジェクト] に署名しています

そして、[証明のパス]タブに表示されるのが、証明書チェーン(証明のパス)です。

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

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

📂-Server

執筆者:labo


  1. migi より:

    この記事のおかげで中間証明書の理解が深まりました。

    質問させて頂きたいのですが、「利用者のサーバからクライアントに送るデータ」に「利用者の署名」が必要な理由はなんでしょうか?
    サーバ証明書の中にある「中間CAの署名」の検証が成功したら、サーバ証明書の公開鍵が正当であることが証明されるので、そこまでで十分かと思いました。

    • labo より:

      コメントありがとうございます
      この図において、利用者の署名は「本人確認」のために使用しています(改ざん防止にも使えますが)。
      サーバ証明書は公開されるものですが、「利用者の秘密鍵」は本人しか持っていません。その秘密鍵で署名し、クライアント側で検証して貰うことにより「図中の「利用者」のサーバと通信している」ことが確認できます。サーバ証明書だけでは、第三者のサーバと通信している可能性もありますので「本人確認」が必要です。

comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

関連記事はありませんでした