常時SSL化について

Webサイトの一部のみをHTTPS化するのではなく、Webサイト全体をHTTPS化することは常時SSL化（常時HTTPS化）と呼ばれています。
従来はログインページやクレジットカード決済ページなど、Webサイト上でパスワードや個人情報等を入力するページのみをHTTPS化して通信を保護することが一般的でした。
しかし近年、インターネットにおけるセキュリティ意識の高まりやGoogle Chromeなどの主要なブラウザーでの対応を受け、Webサイト全体をHTTPS化することが求められています。

このページでは、常時SSL化のメリットや対応までの流れ、押さえておきたい注意点などについて解説します。

Webサイトを常時SSL化することにより、Webサイトのセキュリティ向上（なりすましや盗聴の防止など）やアクセス解析の精度向上（解析ツールへのリファラ情報の引き渡しなど）などの効果が見込めます。

HTTPS化されたWebサイトではブラウザーのアドレスバーに鍵（南京錠）マークを表示されるため、Webサイト訪問者に見た目で安心感を与えることができるというメリットもあります。

Webサイトの高速化

また、通信が効率化され、Webサイトの表示を高速化する次世代プロトコル「HTTP/2」を利用するには、HTTPSで通信することが事実上必須となっています。かつては、Webページをhttpsにすることは、Webサーバー、ブラウザー両方に負荷がかかり、表示が遅くなることもありましたが、HTTP/2が登場したことにより、HTTPS化、常時SSL化はWebサイトの表示を高速化させる要素となりました。

常時SSL化は、Webサイト訪問者に安心してWebサイトを見てもらうために重要なことであり、昨今のWebサイト運用において非常に重要となっています。

大手サイトや政府系サイトの対応

GoogleやYahoo!JAPANといった検索ポータルサイト、TwitterやFacebook、InstagramといったSNSもユーザー保護の観点から常時SSL化されています。
日本の政府機関においても、情報セキュリティ対策を規定する「統一基準」の見直しが進んでおり、政府機関の全Webサイトの常時SSL化が義務化される見通しです。（2018年5月時点）

これらのことからもわかる通り、Webサイトの運営者・訪問者の双方にメリットをもたらす常時SSL化は、インターネット全体のトレンドになっているといえます。

「http」のままでは警告表示も

主要なWebブラウザーでは、「http」のWebサイトを表示する際、アドレスバーに警告が表示されることがあります。 「http」のWebサイトにアクセスした際、アドレスバーにGoogle Chrome 68以降では「保護されていない通信」、Safari 12.1以降では「安全ではありません」と表示されます。Webサイト訪問者に不安を与える警告を表示させないためにも、Webサイト全体をHTTPS化する常時SSL化が必要です。

CSRの作成方法はコチラ

JPRSサーバー証明書を取り扱っている指定事業者はコチラ

JPRSサーバー証明書の認証方法はコチラ

サーバー証明書のインストール手順はコチラ

サーバー証明書には、DV（ドメイン認証型）、OV（組織認証型）、EVの3種類があります。

これらは機能（通信の暗号化）の点ではいずれも同じで、認証の対象（何を認証しているか）が異なります。DVはドメイン名の管理権限のみを認証し、OV、EVはドメイン名の管理権限に加え、組織の法的実在性も認証します（ワイルドカードやマルチドメインでも常時SSLに対応可能な、JPRSサーバー証明書の種類についてはコチラ）。

常時SSL化の最大の理由は通信の暗号化であり、いずれの証明書もその条件を満たしています。

常時SSL化したのにアドレスバーに鍵（南京錠）マークが表示されないページがある場合

HTMLソースの中に「http」で記述されたリンクが残っている「mixed content」という状態になっている可能性があります。

常時SSL化した場合、URLはhttpsから始まるものに変更となります。そのため、HTMLファイル内の内部リンクやサイトマップに記載しているURLをすべてhttpsから始まるものに書き換える必要があります。特にimgタグや、cssを読み込むリンク先などでhttpから始まる絶対パスを使用し、一つのページ内でhttpsとhttpが混在する状態となった場合、「mixed content」という状態となり、ブラウザーによっては鍵マークが表示されなかったり、警告が表示され利用者の混乱につながることがあります。

mixed contentを避けるために、内部リンクのURLを

• 一律「https://」から始まる絶対パスに書き換える
• 絶対パスではなく、相対パス（もしくはルート相対パス）で記述する

のどちらかを行う必要があります。

なお、外部リンクに関しては、httpのURLで記載していても、mixed contentとなることはありませんが、スタイルシートや画像を外部から読み込んでおり、そのURLがhttpの場合はmixed contentとなってしまいます。読込先がhttpsに対応していればhttpsに書き換え、非対応の場合には外部からの読み込みを中止するなどの対策が必要です。特に動画や広告バナーなどがhttpのURLで記載してないか、注意してください。

ブラウザーに搭載された開発者向けのツールを用いることで、ソースコード上でmixed contentの原因となっている箇所を特定することができます。

httpから始まるURLのケア

「https://example.jp」と「http://example.jp」の二つのURLはよく似ていますが、インターネット上では別のURLとして扱われます。外部のWebサイトに記載されたリンクのURLがhttpから始まるURLの場合、常時SSL化しURLがhttpsに変わった際にリンク元からアクセスできなくなるため、httpで運用されているURLのケアが必要となります。
主な対策として、httpsのWebサイトへのリダイレクトを設定することが挙げられます。

リダイレクトの対応

httpのWebサイト「http://example.jp/」にアクセスがあってもエラーにならないように、httpsのWebサイト「https://example.jp/」へのリダイレクトを設定しておきましょう。これまで公開していたhttpのWebサイトを急に閉鎖してしまうと、他のWebサイトからのリンクが切れたり、Webブラウザーのブックマークからアクセスができなくなったりしてしまいます。

ただし、前述した「mixed content」を一度に修正することが難しい、利用者への周知期間を設けたいといった事情がある場合、httpとhttps双方のWebサイトを一定期間並行運用する方法が考えられます。並行運用期間中にmixed contentの修正やアクセスログにエラーがないことを確認し、その後にhttpsへのリダイレクトを設定することで、利用者の混乱を避ける形でhttpsへの移行を進めることができます。

外部連携サービスの設定変更

アクセス解析ツールや、サイト内検索などで外部連携サービスを利用している場合、登録しているURLをhttpで始まるものから、httpsで始まるURLに変更する必要がある場合があります。

サブドメインで運用しているページが多数ある場合

HTTPS化のためには、ホスト名単位でサーバー証明書を設定する必要があります。そのため、複数のサブドメインで運用しているWebサイトを常時SSL化する場合、それらを1枚のサーバー証明書でカバーできるワイルドカード証明書がお勧めです。

HTTP Strict Transport Security（HSTS）への対応

HSTSは、利用者が常時SSL化されたWebサイトにHTTPでアクセスしてしまうことを、できるだけ減らすための仕組みです。

HSTSが設定されたWebサイトに利用者がアクセスすると、そのWebサイトへの次回以降のアクセスにはhttpsのみを使うように、Webブラウザーに通知されます。これにより、次回からは利用者がそのサイトにhttpでアクセスしても、Webブラウザーがhttpsのアクセスに自動変換します。

HSTSに対応する場合、httpからhttpsへのリダイレクトを事前に設定しておく必要があります。また、サブドメインでhttpのWebサイトを運用している場合、それを考慮せずにHSTSを設定してしまうと、そのページにアクセスできなくなってしまう可能性がありますので、注意が必要です。

なお、HSTSにはWebサイトがhttpsのみであることを事前設定しておく、HSTS Pre-Loaded Listという仕組みもあります。この場合、この情報がWebブラウザーに埋め込まれ、1度目のアクセスからhttpsのみが使われるようになります。

また、一度HSTSを設定した場合、何らかの問題が発生してもhttpのサイトに切り戻すことは困難です。そのため、HSTSの設定は慎重に行う必要があります。