カテゴリー
ソフトウェア

SSL 証明書の作成とインストール

はじめに

SSL 証明書は SSL 証明書発行機関によって、対象のドメインが実際にどの組織によって運営されているかを保障するための証明書です。今回、SSL 証明書の申請からインストールまでの手順を紹介します。

組織の実体証明の厳密さにより、SSL 証明書のグレードが設けられています。呼び方、認証方法は SSL 証明書発行機関により差がありますが、大まかには次の 3 グレードがあるようです。

  • Class1 … ドメインの所有者をオンラインにより確認。
      ドメイン名宛のメールアドレスなど、例えば postmaster@example.com 宛に届く確認メールで運営者を確認できれば認証 OK となります。
  • Class2 … ドメインの所有者を電話により確認。
      ドメイン名宛のメールアドレスに加えて、運営者の電話番号宛の電話などで運営者を確認できれば認証 OK となります。
  • Class EV … ドメインの所有者を書類により確認。
      ドメイン名宛のメールアドレス、運営者の電話番号宛の電話に加えて、書類の送付などにより運営者を確認できれば認証 OK となります。

どのグレードの SSL 証明書でも、サーバーへのインストール手順は同じです。CentOS の場合、次のようなディレクトリ・ファイル構成で管理するとよいでしょう。この構成は SSL 証明書の他に、中間証明書を 2 つ必要とする 4 層構成の SSL 証明書をインストールする場合の構成です。

なお、SSL 証明書関連のファイルがいくつか出てきますが、すべて PEM 形式とよばれるテキスト文字列のファイルです。本投稿ではファイルの役割を拡張子に付ける事で、わかりやすくなるようにしています。また、年度の更新がしやすいよう、ファイルの末尾には有効期限日を付けておきます。ただし、本番用にリリースするときは、サーバーの設定ファイルを編集しなくて済むよう、有効期限日は削除します。日付付きのファイルで一式を準備してから、日付なしのファイルにコピーして本番環境に適用する、という流れを想定しています。

(作業用ユーザーエリア) 
~/tls/
   certs/                     ← 外部に公開するファイルを格納するディレクトリ
     example.com.crt.20160519 ← SSL 証明書
     example.com.ca.20160519  ← 中間証明書(3層目、2層目、の順で結合したもの)
   private/                   ← 外部に公開してはいけない/公開する必要がないファイルを格納するディレクトリ
     example.com.ca2.20160519 ← 中間証明書(2層目、クロスルート証明書と呼ばれることがある)
     example.com.ca3.20160519 ← 中間証明書(3層目)
     example.com.csr.20160519 ← CSR
     example.com.key.20160519 ← 秘密鍵 (本番用グローバルエリア)
 /etc/pki/tls/
   certs/                     ← 外部へ公開するファイルを格納するディレクトリ
     example.com.crt          ← SSL 証明書
     example.com.ca           ← 中間証明書(3層目、2層目、の順で結合したもの)
   private/                   ← 秘密鍵を格納するディレクトリ
     example.com.key          ← 秘密鍵

大まかな流れは次のとおりです。

  • SSL 証明書の申請
  • SSL 証明書の受領
  • SSL 証明書のインストール

SSL 証明書の申請

SSL 証明書の申請は、まず秘密鍵 (Private Key) を生成するところから始まります。これは SSL 証明書をインストールしたいホストにインストールするためのファイルです。SSL 証明書発行機関によっては、申請フォームの序盤のステップとして、秘密鍵を生成できるようになっている場合もあります。

SSL 証明書の申請には、発行しようとしている SSL 証明書に記載される運営者情報やドメイン名などを含みます。これも申請フォームのひとつのステップとして用意されている場合があります。

問題なく申請が進むと、SSL 証明書と、必要があれば中間証明書がダウンロードできるようになります。

秘密鍵の生成

秘密鍵は SSL 証明書とペアで使用します。SSL 証明書は不特定多数のクライアントに公開するのに対して、秘密鍵は SSL 証明書を公開するサーバーから漏洩しないように厳重に保管する必要があります。

有効期限(EXPIRED) はだいたいの日付でかまいません。SSL 証明書を受領した際に、正確な日付に変更します。

$ mkdir -p ~/tls/certs ~/tls/private
$ DOMAIN_NAME="example.com"
$ EXPIRED="20160101"

$ openssl genrsa -rand /dev/urandom 2048 > ~/tls/private/${DOMAIN_NAME}.key.${EXPIRED}

CSR の作成

CSR は SSL 証明書の申請書です。SSL 証明書に記載する内容、つまり運営者の所在地や申請するドメイン名(コモンネーム) などを含めます。

$ openssl req -new -sha256 \
    -key ~/tls/private/${DOMAIN_NAME}.key.${EXPIRED} \
    -out ~/tls/private/${DOMAIN_NAME}.csr.${EXPIRED}

今後作成する CSR は SHA1 ではなく SHA256 で作成しましょう。多くの SSL 証明書発行機関は、SHA1 による申請受付を 2015/12/31 までで停止することが決まっています。また、多くのブラウザーは 2017/01/01 以降、SHA1 の SSL 証明書を組み込んだサイトへアクセスできなくなることも発表されました。

作成した CSR の記載内容に誤りがないか確認します。問題なければ、現行のCSR という意味で、末尾の日付を取り除いたファイルとしてコピーしておきます。もし前年度のものがあっても、上書きしてしまってください。間違って古い方の CSR を提出するリスクを回避できます。

$ openssl asn1parse -in ~/tls/private/${DOMAIN_NAME}.csr
$ cp ~/tls/private/${DOMAIN_NAME}.csr.${EXPIRED} \
     ~/tls/private/${DOMAIN_NAME}.csr

SSL 証明書発行機関へ申請

作成した CSR (~/tls/private/${DOMAIN_NAME}.csr) を SSL証明書発行機関へ提出して、SSL 証明書が発行されるのを待ちます。

SSL 証明書の受領

無事 SSL 証明書の発行が通知されたら、次は実際に利用できるように準備します。

SSL 証明書をインストールするサーバーによって、SSL 証明書と中間証明書をひとつにまとめる必要があったり、秘密鍵、SSL 証明書、中間証明書 のすべてをひとつにまとめる必要があるものがあります。

本投稿では、秘密鍵 (.keyファイル)、SSL 証明書 (.crtファイル)、中間証明書 (.caファイル) の 3 つに分けて構成します。

記載内容の確認(ダウンロード前)

発行された SSL 証明書をダウンロードする前に、申請したときの内容も表示してもらえる場合があります。SSL 証明書発行機関の作成結果に相違がないことを確認します。

記載内容の確認(ダウンロード後)

まず、現行の CSR を確認します。ダウンロードした SSL 証明書を作成して、内容を確認します。また、秘密鍵と SSL 証明書のペアに誤りがないことを確認します。

(現行の CSR の一覧を表示)
$ ls -l ~/tls/private/*.csr*

(これから作成する SSL 証明書向けの環境変数を設定)
$ DOMAIN_NAME="example.com"
$ EXPIRED="20160101"

(SSL 証明書の作成)
$ vi ~/tls/certs/${DOMAIN_NAME}.crt.${EXPIRED}

(SSL 証明書の内容確認)
$ openssl x509 -noout -text -in ~/tls/certs/${DOMAIN_NAME}.crt.${EXPIRED}

(SSL 証明書と関連ファイルの有効期限修正)
$ NEW_EXPIRED="20160520"
$ mv ~/tls/certs/${DOMAIN_NAME}.crt.${EXPIRED} \
     ~/tls/certs/${DOMAIN_NAME}.crt.${NEW_EXPIRED}
$ mv ~/tls/private/${DOMAIN_NAME}.key.${EXPIRED} \
     ~/tls/private/${DOMAIN_NAME}.key.${NEW_EXPIRED}
$ mv ~/tls/private/${DOMAIN_NAME}.csr.${EXPIRED} \
     ~/tls/private/${DOMAIN_NAME}.csr.${NEW_EXPIRED}
$ EXPIRED=${NEW_EXPIRED}

(SSL 証明書と秘密鍵とのペアチェック)
$ openssl s_server -accept 4433 \
    -cert ~/tls/certs/${DOMAIN_NAME}.crt.${EXPIRED} \
    -key ~/tls/private/${DOMAIN_NAME}.key.${EXPIRED}

SSL 証明書と秘密鍵とのペアに問題がなければ、最後の行に「ACCEPT」と表示されて、SSL サーバーが起動して待機状態になります。SSL サーバーは次の手順で使用しますので、起動したままにしておいてください。

もしエラーが発生した場合は、SSL 証明書と秘密鍵のペアが正しいか確認してください。

中間証明書の受領

中間証明書が必要な場合はここで準備します。中間証明書は SSL 証明書発行機関により呼び名が異なる場合があります。

下記の例では、中間証明書が(中間証明書とクロスルート証明書など)2つある、4層構成の場合をとりあげます。ルート証明書に近い層の中間証明書は 2 層目、SSL 証明書に近い層の中間証明書は 3 層目 として読み替えてください。

中間証明書が1つだけの場合は3層目の中間証明書 (*.ca3) を除いてください。

(先の手順で指定した環境変数を設定)
$ DOMAIN_NAME="example.com"
$ NEW_EXPIRED="20160520"

(2 層目の中間証明書を作成)
$ vi ~/tls/private/${DOMAIN_NAME}.ca2.${NEW_EXPIRED}

(3 層目の中間証明書を作成)
$ vi ~/tls/private/${DOMAIN_NAME}.ca3.${NEW_EXPIRED}

(1 つの中間証明書として結合)
$ LIST=$(ls -1r ~/tls/private/${DOMAIN_NAME}.ca?.${NEW_EXPIRED})
$ for ITEM in ${LIST}
> do
>   cat ${ITEM} >> ~/tls/certs/${DOMAIN_NAME}.ca.${NEW_EXPIRED}
> done

SSL 証明書、中間証明書の整合性確認

SSL 証明書は SSL 証明書の Subject と中間証明書(あれば)の Issuer、中間証明書の Subject と ルート証明書の Issuer と辿ることができてはじめて有効、と判断されます。SSL 証明書と中間証明書の整合性に問題がないことを、実際にサーバーに組み込む前に確認します。

(先の手順で指定した環境変数を設定)
$ DOMAIN_NAME="example.com"
$ NEW_EXPIRED="20160520"

(SSL 証明書と中間証明書を使って、先の手順で起動しておいた SSL サーバーに接続)
$ openssl s_client \
    -connect localhost:4433 \
    -CAfile ~/tls/certs/${DOMAIN_NAME}.ca.${NEW_EXPIRED}

組み合わせに問題がなければ、最後の行に「Verify return code: 0 (ok)」と表示されます。

もしエラーが発生した場合は、下記を参考に確認してください。

中間証明書が不足しているか、結合順序に誤りがある可能性があります。

Verify return code: 21 (unable to verify the first certificate)

openssl コマンドが持っていないルート証明書を参照している可能性があります。ルート証明書(つまり1層目の証明書)は SSL 証明書発行機関からダウンロードできます。ルート証明書を、結合済みの中間証明書(.caファイル)の末尾に一時的に追記して確認してみてください。成功すれば問題ありません。動作確認ができたら、追記したルート証明書は .ca ファイルから忘れず削除してください。

Verify return code: 2 (unable to get issuer certificate)

SSL 証明書と関連ファイルのデプロイ

整合性が確認できれば、関連ファイル一式を新しい現行ファイルとしてリリースします。具体的には、ファイル末尾の日付を取り除き、ユーザーエリアからグローバルエリアにコピー(上書き)します。

$ sudo cp ~/tls/private/${DOMAIN_NAME}.key.${EXPIRED} \
          /etc/pki/tls/private/${DOMAIN_NAME}.key
$ sudo cp ~/tls/certs/${DOMAIN_NAME}.ca.${EXPIRED} \
          /etc/pki/tls/certs/${DOMAIN_NAME}.ca
$ sudo cp ~/tls/certs/${DOMAIN_NAME}.crt.${EXPIRED} \
          /etc/pki/tls/certs/${DOMAIN_NAME}.crt

サーバーソフトウェアは SSL 証明書が更新されたことを検出できない場合が多いので、サーバーソフトウェアに応じて設定ファイルのリロードを実行してください。

新規に SSL 証明書をサーバーソフトウェアに組み込む場合は、以降の記事を参照してください。

SSL 証明書のインストール

SSL 証明書と中間証明書を、サーバーにインストールします。サーバーにより記述が異なりますので、主なサーバー毎の設定方法を紹介します。

Nginx へインストール

Nginx では、SSL 証明書は中間証明書とひとつにまとめたものと、秘密鍵を指定します。下記コマンドで、ひとつにまとめた証明書を作成します。

$ sudo sh -c '
>   cat /etc/pki/tls/certs/example.com.crt /etc/pki/tls/certs/example.com.ca \
>     > /etc/pki/tls/certs/example.com.bundle.crt
> '

HTTPS でも接続できるように、443 ポートをリッスンするための設定を追加します。

予め HTTP (80 ポート) の設定が済んでいる場合は、server セクションをまるごとコピーして、下記のようにリッスンするポートと SSL 関連の設定をします。

/etc/nginx/conf.d/example.com.conf

server {
    listen  443;

    ssl  on;
    ssl_certificate  /etc/pki/tls/certs/example.com.bundle.crt;
    ssl_certificate_key  /etc/pki/tls/private/example.com.key;

    (中略)
}

server {
    listen  80;

    (中略)
}

設定が完了したら、Nginx を再起動します。

$ sudo systemctl restart nginx

Dovecot へインストール

Dovecot はメール受信サーバーです。SSL 証明書をインストールすると、IMAPS や POP3S が利用できるようになります。

Dovecot では秘密鍵、SSL 証明書、中間証明書の 3 つをそれぞれ別々に指定します。編集内容を diff コマンドの結果で記します。

/etc/dovecot/conf.d/10-ssl.conf

14,15c14,15
< ssl_cert = /etc/pki/dovecot/certs/dovecot.pem
< ssl_key = /etc/pki/dovecot/private/dovecot.pem
---
> ssl_cert = /etc/pki/tls/certs/example.com.crt
> ssl_key = /etc/pki/tls/private/example.com.key
26c26
< #ssl_ca =
---
> ssl_ca = /etc/pki/tls/certs/example.com.ca

設定が完了したら、Dovecot を再起動します。

$ sudo systemctl restart dovecot

SSL 接続ができるか確認します。

(POP3S の場合)
$ openssl s_client -connect example.com:995
> USER user@example.com
> PASS user_pass
> LIST
> RETR 9999
> QUIT

(IMAPS の場合)
$ openssl s_client -connect example.com:993
> a LOGIN user@example.com user_pass
> a SELECT Inbox
> a LOGOUT

コメントを残す

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

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください