DigiCert証明書の正規代理店株式会社アールエムエス
DigiCert サーバー証明書利用団体
  1. ホーム
  2. HTTPS 入門
  3. 証明書を使う

SSL/TLSサーバ証明書を使う

実際にSSL/TLSサーバ証明書を取得し、設定、検証するポイントを理解しましょう。
検証、不正発行防止は忘れられがちですが、安全なWebサイトの運営のためにはぜひ実行してください。

SSL/TLSサーバ証明書の取得

SSL/TLSサーバ証明書を取得するためには、証明書を利用するサーバーで秘密鍵とそれと紐づいたCSR(サーバー証明書要求:Certificate Signing Request)を作成し、CSRだけを認証局(CA)に提出する必要があります。

以下は、当社のドメイン creative-japan.net のWebサイト www.creative-japan.net のための、Apacheサーバー向けCSRを、秘密鍵と同時に作成するopensslコマンドの例です。

openssl req -new -newkey rsa:2048 -nodes -out creative-japan.net.csr -keyout creative-japan.net.key -sha256 -subj "/C=JP/ST=Tokyo/L=Tama City/O=RMS Co. Ltd./OU=Creative Japan Net/CN=www.creative-japan.net"

ここに書かれている内容を順に説明すると、以下のようになります。

  • 「openssl req -new -newkey」-------- openssl コマンドでCSRと秘密鍵を新規作成
  • 「rsa:2048」------------------------ RSA暗号の、鍵長 2048bit の証明書を要求
  • 「-out creative-japan.net.csr」----- CSRを creative-japan.net.csr ファイルに保存
  • 「-keyout creative-japan.net.key」-- 秘密鍵を creative-japan.net.key ファイルに保存
  • 「-sha256」------------------------- 暗号ハッシュ関数はsha256を使用
  • 「-subj ""」------------------------ "" 内で証明書に含む情報を指定
  • 「C=JP」---------------------------- 国名:日本
  • 「ST=Tokyo」------------------------ 都道府県名:東京
  • 「L=Tama City」--------------------- 都市名:多摩市
  • 「O=RMS Co. Ltd.」------------------ 組織名:RMS Co. Ltd.
  • 「OU=Creative Japan Net」----------- 部署名:Creative Japan Net
  • 「CN=www.creative-japan.net」------- 証明書のホスト名:www.creative-japan.net

IISの場合は、インターネットインフォメーションサービス(IIS)マネージャーからステップバイステップでCSRを作成できます。

作成されたCSRには認証局(CA)が発行するSSL/TLSサーバ証明書で使用される公開鍵情報が含まれています。
Webサーバーによっては、決められたGUIでCSR作成を行う必要があるなど、手順が異なることがあります。サーバーごとの手順は、以下の「代表的アプリケーションでのCSR作成方法」を参照してください。

※opensslコマンドを使ってCSRを作成した場合は、秘密鍵が他人に閲覧されないように、厳重に保管してください。

Webサーバーでの証明書の設定

SSL/TLSサーバ証明書が取得できたら、Webサーバーにインストールします。
インストールに必要なファイルは、以下の3ファイルです。

  • 秘密鍵ファイル
  • SSL/TLSサーバ証明書ファイル
  • 中間証明書ファイル

秘密鍵ファイルはCSR作成の際に作成したファイルですので、すでにサーバーに保存されているはずです。
SSL/TLSサーバ証明書ファイル、中間証明書ファイルが認証局(CA)から発行されます。
Windows向けの証明書の場合、SSL/TLSサーバ証明書ファイル・中間証明書ファイルの二つの証明書ファイルはひとつにまとまっています。
中間証明書はSSL/TLS サーバー証明書と認証局(CA)のroot証明書の関連性を証明するために発行される証明書です。

CA (認証局) から中間証明書が提供された場合は、必ず中間証明書も利用する設定を行ってください。そうしないと信頼できない証明書と判断される場合があります。
このほかにクロスルートと呼ばれる証明書が必要な場合がありますが、一般的には、クロスルート証明書は中間証明書ファイル内に含まれます。

証明書のインストール

インストールの具体的な手順は、以下の「代表的アプリケーションでのインストール方法」を参照してください。

IISのようにGUIが用意されているサーバーの場合、ステップバイステップで行えば間違いありませんが、Apache等の場合、理解しておいたほうが良い点があります。
例えば、Apacheではインストール設定を ssl.conf 等のファイルの <VirtualHost ...> ... </VirtualHost> ディレクティブ内で行います。
このうち、SSLProtocolとSSLCipherSuiteの二つのディレクディブの意味を理解しておく必要があります。将来変更の必要が出てくるかもしれないためです。

SSLProtocolとSSLCipherSuite

SSLProtocol:TLSのバージョン決定

SSLProtocolは、Webサーバーで利用できるTLS通信のバージョンを決定します。
現在安全とされているバージョンはTLSv1.2です。
以下は、「SSLv2、SSLV3 を除くすべての利用可能なプロトコルを利用する」指定です。

SSLProtocol all -SSLv2 -SSLV3

しかし、古いプロトコルは危険性があるため、近い将来(環境によってはすぐに)、TLSv1、TLSv1.1 も利用しないよう設定したほうが良いかもしれません。
その場合は、以下のように指定します。

SSLProtocol all -SSLv2 -SSLV3 -TLSv1 -TLSv1.1

または

SSLProtocol +TLSv1.2

host_nameサーバーにTLSv1.2で接続できるかを調べるには、以下のコマンドを利用します。

openssl s_client -connect host_name:443 -tls1_2

成功した場合、表示情報内に以下が表示されます。

SSL-Session: Protocol : TLSv1.2
SSLCipherSuite:利用できる暗号を決定

SSLCipherSuiteは、Webサーバーで利用できる暗号を決定します。
CipherSuiteとは、HTTPS接続で利用できる暗号セットのことです。
OpenSSL 1.0.1e-fips 11 Feb 2013では、75の CipherSuite (暗号セット) が利用可能です。

利用できる CipherSuite は以下のコマンドで確認できます。

openssl ciphers -v

このコマンドを実行すると、以下のようなリストが得られます。

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ........ ........ ........ RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1 KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5

各行は左から順にスペース区切りで、「CipherSuite名」「プロトコル」「鍵交換アルゴリズム」「認証アルゴリズム」「ストリーム暗号」「ハッシュアルゴリズム」を示しています。

各要素には以下のような選択肢があります。

要素名暗号名等
プロトコルSSLv3, TLSv1.2t等
鍵交換アルゴリズム
Kx --- Key Exchange
RSA, Diffie-Hellman, ECDH, SRP, PSK等
認証アルゴリズム
Au --- Authentication
RSA, DSA, ECDSA等
ストリーム暗号
Enc --- Encryption
RC4, Triple DES, AES, IDEA, DES, Camellia等
ハッシュアルゴリズム
Mac --- Message Authentication Code
SHA1, SHA256, SHA384, AEAD, MD5等

SSLCipherSuiteの書式

以下のような指定が可能です。

「CipherSuite名」で指定

SSLCipherSuite AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5

「暗号セット」で指定

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA"

「利用不可、強度レベル」で指定

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!LOW:!RC4:+HIGH:+MEDIUM

複数要素の指定の場合、"" コートであればスペース区切り、コートなしであれば、: 区切りとします。
利用不可指定、強度レベル指定での ! は利用不可、+ 追加を示します。
強度レベルは、以下です。

  • HIGH--------共通鍵暗号方式の鍵長が 128bit より大きい暗号セット
  • MEDIUM------共通鍵暗号方式の鍵長が 128bit の暗号セット
  • LOW---------共通鍵暗号方式の鍵長が 56bit または 64bit の暗号セット

ディレクティブ名SSLCipherSuiteはApacheで利用、nginxでは、ssl_ciphersディレクティブを使います。
実際の設定では、まずサーバーのデフォルトの設定を採用してください。
その後、以下で説明する検証を行い、最適な設定を見つけてください。

サーバ証明書設定の検証

サーバ証明書がインストールされ、ブラウザからアクセスして問題がなさそうに見える場合でも、セキュリティの観点からは修正したほうが良い設定になっている場合があります。
そうした問題の発見を手助けしてくれるサイトが、「SSL Server Test」です。
以下のリンクから誰でも利用できます。

推奨サイト:SSL Server Test

テストするホスト名を入力すると、数分で以下のような評価結果が表示されます。

A+評価の場合は全く問題ありません。セキュリティ上、A+、A、A-の評価であればよいとされているようです。それ以外の場合は見直しを行いましょう。

上図のような結果が表示された場合は、ピンクの帯に表示された問題は必ず解決してください。
濃い黄色の帯に表示された問題も、できれば解決する必要があります。

画面下部には、以下のようにCipherSuitesについての評価結果も表示されます。

濃い黄色で WEAK と表示されたものは利用しない設定にしましょう。

以下が表示された場合

TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 1024 bits FS WEAK
Apache等のCipherSuite表記と異なっていますが、以下のコマンドでコード(例:0x45)からSSLCipherSuiteで指定するCipherSuite名(例:DHE-RSA-CAMELLIA128-SHA)を見つけることができます。

openssl ciphers -V | grep 0x45
0x00,0x45 - DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1

!DHE-RSA-CAMELLIA128-SHA をSSLCipherSuiteに追加します。

不正発行の防止とチェック

利用しているドメインの証明書が不正に、あるいは誤って発行されることを防止することと、発行状態を把握することは重要です。
過去には、オランダの認証局(CA)のroot証明書が漏洩し、google.com ドメインの証明書が不正に発行された事件もありました。
また、中国の認証局(CA)が証明書を不正発行し、そのCAのroot証明書が取り消しになったこともあります。

DNS CAAで誤発行を防止

誤発行を防ぐ有力な手段が、DNSへのCAA(Certification Authority Authorization)登録です。
DNSのCAAレコードに、そのドメインに対して証明書を発行できる認証局(CA)を指定できます。
CA/ブラウザフォーラムの規定により、認証局(CA)はCAAレコードに違反した証明書は発行できませんので、誤発行の可能性を低下させることができます。

CTログ検索

数年前までは、利用しているドメインの証明書の発行状態を完全に把握するのは困難でした。
また、利用しているドメインを偽装する目的で発行されている証明書の発行状態を把握するのはほとんど不可能でした。
しかし、現在はCTという仕組みがあります。
CTでは、証明書発行の際、認証局(CA)がCTログという誰でも閲覧できるサイトに証明書を登録します。
CTログへの登録は義務ではありませんが、Google Chromeが2018年4月以降CTログに登録されていない証明書に警告を出すようになるため、現実的には全認証局(CA)がCTログ登録を行うでしょう。

CTログを直接参照し利用ドメインについて調査することもできますが、CTログを参照し検索を支援するサイト「Censys」もおすすめです。
例えば "paypal" で検索すれば、secure-paypal-com.xxx.biz というようなコモンネームの証明書が発行されていることを確認できます。
証明書の保護だけでなく、自社の商標権侵害防止にも有効なツールです。

おすすめサイト:Censys

全ページHTTPS化関連情報

SSL サーバ証明書とは?
30日間テスト証明書
30日間返金保証制度あり!
コードサイニング証明書
ドキュメントサイニング証明書
デジタル証明書ニュース
HTTPS入門
digicert.comトピックス&ニュース