HTTPSアクセスにして、Webサイトの安全性を確保するためには、SSL/TLSサーバ証明書が必須です。
SSL/TLSサーバ証明書にはいくつかの種類があり、発行している認証局（CA）も多数あります。
サイトの性格に合わせて、最適なSSL/TLSサーバ証明書を選択してください。
例えば、銀行のWebサイトにアクセスし、振込を行う場合を想像してみてください。
安心して利用するためには、必ず保証されなければならない要素が二つあります。
アクセスしているサイトが間違いなく銀行のサイトであること
送受信データが保護され、第三者による閲覧や改ざんができないこと
著名な決済サイトやショッピングサイトを偽装したサイトを開設してユーザーを誘導しパスワードや個人情報を盗み出すフィッシングや、正規のサーバーとユーザーの通信経路の中間に入り込み、データの閲覧や改ざんを行う中間者攻撃（MiTM）などの犯罪からユーザーを守るためには、HTTPSで通信を暗号化することが重要ですが、HTTPSプロトコルだけでは上の二つの保証は実現できません。
SSL/TLSサーバ証明書を利用することによってはじめて、「サイトの真正性の保証」と「暗号化によるデータ保護」が実現します。
安心してWebサイトを利用するためには、これらが保証されていることが重要です。
SSL/TLSサーバ証明書には、Webサイトの証明書が含まれています。また、証明書を発行した機関の情報も含まれています。
この発行者のことを認証局（CA）と言います。
サーバーからSSL/TLSサーバ証明書の提示を受けたブラウザは、ブラウザ自身がその証明書を発行した認証局（CA）の証明書（root証明書と呼びます）を持っている場合、その証明書を信頼できる証明書と判断します。
そして、提示されたSSL/TLSサーバ証明書で証明されているサイトの真正性を認めます。
いわゆるオレオレ証明書を公開Webサイトで利用できないのは、オレオレ証明書を発行したオレオレ認証局（CA）のroot証明書をブラウザが持っていないからです。
HTTPS通信では、ブラウザとWebサーバーが暗号化のための鍵を秘密裏に共有し、共有した鍵を使って暗号化・復号化を行っています。
秘密裏に鍵を共有するために使われるのが、公開鍵と秘密鍵です。
公開鍵で暗号化されたデータを復号化できるのは、ペアの秘密鍵だけです。
これを、公開鍵暗号（Public-key cryptography）方式と呼びます。
HTTPS接続開始時に、サーバーからSSL/TLSサーバ証明書の提示を受けたブラウザは、そこに含まれる公開鍵を使って共通鍵を暗号化し、サーバーに送信します。
サーバーは秘密鍵を使って共通鍵を復号化し、ブラウザと共通鍵を共有できます。
通信経路上で暗号化された共通鍵を傍受しても、公開鍵では復号化できません。秘密鍵を持っているサーバーだけが復号化でき、ブラウザとサーバーだけが共通鍵を共有できます。
最初だけ公開鍵と秘密鍵を使い、以降は共通鍵を使うのは、共通鍵の方が暗号化・復号化の際の負荷が低いためです。
Webサイトで利用するために最適な証明書選を択するには、SSL/TLSサーバ証明書の種類についての理解が必要です。
広く利用されている証明書は、機能などによって以下のように分類できます。
| 名称 | 認証の範囲 |
|---|---|
| ドメイン認証（DV） | ドメインの実在・ドメイン権利者による証明書申請 |
| 組織認証（OV） | ドメイン認証範囲に加え、ドメイン権利者組織の実在 |
| 拡張認証（EV） | 組織認証に加え、ドメイン権利者組織実在の確実性 |
| 名称 | 証明するホスト |
|---|---|
| 単一ホスト名 | 単一ホスト名あるいはプラス www.ホスト名 |
| ワイルドカード | ホスト名のすべてのサブホスト名（*.ホスト名） |
| マルチドメイン | 証明書申請者が所有するドメインの複数のホスト名（www.example.com, www.example.net） |
| 名称 | 特徴 |
|---|---|
| RSA | 現在主流の暗号手法 |
| 楕円曲線暗号（ECC） | Webの高速化が可能 |
証明書を選択する際には、Webサイトの特徴にマッチしたものを選択したいものです。
SSL/TLSサーバ証明書の選択する際の選択肢となる主な要素は、以下のようなものでしょう。
一般的に、Webサイトの運営主体別に以下のような証明書が最適と言われています。
商用にSSL/TLSサーバ証明書を発行している認証局（CA）の場合、そのroot証明書はほとんどのブラウザから信頼されているはずなので、どの認証局から購入しても利用できないということはありません。
しかし、証明書購入先の認証局が誤発行を繰り返したり、業界基準に違反した証明書を発行したりした場合、その認証局のroot証明書が無効になったり、取得済みの証明書の再取得が必要になったりする場合もあります。
購入予定の証明書を絞り込んだら、その証明書で使われるroot証明書を確認してください。購入先のWebサイトで確認できるはずです。あるいは、購入先に問合せれば教えてもらえるはずです。
次に、以下の「CA/ブラウザフォーラムメンバーリスト」にアクセスし、購入予定の証明書、またはroot証明書に記載された認証局（CA）の名前がリストに含まれているかを確認してください。
認証局（CA）の名前がリストに含まれていない場合でもすぐには危険だと断定することはできませんが、含まれている場合は最新の基準に基づいて証明書発行が行われているはずですので、安心できます。
もちろん、当サイトで証明書を取扱っているDigiCertは、CAブラウザフォーラムの主要メンバーです。
信頼できるか、適切なサポートが受けられるか、などの要素が満たされた認証局が複数ある場合は、価格ももちろん重要になってきます。
必要な証明書がドメイン認証（DV）の証明書で、Unixの知識があるなら、無料のLet’s Encryptを採用することになるでしょう。
組織認証（OV）の証明書が必要な場合は、商用にSSL/TLSサーバ証明書を発行している認証局（CA）から選択することになります。
DigiCertの証明書は他の認証局が発行する組織認証の証明書と比べてコストパフォーマンスが非常に高く、ワイルドカード証明書やマルチドメイン証明書を利用すれば、更に大幅なコストダウンにつながります。
・SSLサーバー証明書
・コードサイニング
その他証明書
・バウチャ(クーポン)
