r_nobuホームページ (のぶねこブログ)

当ブログのサイト全体をhttps化する対応を行ったので、以下に対応手順をメモとして残しておく。

レンタルサーバのXREAを利用している人でサイト全体のhttps化を検討する方法が分からなくて困っている人、Movable Typeのどこの設定を変更すればhttps化ができるのかが分からない人にとっては、参考になるのではないかと思う。
XREAもMovable Typeも使っていない人でも、Mixed Contentって何？どうすればいいの？と思っている人にとっても、参考になるところがあると思う。

サイト全体をhttps化（いわゆる常時SSL化）するには、主に2つの対応が必要である。

1.サーバの設定変更
2.htmlソースの修正

どちらを先に行うべきかについては、本来であれば後者の方かな、とは思ったけれど、私は前者の方から先に実施した。
理由は、仕事もプライベートも忙しくて、自分の個人的なブログサイトのhttps化対応にたっぷりと時間を費やせる余裕はなく、もうぶっつけ本番でさっさと終わらせればよい、と思ったからである。
とりあえず先にサーバの設定変更を行ってサイト全体をhttps化してしまい、https化したことで閲覧できなくなる不具合が発生したら、htmlソースを片っ端から修正すればよい、と考えた。

当ブログのサーバは、XREAのレンタルサーバを使用している。
2018年現在、XREAでは独自ドメインのSSL証明書を無料で使用できるため、SSL証明書の取得費・更新費が不要である。
年間のレンタルサーバ利用費用と独自ドメインの更新費用に加えて、年間何万円ものSSL証明書の維持費がかかるとなると費用的な負担が大きいと思って長年悩んでいたが、SSL証明書の費用がまったくかからないということを知ると、これまでの悩みが何だったんだろう、と思うぐらい拍子抜けをした。

XREAで無料のSSL証明書の導入をするのは、とても簡単であった。
サーバの技術的な詳しい知識はなくとも、XREAの管理画面（コントロールパネル）を触って適当に操作をしていくだけで、簡単にSSL証明書の設定を行うことができた。

1.サーバの設定変更手順は以下の通り。

1-1.XREAのコントロールパネルにログイン

XREAのコントロールパネルの「サイト設定」メニュー。

1-2.「サイト設定」メニューをクリックし、「サイト一覧」を表示する。

XREAのコントロールパネルの「サイト一覧」。

XREAのコントロールパネルの「サイト一覧」の「アクション」に並ぶボタン。

設定変更ができるボタン（ツールのアイコン）は、工具のような絵が描かれたボタン。

なお、既存サイトをhttpからhttpsに変更するため、「サイト設定の新規作成」ボタンはクリック不要。

XREAのコントロールパネルの「サイト設定の新規作成」ボタン。

この「サイト設定の新規作成」ボタンをクリックした場合、新規ドメイン・新サイトの設定となるため、このボタンではなく、既存のドメインのサイトの設定変更を行う。

1-3.設定変更用のアイコンボタンをクリックし、「サイト設定の変更」画面を開く。

XREAのコントロールパネルの「サイト設定の変更」画面。

1-4.「サイト設定の変更」画面で「無料SSL」を設定する。

XREAのコントロールパネルの「サイト設定の変更」画面にある「無料SSL」の選択オプション。

「SSL」設定のラジオボタンは「しない」にチェックが入っているので「無料SSL」にチェックを入れる。

XREAのコントロールパネルの「サイト設定の変更」画面にあるSSLの3つの選択肢から「無料SSL」を選択した画面。

XREAのコントロールパネルの「サイト設定の変更」画面の「サイト設定を変更する」ボタン。

「サイト設定を変更する」ボタンをクリックすると、無料SSLの設定が反映される。

XREAのコントロールパネルの「サイト一覧」に表示された「無料SSL」の記載。

このように「無料SSL」の表示がされる。

高額で有料のSSL証明書の場合、CSRの作成、証明書発行会社へのSSL証明書取得申請（更新）、秘密鍵と公開鍵の管理、サーバ設定変更、ファイアウォールの設定変更（httpプロトコル：80番ポートでの通信のみを許可している場合はhttpsプロトコル：443番ポートでの通信の許可設定）、SSL証明書の導入・設定を反映するためのウェブサービス（Apache等）の再起動が必要となってくるが、それらの作業は一切不要であった。
無料というだけでも嬉しいのに、このようにボタンを数回クリックするだけでSSL証明書の導入・設定が行えてしまうのは、とても簡単で便利である。

また、自分のサイトにhttp://でアクセスをすると、https://にリダイレクトされることも分かったので、XREAの無料SSLは、サイト全体のhttps化（常時SSL対応）にしっかりと対応したサービスであることが分かる。

1-5.ブラウザでSSL証明書の設定を確認する。

別に確認をしなくてもいいのかもしれないけれど、XREAの無料SSLでどのような証明書が設定されているかを確認して知っておきたかった。
どんなSSL証明書が使用されているかについては、ブラウザで簡単に確認できる。
IE11、Firefoxでも確認はできるけれど、Google Chromeで確認をした。

Google ChromeのSSL証明書画面「全般」タブ。

証明書の情報

この証明書の目的：
・リモートコンピューターのIDを保証する
・リモートコンピューターにIDを証明する
・2.23.140.1.2.1
・1.3.6.1.4.1.44947.1.1.1
*詳細は、証明機関のステートメントを参照してください。
発行先：　nobuneko.com
発行者：Let's Encrypt Authority X3
有効期間　2018/08/17から2018/11/5

Google ChromeのSSL証明書画面「詳細」タブ。

バージョン　V3

シリアル番号　04 7b 41 16 ba 9b 18 24 a3 3...
署名アルゴリズム　sha256RSA
署名ハッシュ アルゴリズム　sha256
発行者　Let's Encrypt Authority X3,Le...
有効期間の開始　2018年8月17日 22:25:03
有効期間の終了　2018年11月15日 22:25:03

Google ChromeのSSL証明書画面「証明のパス」タブ。

照明のパス(P)

DST Root CA X3

　Let's Encrypt Authority X3

　　nobuneko.com



証明書の状態(S)

この証明書は問題ありません。

SSL証明書の新規導入・設定、設定状況の確認は以上の通り。

2.htmlソースの修正の手順は以下の通り。

2-1.https化したサイトをブラウザで閲覧して問題個所を確認する。

Google Chromeアドレスバーをクリックすると表示される「このサイトへの接続は完全には保護されていません」のメッセージ。

このサイトへの接続は完全には保護されていません

このサイトでは機密情報（パスワード、クレジットカードなど）を入力しないでください。悪意のあるユーザーに情報が盗まれる恐れがあります。
証明書（有効）
Cookie（30個が使用中）
サイトの設定

Google Chromeのアドレスバーのセキュリティマークに付いた赤いバツ印。

Google Chromeの「設定」メニュー一覧。

「その他のツール」をクリックする。

Google Chromeのデベロッパーツール起動メニュー。

Google Chromeの開発者ツールであるデベロッパーツールをクリックして起動する。

Google Chromeのデベロッパーツール起動後の画面（11件のエラー、4件の警告）。

画面右上に赤いバツマーク、黄色いびっくりマークが表示されている。
赤いバツマークがエラー、黄色いびっくりマークが警告の意味のマーク。

Google Chromeのデベロッパーツールで確認できるMixed Contentの警告メッセージなど。

Mixed Content: The page at 'https://nobuneko.com/' was loaded .(index):55 over a secure connection, but contains a form that targets an insecure endpoint 'http://www.google.co.jp/custom'.This endpoint shoud be made available over a secure connection.

Mixed Content: The page at 'https://nobuneko.com/' was loaded .(index):58 over HTTPS, but requested an insecure image 'http://www.google.com/logos/Logo_25wht.gif'. This content should also be served over HTTPS.

Mixed Contentでhttp://パスのスタイルシートが読み込めないことでデザインが崩れたブログトップページ画面。

Google Chromeのデベロッパーツールで確認できるMixed Contentの警告メッセージとエラーメッセージ。

Mixed Content: The page at 'https://nobuneko.com/blog/' was loaded .(index):7 loaded over HTTPS, but requested an insecure stylesheet 'http://nobuneko.com/blog/styles.css'. This request has been blocked; the content must be served over HTTPS.

Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure image ''. This content should also be served over HTTPS.

Mixed Content: The page at 'https://nobuneko.com/blog/' was .(index):93 loaded over HTTPS, but requested an insecure image 'http://nobuneko.com/blog/archives/assets_c/2018/08/28D64720-1B02-43ED-B7D3-9870BF18AE64-thumb-480xauto-5824.jpeg'. This content should also be served over HTTPS.

主に、以下のパターンのエラー、警告が出ており、どのように対処すればよいかが分かった。

https化されたページ内に埋め込んでいるコンテンツがhttp://で呼び出されていると、httpとhttpsが混在するMixed Contentになるので、https://からの呼び出しに修正すればよい。

ページ内に埋め込まれるコンテンツとしては、主に以下の3つがある。

・画像
・スタイルシート
・ASPサービスで提供されるコンテンツ

2-1-1.ページ内埋め込み画像がMixed Contentエラーになる原因とエラー解消方法
ページ内の埋め込み画像が、Mixed Contentとなる場合、htmlソース上で以下のようにsrcで指定される画像のパスがhttp//になっていることが原因である。

＜img src="http://nobuneko.com/blog/archives/assets_c/2018/08/28D64720-1B02-43ED-B7D3-9870BF18AE64-thumb-480xauto-5824.jpeg" alt="アニメ「恋物語」の貝木泥舟の変顔を見つめる猫-ゆきお"＞

src="http://になっている記述を
src="https://に修正するだけで画像のMixed Contentのエラーは解消できる。

2-1-2.スタイルシートがMixed Contentエラーになる原因とエラー解消方法
スタイルシート（CSS）がMixed Contentとなる場合、htmlソース上で以下のようにhttp://からの呼び出しとなっていることが原因である。

CSSのパスがhttp://になっているhtmlソースの一部。

＜link rel="stylesheet" href="http://nobuneko.com/blog/styles.css"＞

href="http://になっている記述を
href="https://に修正するだけでスタイルシートのMixed Contentのエラーは解消できる。

2-1-3.ASPサービスがMixed Contentエラーになる原因とエラー解消方法

ASPサービスとは、自分のドメインのサイト内で作成・提供しているコンテンツではなく、Googleカスタム検索ボックスなど、外部サイトで提供されるコンテンツ・機能などを利用するサービスのことである。

https化された自ドメイン内のサイトにおいて、コンテンツをhttp://で呼び出すと、Mixed Contentエラーになるので、https://でコンテンツを呼び出す必要がある。
呼び出すコンテンツが外部サイトの場合、外部サイトがhttps://からの呼び出しに対応しているかどうかの確認が必要である。
どのような記述に変更すればよいかは、ASPサービスのコード発行画面やヘルプなどで確認する必要がある。
もし、ASPサービス側でhttp://での呼び出しに対応していない場合、Mixed Contentエラーを解消できない。
http://での呼び出しのみに対応し、
https://での呼出には非対応というASPサービスがもしあった場合は、そのようなASPサービスはセキュリティ面で不安であるし、今後の発展性に期待できそうもないので、利用を取りやめた方がよい。

2-2.Mixed Contentエラーを修正する。

当ブログサイトは、Six Apart社のMovable Typeでページの作成・更新を行っている。
Movable Typeを使って、http://の記述をhttps://に変更することができる。

Movable Typeにログインして作業をする。

サイト全体をhttps化すると、Movable Typeの画面もhttps化され、スタイルシートの読み込みに問題があったため、https化した「nobuneko.com」というドメインではMovable Typeの画面を操作するのが困難になってしまったことに気づいた。
これに気付いた時は、愕然としてしまい、https化を解除してhttpに戻してMovable Typeを操作しようかと考えていると、
「nobuneko.com」と同じページを参照しているサブドメイン
「www.nobuneko.com」があることを思い出した。
このサブドメインはまだhttps化をしていなかったので、このサブドメインでMovable Typeにログインするとレイアウト崩れもなく、Movable Typeを無事に操作できた。

2-2-1.Movable Typeの置換機能でブログ記事内のhttp://をhttps://に置換する。

Movable Typeの検索/置換画面（http://をhttps://に置換）。

記事だけでなく、ウェブページ、テンプレートも一括置換で修正する。

Movable Typeでの置換実行後のメッセージ。

この一括置換により、ブログ記事内で登録した何千枚もの画像のパスをhttp://からhttps://に修正できる。
これで画像のMixed Contentエラーは解消できる。

2-2-2.Movable Typeの設定をhttp://からhttps://に変更する。

Movable Typeの「ブログURL」の設定画面（編集中の画面）。

Movable Typeの「ブログURL」の設定画面。

ここはフォルダ名のみを修正できる画面であり、「http://」の部分は修正できない。
別に「ウェブサイトURL」の設定画面があるので、その画面で修正する。

Movable Typeの「ウェブサイトURL」の設定画面。

Movable Typeの「ウェブサイトURL」の設定画面（編集中の画面）。

これで、Movable Typeの画面上での設定は終了となる。
Movable TypeのCGIプログラムも修正をしておく。

CGIプログラムは、mt-config.cgiのみを修正した。
修正個所は以下の2点。

CGIPath http://nobuneko.com/blog/
　　　　　　↓ http://をhttps://に修正。
CGIPath https://nobuneko.com/blog/

StaticWebPath http://nobuneko.com/blog/mt-static
　　　　　　　　　↓ http://をhttps://に修正。
StaticWebPath https://nobuneko.com/blog/mt-static

※Movable Typeの場合、記事のhtmlページがそれぞれ静的なコンテンツとなっているので、以上の作業終了後、再構築ボタンをクリックして既存のhtmlページを全て更新する必要がある。

2-2-3.ASPサービスの設定をhttp://からhttps://に変更する。

サイトのアクセス解析用にGoogle Analyticsを使っているのでGoogle Analyticsの設定を変更した。

Google AnalyticsのデフォルトのURL設定画面。

ここでhttps://を選択した。

また、今回のサイト全体のhttps化の影響かどうかは分からなかったけれど、Google Chromeのデベロッパーツールで、Google Analyticsで以下のエラーが出いていることにも気付いた。

index.html:41 A parser-blocking, cross site (i.e. different eTLD+1) script, https://ssl.google-analytics.com/ga.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.

これの対処方法がさっぱり分からなかったので、Google Analyticsの最新のコードを取得し、最新のコードを埋め込んだところ、エラーが発生しなくなった。

その他、ASPサービスとしては以下を利用しているので、以下の設定をhttps://用に変更した。

・Google Search Console
・にほんブログ村

Search Consoleの場合、Search Console画面内で[プロパティを追加]ボタンをクリックして、http://の既存のプロパティとは別にhttps://で新規のプロパティを作成する必要があり、やや面倒であった。

Google Search Consoleのホーム画面に並ぶhttp://とhttps://のプロパティ。

3.動作確認をする

サイト全体のhttps化がうまくいったかどうかを動作確認する。
動作確認としては、Google Chromeで1ページずつ見ていき、ページのレイアウトが崩れていないこと、Mixed Contentのエラーが表示されないことを確認した。

常時SSL化対応完了後のブログトップページ画面（Google Chromeデベロッパーツールでの警告・エラーなし）。

何1つエラーが出ず、レイアウト崩れも起きていないことを確認できると安心だ。

これらの作業後、約2週間が経過したが、特に問題は起きていない。
サイト全体のSSL化（常時SSL化）に要した時間は、途中で寝てしまったので正確な時間は分からないけれど、どうしたらよいのかが分からなくてハマってしまった時間を入れても3時間程度だった。

まだサイト全体のSSL化が終わっていない人は、できる限り早急に対応をした方がよいと思う。
私のようにXREAを利用している人は、独自ドメインであっても無料でSSLを利用できるから、お金の負担が増えることを気にする必要もないので、何とかして作業時間を確保して、さっさと対応をしておいた方がよい。

他社のレンタルサーバを使っている人で、費用面を考えて無料のSSLを利用したいという目的で他社のレンタルサーバからXREAに引っ越すのもよいかもしれない。
（もし引っ越しをする場合は、Movable Type等のプログラムが動作しなくなる可能性もあるので、サーバ要件等はよく確認した上で引っ越しをした方がよい。）

《広告》無料から使える高機能・高品質レンタルサーバー XREA（エクスリア）