全ページを HTTPSに移行するためにはコストが発生します。
しかし、従来に比べそのコストは大幅に低下し、ほとんどのWebサイト運営者が苦痛なく負担できるものになっています。
HTTPSでは、暗号化されたデータを通信するため、すべてのデータがWebサーバーとブラウザの双方で暗号化・復号化されます。
そのため、双方の環境でCPUに負荷が発生します。
しかし、現在一般的なクライアント環境では、この負荷により、「HTTPSのWebページの表示がHTTPのものよりも遅く感じる」というほどの影響はありません。
Webサーバー側の負荷は通信量に比例して増加しますので一概には言えませんが、一般的なサイトであれば、近年のCPUの能力アップにより、大幅な費用負担なく負荷を処理できると思われます。
また、高負荷になるネゴシエーションの負荷をECC証明書の利用で下げることができます。
更に、ネゴシエーション時に証明書のステータスを検証するOCSPレスポンスタイムの短い証明書を選択すれば、ネゴシエーションに要する時間を短縮することができます。
Webサーバー側の負荷軽減のより根本的な流れとして、 SPDY -> HTTP/2 への移行があります。
すでに、Apache、nginxがHTTP/2をサポートしています。デフォルトではないので利用設定を行う必要がありますが、困難ではありません。
また、IISでも、Windows10・Windows Server2016でHTTP/2が利用できます。
HTTP/2ではTLSの利用が標準で、HTTPSの表示が非常に早くなります。
主要なブラウザも、現在ではHTTP/2をサポートしています。
以下の「HTTP vs HTTPS Test」という、HTTP/2環境のHTTPSとHTTP/1.1環境のHTTPの表示速度を比較できるサイトにアクセスしてみてください。
HTTPの表示がHTTPSより8倍近くも時間を要していることが確認できます。
こうしたことから、全ページをHTTPSに移行するためのサーバーリソースコストは、今後減少傾向にあると思われます。
HTTPS接続では、Webサイトがユーザーがアクセスを希望している真正のサイトであることを証明するために、信頼されたroot証明書を持つ認証局（CA）が発行した証明書の利用が不可欠です。そのため、かっては認証局（CA）から証明書を購入することが必須でした。
しかし現在は、真正のサイトであることの証明をドメイン名だけに絞り込んだ（ドメイン認証：DV）証明書がLet’s Encryptから無料で取得できます。
Apacheやnginxで使う場合は、インストールまで行ってくれます。
非公式ですが、第三者が運営する日本語のポータルページもあります。
サーバ証明書が真正のサイトであることを証明する階層は、ドメイン認証（DV）＜ 組織認証（OV）＜ 拡張認証（EV）の三段階です。
企業の公式サイトや商用サイトであれば「組織認証」が、決済機能を持つサイトであれば「拡張認証」が望ましいとされていますが、個人サイトやブログ等では「ドメイン認証」の Let’s Encryptが広く使われています。
有料の証明書でも、DigiCertのWildCard Plusであれば「組織認証」であり、かつサブドメイン数無制限で利用できますので、大幅なコスト削減が可能です。
また、マルチドメイン証明書は複数のドメインの証明書をひとつにまとめることができるため、こちらもコストの削減ができます。
DigiCertのマルチドメイン証明書には、組織認証のマルチドメイン証明書と拡張認証のEVマルチドメインサーバ証明書があります。
Webサーバーが複数のドメインをホストする仕組みがバーチャルホストです。
※現在はv4 IPアドレスの枯渇により、名前ベースのバーチャルホストが標準的になっています。
従来は、IPアドレスとサーバ証明書は1対1の対応が必須でした。そのため、ひとつのIP上で複数のドメインを運用している場合、1ドメインだけしかHTTPSで運営することができず、 HTTPS運営のためにIPを追加するコストが発生していました。この現象の原因は、ブラウザがWebサーバーと接続するしくみによる制限でした。
ブラウザがWebサイトにアクセスする場合、DNSでサイトのIPアドレスを取得し接続を行います。
IPアドレスを持つサーバーへの接続が完了してからWebサーバーにHTTPヘッダーでドメイン名を提示し、コンテンツを提示してもらいます。
IPアドレスを持つWebサーバーに接続する段階でSSL/TLSハンドシェイクが行われます。
この段階では、Webサーバーはブラウザが接続を希望するホスト名がどれか知ることができないので、仮にWebサーバー上の複数のホストがそれぞれホスト名の証明書を持っていたとしても、正しい証明書を提示することはできません。SSL/TLSハンドシェイクでは提示された証明書にURLで指定されたホスト名が含まれている必要があるため、証明書エラーが発生していました。
この制限をクリアしたのが、Server Name Indication (SNI) です。
TLSに拡張機能を加えることで、IPアドレスを持つWebサーバーに接続する段階でブラウザが接続を希望するホスト名を伝えることができるようにしました。
これによって、Webサーバーはブラウザが接続を希望するホスト名の証明書を提示することができるようになりました。
SNI利用のためにはWebサーバーとブラウザの双方がSNIに対応している必要がありますが、現在一般に利用されているWebサーバーとブラウザのほとんどすべてがSNIに対応しています。
そのため、現在ではIPアドレスのコストの懸念なくHTTPSの実現が可能になっています。
・SSLサーバー証明書
・コードサイニング
その他証明書
・バウチャ(クーポン)
