常時SSL Lab.編集部［目次］
常時SSL化するWebサイトでは、各ページで使用されるすべてのリソース(画像やCSS、Javascriptやインラインフレームなど)もすべてHTTPSで配信する必要があります。
そのために、Webサイトを構成するHTMLやCSSなどのソースコードの記述を修正する必要があります。
本記事では、Webサイトの常時SSL化の際に必要なソースコードに対するさまざまな作業をご紹介します。
HTTPSで公開するデータを準備する
現在HTTPで公開しているすべてのデータのバックアップと、それをコピーして常時SSL化後にHTTPSで公開するための作業用データを準備しましょう。
筆者の経験で、常時SSL化後のWebサイトを公開する際には、HTTPのデータはそのままでHTTPSのデータを公開し、問題ないことが確認できればHTTP→HTTPSに301転送してHTTPのデータを削除する、というのが一番失敗が少ない作業方法だと思います。
最終的に301転送するまでHTTP/HTTPSの両方のデータを編集可能な状態にしておくと、臨機応変な対応が可能になります。
重複するデータの整理/統合
現在すでにWebサイトの一部をHTTPSで公開していると、HTTPとHTTPSのそれぞれドキュメントルートには、同じ画像やCSSファイルがそれぞれ設置されているなど、HTTPSで公開中のデータが存在していると思います。
常時SSL化後の運用を鑑みると、これらの重複するファイルはHTTPのデータをHTTPSにコピーするときにできるだけ整理/統合したほうがよいでしょう。
その際、整理/統合の前後で情報や要素の過不足がないか、ソースコードレベルでも確認が必要です。
HTTP用のCSSファイルに実施した更新をHTTPSに適用し忘れていたり、階層やファイル名の違いにより、ファイルを整理/統合したらWebサイトのレイアウトがガタガタになった、などは意外によくある失敗です。
複数のテキストファイルの差分を表示するソフトウェアなどを活用し、必要に応じて内容をマージしておきましょう。
HTMLやCSSの属性の修正
常時SSL化にあたって、Webサイト内部の画像やHTM/CSSLファイルへのリンクなど、ソースコードのレベルでは主に以下のようなタグの修正が必要になります。
- <a>タグの『href』属性 = リンク先の指定
- <link>タグの『href』属性 = スタイルシート(CSS)やファビコンの参照先
- <img>タグの『src』属性 = 画像の参照先
- <script>タグの『src』属性 = Javascriptの外部ファイルの参照先
- CSSの"background-image"の『url』 = 画像の参照先 など
これらの例にある『src』属性や『href』属性などのリンクやパスには、いくつかの記述方法があります。
現在の記述方法によって必要な作業が異なります。
※ リンクやパスの現在の記述方法によっては、修正が不要な場合もあります。
相対パスの場合
現在のファイルの位置を基準にしたパスの記述方法です。
参照するファイルの位置関係が変わらなければ、リンクやパスの修正は不要です。
|
1 2 |
<img src="../ディレクトリ名/ファイル名"> <a href="../ディレクトリ名/ファイル名"></a> |
サイトルート相対パスの場合
Webサイトのドキュメントルートの位置を基準にしたパスの記述方法です。
参照するファイルのドキュメントルートからの位置関係が変わらなければ、リンクやパスの修正は不要です。
|
1 2 |
<img src="/ディレクトリ名/ディレクトリ名/ファイル名"> <a href="/ディレクトリ名/ディレクトリ名/ファイル名"></a> |
絶対パスの場合
WebサイトのURLでページやファイルを指定して、情報の位置を確実に伝える記述方法です。
常時SSL化に伴って参照するURLが変わりますので、リンクやパスの修正が必要になります。
|
1 2 |
<img src="http://example.com/ディレクトリ名/ディレクトリ名/ファイル名"> <a href="http://example.com/ディレクトリ名/ディレクトリ名/ファイル名"></a> |
|
1 2 |
<img src="https://example.com/ディレクトリ名/ディレクトリ名/ファイル名"> <a href="https://example.com/ディレクトリ名/ディレクトリ名/ファイル名"></a> |
同じWebサイト内のリソースであれば、基本的に「相対パス」か「サイトルート相対パス」などに統一しておくと、ローカル環境やテストサーバーなどでテストする際も、画像やCSSの設置/読み込みなどのミスを発見しやすくなります。
修正漏れによりHTTPが混在したままで常時SSL化がうまくいかない、などといったトラブルも少なくなると思います。
プログラム内部のパスの修正
CGIなどのプログラムの内部には、同じサーバー内の他のファイルやライブラリを参照する際に、ドキュメントルートではなく、「/virtual/www/～」のようなサーバールートからのパスを記述することがあります。
このような記述がある場合は、常時SSL化後の構成に合わせて修正が必要です。
例えば、一部のレンタルサーバーでは常時SSL化を実施しようとるすと、データを設置するディレクトリが変わりますので、以下のように記述を修正します。
|
1 |
/virtual/www/～ |
|
1 |
/virtual/ssl/～ |
また、レンタルサーバーによってはPerlのパスの修正が必要になる可能性がありますので、技術仕様を必ず確認しましょう。
外部リソースのリンクやパスの修正
WebフォントやjQuery、YouTubeなど、外部のサーバーからリソースを読み込んでいる場合、配信元がHTTPSに対応しているか確認しましょう。
ソーシャル系のボタンやアフィリエイト、広告系のタグなど、外部サービスを利用している場合も同様です。
HTTPSに対応していなければ、必ず対応しているリソースに変更しなければ、常時SSL化が達成できません。
記述の修正
HTTPSに対応していれば、読み込みのパスなどの記述を必要に応じて書き換えます。
リソースの提供元でサンプルコードなどが提供されていると思いますが、おそらく以下のような形になっていると思います。
いずれの記述でも基本的には同じ挙動ですが、プロトコルに左右されない省略した記述の方が一般的になってきているようです。
[プロトコルを記述]
|
1 2 |
<link href="https://example.com/css/style.css" rel="stylesheet" /> <iframe src="https://www.youtube.com/～"></iframe> |
[プロトコルを省略した記述]
|
1 2 |
<link href="/rentalserver//example.com/css/style.css" rel="stylesheet" /> <iframe src="/rentalserver//www.youtube.com/～"></iframe> |
安全性の確認
読み込みの記述変更と合わせて、この機会に配信元の運営組織の安全性も必ず確認しておきましょう。
GoogleやMicrosoftなど、世界的に名前の知られた企業ならセキュリティも担保されて安全性は高いと思いますが、よくわからない配信元の場合は注意が必要です。
配信元の安全性が低いと、配信元がハッキングや悪用の被害に遭った場合に、それを読み込むWebサイトも巻き込まれ、結果的に閲覧者にまで被害が及ぶ恐れがあります。
また、配信元がHTTPSに対応して一見すると安全そうに見えても、運営組織に関係なく簡単に取得できるドメイン認証型のSSLサーバー証明書なら、必ずしも安全とはいえません。
WebサイトをEV SSLサーバー証明書で常時SSL化して安全性を謳っても、中で読み込むリソースが怪しい配信元だったら、何のための常時SSL化かわかりません。
常時SSL化を意味あるものにするために、細心の注意を払いましょう。
ページの軽量化
ソースコードの編集に合わせて、可能であればページの軽量化を検討するとよいと思います。
ご利用のレンタルサーバーがHTTPSの通信が高速になるHTTP/2に対応していなければ、Webサイトの表示スピードは常時SSL化により若干遅くなる可能性があります。
ほとんど体感できないレベルかもしれませんが、軽量化がデメリットになることはありませんので、不要な画像やJavascriptの削除などを実施して、できるだけ軽量化することをおすすめします。
なお、Googleでは、Webページの内容を解析して読み込み速度を測定し、読み込み速度向上のための提案をしてくれるツールもありますので、ぜひ利用してみてください。
PageSpeed Insights – Google Developers
この記事のポイント
- ソースコードレベルでHTTPとHTTPSの混在やパスの修正漏れが残らないように。
- 外部リソースは修正だけでなく安全性の再確認も。
- 軽量化によりユーザーに優しいサイトに。
株式会社IDCフロンティア
