実際にSSL/TLSサーバ証明書を取得し、設定、検証するポイントを理解しましょう。
検証、不正発行防止は忘れられがちですが、安全なWebサイトの運営のためにはぜひ実行してください。
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"
ここに書かれている内容を順に説明すると、以下のようになります。
IISの場合は、インターネットインフォメーションサービス（IIS）マネージャーからステップバイステップでCSRを作成できます。
作成されたCSRには認証局（CA）が発行するSSL/TLSサーバ証明書で使用される公開鍵情報が含まれています。
Webサーバーによっては、決められたGUIでCSR作成を行う必要があるなど、手順が異なることがあります。サーバーごとの手順は、以下の「代表的アプリケーションでのCSR作成方法」を参照してください。
SSL/TLSサーバ証明書が取得できたら、Webサーバーにインストールします。
インストールに必要なファイルは、以下の3ファイルです。
秘密鍵ファイルはCSR作成の際に作成したファイルですので、すでにサーバーに保存されているはずです。
SSL/TLSサーバ証明書ファイル、中間証明書ファイルが認証局（CA）から発行されます。
Windows向けの証明書の場合、SSL/TLSサーバ証明書ファイル・中間証明書ファイルの二つの証明書ファイルはひとつにまとまっています。
中間証明書はSSL/TLS サーバー証明書と認証局（CA）のroot証明書の関連性を証明するために発行される証明書です。
CA (認証局) から中間証明書が提供された場合は、必ず中間証明書も利用する設定を行ってください。そうしないと信頼できない証明書と判断される場合があります。
このほかにクロスルートと呼ばれる証明書が必要な場合がありますが、一般的には、クロスルート証明書は中間証明書ファイル内に含まれます。
インストールの具体的な手順は、以下の「代表的アプリケーションでのインストール方法」を参照してください。
IISのようにGUIが用意されているサーバーの場合、ステップバイステップで行えば間違いありませんが、Apache等の場合、理解しておいたほうが良い点があります。
例えば、Apacheではインストール設定を ssl.conf 等のファイルの <VirtualHost …> … </VirtualHost> ディレクティブ内で行います。
このうち、SSLProtocolとSSLCipherSuiteの二つのディレクディブの意味を理解しておく必要があります。将来変更の必要が出てくるかもしれないためです。
SSLProtocolは、Webサーバーで利用できるTLS通信のバージョンを決定します。
現在安全とされているバージョンはTLSv1.2です。
以下は、「SSLv2、SSLV3 を除くすべての利用可能なプロトコルを利用する」指定です。
しかし、古いプロトコルは危険性があるため、近い将来（環境によってはすぐに）、TLSv1、TLSv1.1 も利用しないよう設定したほうが良いかもしれません。
その場合は、以下のように指定します。
または
host_nameサーバーにTLSv1.2で接続できるかを調べるには、以下のコマンドを利用します。
openssl s_client -connect host_name:443 -tls1_2
成功した場合、表示情報内に以下が表示されます。
SSLCipherSuiteは、Webサーバーで利用できる暗号を決定します。
CipherSuiteとは、HTTPS接続で利用できる暗号セットのことです。
OpenSSL 1.0.1e-fips 11 Feb 2013では、75の CipherSuite (暗号セット) が利用可能です。
利用できる CipherSuite は以下のコマンドで確認できます。
openssl ciphers -v
このコマンドを実行すると、以下のようなリストが得られます。
各行は左から順にスペース区切りで、「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等 |
以下のような指定が可能です。
「CipherSuite名」で指定
「暗号セット」で指定
「利用不可、強度レベル」で指定
複数要素の指定の場合、”” コートであればスペース区切り、コートなしであれば、: 区切りとします。
利用不可指定、強度レベル指定での ! は利用不可、+ 追加を示します。
強度レベルは、以下です。
ディレクティブ名SSLCipherSuiteはApacheで利用、nginxでは、ssl_ciphersディレクティブを使います。
実際の設定では、まずサーバーのデフォルトの設定を採用してください。
その後、以下で説明する検証を行い、最適な設定を見つけてください。
サーバ証明書がインストールされ、ブラウザからアクセスして問題がなさそうに見える場合でも、セキュリティの観点からは修正したほうが良い設定になっている場合があります。
そうした問題の発見を手助けしてくれるサイトが、「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
!DHE-RSA-CAMELLIA128-SHA をSSLCipherSuiteに追加します。
利用しているドメインの証明書が不正に、あるいは誤って発行されることを防止することと、発行状態を把握することは重要です。
過去には、オランダの認証局（CA）のroot証明書が漏洩し、google.com ドメインの証明書が不正に発行された事件もありました。
また、中国の認証局（CA）が証明書を不正発行し、そのCAのroot証明書が取り消しになったこともあります。
誤発行を防ぐ有力な手段が、DNSへのCAA（Certification Authority Authorization）登録です。
DNSのCAAレコードに、そのドメインに対して証明書を発行できる認証局（CA）を指定できます。
CA/ブラウザフォーラムの規定により、認証局（CA）はCAAレコードに違反した証明書は発行できませんので、誤発行の可能性を低下させることができます。
数年前までは、利用しているドメインの証明書の発行状態を完全に把握するのは困難でした。
また、利用しているドメインを偽装する目的で発行されている証明書の発行状態を把握するのはほとんど不可能でした。
しかし、現在はCTという仕組みがあります。
CTでは、証明書発行の際、認証局（CA）がCTログという誰でも閲覧できるサイトに証明書を登録します。
CTログへの登録は義務ではありませんが、Google Chromeが2018年4月以降CTログに登録されていない証明書に警告を出すようになるため、現実的には全認証局（CA）がCTログ登録を行うでしょう。
CTログを直接参照し利用ドメインについて調査することもできますが、CTログを参照し検索を支援するサイト「Censys」もおすすめです。
例えば “paypal” で検索すれば、secure-paypal-com.xxx.biz というようなコモンネームの証明書が発行されていることを確認できます。
証明書の保護だけでなく、自社の商標権侵害防止にも有効なツールです。
・SSLサーバー証明書
・コードサイニング
その他証明書
・バウチャ(クーポン)
