CDNでWordPressを安全にHTTPS化する方法

今回は、CDNでWordPressを安全にHTTPS（SSL）化する方法をご紹介します。

通常のWEBサーバーのみの環境ではそれほど難しくないHTTPS化もCDNやロードバランサー（ELB等）と連携して利用しようとすると、リダイレクトループなどでトラブルになる可能性があるため、この機会にポイントを押えておきましょう。

HTTPS（SSL）するパターン

新規サイト立ち上げ時にHTTPSにする場合

開発段階でこれからWordPressでコンテンツ作成していく！という場合WEBサーバー側の設定とWordPress側のURLの設定を正しく行えば問題ありません。

WEBサーバー側のSSL設定

まずはWEBサーバー（ApacheやNginx）でSSLの設定を行う必要があります。SSL証明書と秘密鍵をApacheやNginxのコンフィグで適切に読み込めるように設定しましょう。
Root権限がないホスティングサーバーを利用している場合は、各事業者のコントロールパネルからSSLを有効にする設定を行って下さい。

WordPress側のSSL設定

WordPressのインストール時、サイトのアドレスをhttps://～始まるURLを入力しましょう。

インストール後念のため「一般設定」にある以下の項目がhttps://～始まっているか確認しましょう。

既存サイトをHTTPからHTTPSにする場合

おそらくこちらのケースのほうが多いかもしれません。既にサイトをHTTPで公開しており、記事やコンテンツがある状態でHTTPS化する場合です。新規構築時と異なり既に公開しているコンテンツの変換という作業とWordPressの設定変更が追加で発生します。

新規構築時と同様、WEBサーバー（ApacheやNginx）で適切にSSLの設定を行います。WEBサーバー側のSSL設定が完了したら、DB内に保存されているコンテンツの中身を変換する作業に移ります。

既存コンテンツの書き換え

WordPressは絶対パス（FullPath）で画像や記事へのリンクを保存します。そのため、サーバー自身をHTTPS化してもHTTPサイトで運営していた時に作成した固定ページや投稿内のリンクは全てhttp://～始まるURLとなっています。このままですと、Chromeなどのブラウザで開いたときに、Mixed Content:という警告（※HTTPとHTTPSの通信が混在しているという意味）が表示されてしまうため、http://から始まる文字をhttps://に置換しなければ行けません。

Search Regexプラグイン

SQL文をガリガリ発行してもいいのですが、今回はWordPressの管理画面から行えるようにするプラグインSearch Regexをつかった方法をご紹介します。※本プラグインはDB内のコンテンツを書き換えますので、念のためBackWPup プラグインなどを利用してDBのバックアップを実施してください。

Search Regexプラグインの導入

まずは、WordPressのプラグイン追加から、Search Regexを検索し、インストール後有効化します。有効化が完了したら、WordPress管理画面からツール→Search Regexをクリックし設定画面を表示します。

Search Regexでコンテンツの書き換え（http:// からhttps://）

Search Regexの設定画面を開いたら以下の様に置換前の文字列、置換後の文字列を入力し、Replaceボタンを押します。

• Search Patternにhttp://サイトドメイン名（HTTPS化前のサイトURL）
• Replace Patternにhttps://サイトドメイン名（HTTPS化後のサイトURL）
• Source：Post content（デフォルト）
• Limit to：No limit（デフォルト）
• Order By：Ascending（デフォルト）
• Regex：今回は文字列を完全一致指定しているため選択不要

Replaceボタンを押すと、文字列置き換え前と後の文字列が列挙されますので念のため問題が無いかいくつか確認しましょう。

HTTPからHTTPSに文字列置換した結果をDBに保存するには、「Replace ＆ Save」ボタンをクリックしてください。

これでWordPress内のhttp://から始るリンクはhttps://に変換されました。

WordPressの設定からサイトURLを変更

WordPress「一般設定」にあるWordPressアドレスとサイトアドレスの項目で、http://～始まっているURLをhttps://に変更します。

これらの設定で、HTTPサイトをHTTPSにすることが出来ました。新規構築時と比べると既存コンテンツがある分作業が多くなっています。

httpからhttpsへリダイレクト正規化

HTTPS化を無事行う事が出来たら、次はHTTPからHTTPSにリダイレクトするようURLの正規化を行います。リダイレクト(Apacheの場合).htaccess等に記載する項目は以下の通りです。こちらはHTTPS通信ではなかった場合、HTTPSに301リダイレクトするという単純な記述になります。

HTTPからHTTPSへのリダイレクト（Apache）

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

HTTPからHTTPSへのリダイレクト（Nginx）

server {
listen 80;
server_name ドメイン名;
return 301 https://$host$request_uri;
}

※IF分などを書かないシンプルな記述がお勧めです。

CDNまたはロードバランサー経由のHTTPS化

さて、ここからが実は本題です。先ほどのように、WEBサーバーだけで稼働しているWordPressのHTTPS化は手順さえおさえておけば問題無く出来ると思います。

しかし、WEBサーバーの全段に以下の様なサービスがある場合、注意しなければサイトが見られなくなったりリダイレクトループになる場合があります。

• 負荷分散の目的でNginxなどのリバースプロキシを利用している。
• CDNサービス（エッジキャッシュ,CloudFront,Fastlyなど）を利用している。
• AWSなどのロードバランサー（ELB・ALB）配下にWordPressサイトがある。

HTTPS化でリダイレクトループ

主なCDNサービスやELB等のロードバランサーはフロント側をHTTPSの終端とし、そのリクエストをWordPressにHTTPで送信します。
そのため、WEBサーバーから見るとブラウザでHTTPSでアクセスしていたとしても、HTTPでアクセスしている状態に変換されてしまいます。こちらが原因で、WordPress側で適切な設定をしなければリダイレクトループとなってしまう場合があります。

HTTPからHTTPSへのリダイレクト判定変更

先ほどご紹介した.htaccessのリダイレクトはプロトコルがHTTPなのかそれともHTTPSなのかを単純に判別しているだけです。
そのため、WEBサーバーの全段にCDNやロードバランサーなどが入っていると以下の様なリクエストになり、結果リダイレクトループが起こってしまいます。

1. ブラウザ：HTTP://でアクセス
2. CDNまたはLBはhttpでブラウザからの通信を受信し、WordPressにそのままhttpで通信します。
3. WordPress側のWEBサーバーでHTTPアクセスをHTTPSに301リダイレクトします。★
4. ブラウザはHTTPSにリダイレクトされたことを検知し、再度HTTPSでサイトにアクセスします。
5. CDNまたはLBはHTTPSでブラウザからの通信を受信し、WordPressへHTTPに変換して通信します。
   その後は、★印に戻りループが繰り返されてしまいます。

これらを回避するためには、CDNまたはロードバランサーからのアクセスなのか、それともブラウザからのアクセスなのかをWEBサーバー側で検知し、CDNまたはロードバランサーからのアクセスだった場合は、HTTPSにリダイレクトしないという判定を行う必要があります。

CDN経由またはロードバランサからのアクセス判定

CDNやロードバランサーは、ブラウザからのアクセスがHTTPなのかそれともHTTPSなのかを、配下（バックエンド）のサーバーやプログラムが認識できるよう、X-Forwarded-ProtoというHTTPヘッダを付け加えてその中に情報を格納していることが多いです。

そのため、CDNまたはロードバランサーを経由したHTTPS配信で、且つ正規化リダイレクトをWEBサーバーで行っている場合は、X-Forwarded-Protoヘッダの中身を確認し、HTTPだった場合だけHTTPSにリダイレクトするというように記載します。

CDNを利用したリダイレクト（Apache）

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R,L]
</IfModule>

CDNを利用したリダイレクト（Nginx）

server {
listen 80;
server_name ドメイン名;

#X_forwarded_proto判定
if ($http_x_forwarded_proto != https) {
return 301 https://$host$request_uri;
}
}

このようにすると、先ほどの例では以下の様なフローになります。

1. ブラウザ：HTTP://でアクセス
2. CDNまたはLBはhttpでブラウザからの通信を受信し、X-Forwarded-Protoヘッダを付与してWordPressにそのままhttpで通信します
3. WEBサーバーはX-Forwarded-Protoヘッダの中身がHTTPのため、HTTPSに301リダイレクトします。
4. ブラウザはHTTPSにリダイレクトされたことを検知し、再度HTTPSでサイトにアクセスします。
5. CDNまたはLBはHTTPSでブラウザからの通信を受信し、X-Forwarded-ProtoヘッダにHTTPSをつけてWordPressに通信します。
6. WEBサーバーはX-Forwarded-Protoヘッダの中身がHTTPSのため、リダイレクトせずにそのまま通信をブラウザに返します。

WordPress管理画面で強制SSLをONにしている場合

WordPressの設定で強制SSLをON(wp-config.phpで define(‘FORCE_SSL_ADMIN’, true);  と設定）にしている場合、WordPress側でも先ほどのX-Forwarded-Protoヘッダを判別させなければいけません。

X-Forwarded-Protoヘッダを正しくWordPressで認識できるように、以下の様にwp-config.phpを修正する必要があります。

if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) {
$_SERVER['HTTPS']='on';
}

HTTPS化(SSL)を行った後の効果測定

さて、WordPressをHTTPS化した後、https://でWordPressにアクセスできれば完了というわけではありません。
SSLにはネゴシエーション時のバージョンや仕組みなど細かいチューニングが必要で、これらを適切に設定しなければWEBサイトのレスポンスに影響を及ぼす場合があります。そのため、HTTPS化したWordPressについてもしっかりSSL通信の設定が問題無いか今一度効果測定を行いましょう。効果測定を行えるツールやWEBサイトは様々ですが、特に細かく調査してくれるサイトをご紹介します。

SSL labsについて

SSL labsは、様々なSSL設定についてかなり細かくスキャンしてくれます。

WEBサイトのSSL評価を確認するには、こちらのサイトでSSL化した後のドメイン名を入力し、SUBMITボタンを押しましょう。
しばらくするとサイトのスキャンが始まります。
※Do not show the results on the boardsにチェックを入れておくと、スキャンしたURLの一覧に乗せないことができます。

SSLランク・スキャン結果

スキャン完了までしばらく時間がかかりますが、以下のような結果が表示されます。ランクは高い順にA+  A-  A-FまでありますがA+の最高ランクを取得するのは色々と試行錯誤しなければいけません。またどのような項目に問題があったのかは、ページの下のほうに細かく掲載されています。

無料でSSL化できるCDNサービス

SSL化を行った後、ROOT権限があるVPSやAWSなどのサーバーはApacheやNginxのSSL設定（Cipher  suite）を調整し、SSLスコアが高い状況になるようにすることが望ましいです。SSL通信は以下のように様々なやり取りを行います。

SSLネゴシエーションフロー

そのため、サーバー側で本来不要なネゴシエーションまで利用できるようにしてしまうと、サーバーの負荷が通常より高くなりますし、SSLのスコアも結果的に下がってしまいます。結局はクライアントからのネゴシエーション時なにをサーバー側で使わせるかという線引きが必要なのですが、多ければいいというものではなくベストプラクティスを見つけるのは至難の業です。（あるバージョンのブラウザだけ通信できなくなっていた。なんてこともあり得ます。）

さらに、そもそも共有サーバーでROOT権限がないWEBサーバーはこれらの細かい値を調整することが出来ません。この辺を解決するためには、やはりAWSに代表されるロードバランサーやCDNサービスなどを別途契約し料金を払うしかありません。

Rapid START（CDNサービス）

弊社は、無料で利用できるCDNサービス「Rapid START」を今年6月にリリースし、いくつかのアップデートを経て現在はHTTPSも無料で対応しました。(もちろんHTTP/2プロトコルにも対応)
Rapid STARTを利用することによって、前段のCDNでSSL通信を行いながら、画像などの静的コンテンツも国内サーバーからキャッシュ配信しWEBサーバーの負荷を下げることが可能です。※こちらを行う場合は本投稿に掲載している「CDN経由またはロードバランサからのアクセス判定」の部分を参考にしてください。

登録方法

Rapid STARTでドメイン登録後、ドメイン所有権の確認のためいくつかのステップを行ったあと、SSL証明書を管理画面から登録することができます。サイトをCDN経由に切り替えるためには、Rapid START専用のサブドメインにCNAMEレコードを設定するだけの簡単設定です。これで、小規模サイトであればHTTPS化と負荷分散を同時に行うことができます。WordPress専用設定をプリセットに用意しているため、プラグインの導入や細かいカスタマイズを行う事無く安全にキャッシュ配信することができます。

よくわからない場合はFacebookからのみとなりますが、チャット形式で導入サポートを受け付けております。

まとめ

今回は、WordPressをSSL化する上でのポイントを掲載しました。一般的なSSL化の設定は様々なブログや記事で紹介されているとおもいますが、CDNやロードバランサーを経由した構成になるといっきに敷居が高くなります。

ほとんどのケースでは、管理画面だけリダイレクトループ、MixedContentエラーになることが多いですが、既存のリダイレクト設定が問題なのかそれともWordPress側の設定なのか、もしくはCDNやロードバランサーの設定ミスなのか初めての場合は判断が難しいと思います。しかし、正しく仕組みを理解していれば適切な対処ができますし、WEBサーバーも高速になりメンテナンスや運用もラクになります。

是非WordPressのSSL化を行ってみてください！