第2回 HTTPSの詳細：超入門HTTPS（2/2 ページ）

[打越浩幸，デジタルアドバンテージ]

SSL／TLS初期化後の通信

　以上のようにしてSSL／TLSの通信路が確立できれば、後はその通信路上でHTTPプロトコルを使った通信を行えばよい。この部分はHTTPでもHTTPSでも変わらない。Webブラウザのデバッグ機能を使えば、HTTPS通信であってもメソッドやその内容を確認できる。

HTTPSでの通信例
HTTPSであっても、上位のプロトコルは暗号化されていない場合のHTTPプロトコルと同じである。開発者ツールを使えばその通信内容を確認できる。
　 （1）Windows 10のMicrosoft Edgeでhttps://〜を使ってアクセスしてみる。
　 （2）開発者ツールで［ネットワーク］を選択する。
　 （3）HTTPSとなっている（実際にはTLS 1.2上でHTTP 1.1プロトコルが使われている）。
　 （4）GETやPOSTなどのメソッドが使われているのはHTTPの場合と同じ。

サーバ証明書

　HTTPSではWebサーバにセットされている「サーバ証明書」が重要な役割を持つ。暗号化の鍵として利用されるだけでなく、そのWebサーバがある特定のドメインに属している正当なシステムであることを保証したり、ユーザーに対して、そのドメインが正規の組織が管理しているドメインであることを表明したりするからだ。サーバ証明書にはWebサーバの所有者の情報や公開鍵暗号システムで利用される公開鍵などが含まれ、それが発行者によって電子署名されている。

●サーバ証明書の種類

　Webサーバにセットする証明書には次のように幾つかの種類がある。

種別	内容
DV（Domain Validation） ドメイン認証型証明書	一番手軽なサーバ証明書。ドメインの正当な所有者であれば、メールなどで申し込み可能（物理的な個人／組織／団体として存在していなくてもよい）。比較的低コスト。無料のものもある
OV（Organization Validation） 実在認証型証明書	ドメインの所有者の組織や団体が実際に存在することを確認して保証する証明書。他人がある組織を偽って証明書を取得する、といった不正はできない （脆弱性や手続きのミスを除く）
EV（Extended Validation） 拡張実在認証型証明書	一番厳格な証明書。組織（会社など）が確実に存在し、社会的にもある程度の期間継続していて、さらに担当者なども実際に存在することが確認されるなど、かなり厳格な存在チェックが行われる。存在チェックが厳しくコストも高いが信頼性は一番高い
Webサーバ証明書の種類

　DVからOV、EVとなるにつれて所有者の存在確認などが厳しくなり、その分証明書としての信頼性が高くなるが、コストも上昇する。

　もっとも、Let's Encryptのような無料の証明書サービスもあるので（次のリンク参照）、以前よりもHTTPS導入のためのハードルは低くなってきているのも事実である。

• Tech Basics「無料のHTTPS用証明書サービスLet's Encrypt」

　以上のいずれかの証明書が使われていれば、Webブラウザのアドレスバーに暗号化を表す鍵マークなどが表示される。特にEV証明書の場合は、組織名が（ほとんどのブラウザでは）緑色で大きく表示されるなど、より特別に正当な組織であることが分かるようになっている。

サーバ証明書の種類の違いによる表示の違い
証明書の種類によって表示方法が異なる。これはWindows 10のMicrosoft Edgeの例。
　 （1）OVやDV証明書の場合はこのようなシンプルな鍵マークの表示になる。
　 （2）EV証明書の場合は組織名などが緑色で表示され、より信頼できるサイトであることが分かる。大手企業や金融機関などでの採用が多い。

　証明書の詳細は次の通りである。

証明書の例
上記のサイトのWebサーバ証明書の詳細を表示させたところ（Internet Explorerによる表示）。
　 （1）証明書の発行者（証明機関）。
　 （2）「サブジェクト」は発行された証明書の対象を表す。
　 （3）証明書の署名などで使われているアルゴリズム。以前はSHA-1も使われていたが、脆弱性が見つかったので現在ではもう使われない。利用できるアルゴリズムなどの仕様は、SSL／TLSのバージョンや実装などによって変わっている。いつまでも古い証明書や実装を使い続けるのは危険である。
　 （4）証明書の発行対象のドメイン名（FQDN名）。この名前が正しく存在することを証明している。
　 （5）証明書の発行対象の組織情報（もしくは証明書販売業者の情報など）。

●サーバ証明書に使われているアルゴリズムに注意

　サーバ証明書ではデータを符号化するためにさまざまな数学的アルゴリズムを利用できる。それらのうち、SHA-1を使った証明書は安全性が低いため（SHA-1の脆弱性が見つかったため）、現在では非推奨となっている。SHA-1を使った証明書（や、自己発行の、いわゆるオレオレ証明書）をインストールしてあるWebサイトへ接続するとWebブラウザが警告メッセージを表示するようになっている。

WebサイトのHTTPS化

　現在HTTP（だけ）で運用しているWebサーバを全面的にHTTPS化（常時HTTPS化）する場合、サーバ証明書を導入してWebサーバの設定を変更するだけでは済まない。

　さまざまなリソースをHTTPS経由でもアクセスできるように更新する他、今までHTTPでアクセスされてきた外部公開URLなどをHTTPSでのアクセスに切り替えさせる（リダイレクトする）対策も必要である。これを行わないと、今までブックマークされたり、告知していたりしたリンク情報（例：「http://〜」など）が急に全て無効になってしまうからだ。

　HTTPS化する方法を全て説明するのは本記事の趣旨からは外れるので、ここでは主な作業項目だけを列挙しておく。

• サーバ証明書を用意して、HTTPだけでなく、HTTPS（SSL／TLS）でのアクセス「も」受け付けるように、WebサーバやWebサイト（ファイアウォール、負荷分散装置、なども含む）の設定を変更する
• HTTPSでのアクセスをHTTPに中継するようなリバースプロキシを使って、サイト全体をHTTPS化するという方法もある（Tech Basics「リバースプロキシ」参照）
• サイト内の全てのリソース（画像やスクリプト、CSS、他）へHTTPSでアクセスできるように、設定やコンテンツを直す
• 内部リンク（サイト内で利用しているリンクなど）をHTTPSのページを指すように変更する。一部のリソース（例：*.gifや*.jsなど）へのアクセスがhttp://〜のまま残って混在していると、アプリやブラウザでエラーになることが少なくない
• HTTP（http://〜）でアクセスされた場合は、HTTPSへのリンク（htts://〜）へリダイレクトさせるように設定する
• sitemap.xmlなどの検索エンジンbot制御用のファイルも設定を変更する
• Google Search ConsoleやGoogle Analyticsといった分析ツールにHTTPSのサイトの設定を加える

---

　本記事ではHTTPSプロトコルについて簡単にまとめてみた。WebサイトのHTTPS化／常時SSL化には、通信内容の暗号化による情報漏洩の防止だけでなく、SEO対策やサイトの高速化など、さまざまなメリットがある。まだ移行していないなら、ぜひ移行・導入を検討するべきだろう。