CLOUD FLARE + WordPress + 共用サーバーでサイトが崩壊したときの処方箋

こんばんは、Webプログラマの篠田です。

2016年も残すところ1ヶ月を切り、街が徐々にクリスマスの様相を呈してきましたね。

本日は、WordPress + 共用サーバー+ CLOUD FLAREで常時SSL化にするための注意点に関してご紹介したいと思います

何も知らずに流行りに乗ると、サイトがひどいことになりますのでご注意下さい。

想定する環境

■WordPress
こちらのバージョンは「4.6.1（2016.12.02時点での最新）」になります。

■共用サーバー
共用サーバーは、「さくらサーバー」でも「ロリポップ」でも「heteml（ヘテムル）」でもなんでもOKです。
ポイントは独自SSLを契約していないという点です。

■CLOUD FLARE（クラウドフレア）
CDNサービスもいろいろありますが、無料で多くの方が利用しそうな「CLOUD FLARE」を想定します。

CLOUD FLAREの設定に関して

今回はCLOUDFLAREの設定方法は割愛させていただきます。

別の機会に設定方法をまとめたいと思っています。

設定を普通にしてしまうとどうなるのか

CLOUD FLAREを利用して常時SSL化をするというのはGoogle先生の影響もあり多くのサイトで実践されています。
もちろん、WordPressを利用しているサービスもCLOUD FLAREを利用して高速化や常時SSL化を実践されている方もいます。

ですが、それと同時によく目にするのが、今回のお題と同じ「WordPress + CLOUDFLAREでぶっ壊れた」といった嘆きも目にします。

原因は、「WordPress + CLOUDFLARE」ではなく「WordPress + CLOUDFLARE + 共用サーバー」もしくは、「WordPress + CLOUDFLARE + 非SSL環境」が原因で発生している問題です。

CLOUDFLAREのSSLの仕様

まずは、CLOUDFLAREが提供しているSSLの仕様に関して確認しておきたいと思います。

Full

CLOUDFLAREとサーバー、及びクライアント（ユーザー）すべての通信がSSL化される設定です。
セキュリティ的に堅牢で安心して利用できる設定ですが、条件としてサーバー側に自己証明書（通称：オレオレ証明書）でもいいので設定がされていることが条件になります。

Full(static)

これも基本は「Full」と同じで、CLOUDFLAREとサーバー、及びクライアント（ユーザー）すべての通信がSSL化される設定になります。
違いは、サーバー側にあるSSL証明書が外部機関が発行している、ちゃんとしたSSL証明書である必要がある点です。

Flexible

これが本日の本命「Flexible SSL」設定です。
これは通常のSSL証明書と違い、CLOUDFLAREとクライアント（ユーザー）間の通信はSSL化してくれますが、CLOUDFLAREとサーバー間の通信はSSL化されないという特殊な設定になります。

メリットとしては、共用サーバーなどのSSL証明書が設定しづらい環境でも無料でSSL化風にすることができる点があげられます。

デメリットは、本来の意味でのSSL暗号化通信ができないため、完全なセキュア環境でないという点です。
しかし、共用サーバーが提供しているような「共用SSL」を使うぐらいであれば、URLも変わりませんので有効です。
自己証明書を用意できるサーバーであれば迷わず「Full」をご利用下さい。

WordPressにおけるSSLの仕様

CLOUDFLAREがどういう仕様でSSLを提供しているかが分かったところで、WordPress側の仕様に関しても確認しておきましょう。

WordPressでSSLを利用としたときに設定する項目として、管理画面の「設定」→「一般」にある「WordPressアドレス」と「サイトアドレス」のそれぞれの項目を「https://」にすることで常時SSL化を実現することができます。

WordPressは「WordPressアドレス」と「サイトアドレス」に設定されているそれぞれのURLにリダイレクトするよう設定されています。そのため、SSL化後に「http://」と入力しても「https://」に自動的にリダイレクトして表示してくれます。

注意が必要なのはこれが正常に行われるのは、「Full」または「Full(static)」ができるサーバー側でもSSL証明書を設定しているときに限ります。

つまり「Flexible」しか使えない環境下でWordPressを使っている方は、管理画面でURLを変更しただけではSSL化ができないばかりか、サイトが見れない状態になるというわけです。

WordPressにおけるSSLの仕様の罠

「Flexible」とWordPressの組み合わせが悪くなるのには理由があります。

「Flexible」の特徴にもありましたが、CLOUDFLAREとサーバー間でSSL化されていません。

これが原因で、CLOUDFLAREがサーバーと通信するときは「http://」で通信をしようとしますが、WordPressは「https://」にリダイレクトしようとします。
リダイレクトされるとまたCLOUDFLAREがサーバーと「http://」で通信をしようとします。

つまり、恐怖の「無限リダイレクト」に陥りサイトが見れなくなるという現象が発生してしまいます。

こうなってしまうと、管理画面にも入れない、サイトは見れない、WordPressのURLを変更できないという「詰み」状態になります。
※実際はphpMyAdmin等のツールを使って直接データベースに書かれている「WordPressアドレス」と「サイトアドレス」を変更することで復旧させることができます。

解決方法

前フリがだいぶ長くなりましたが、解決方法に関してご紹介したいと思います。

基本はこれからご紹介する「wp-config.php」を変更する方法で対応可能です。
あわててプラグインをインストールしなくても大丈夫です。
※ご紹介の方法でも対応できない場合も、バージョンやサーバー会社の設定によってありますので、ご了承下さいm(_ _)m

「wp-config.php」を開いて、一番上の行に下記を追記してみて下さい。

ソースコードの解説

データの通信が「https://」であるかを調べるときにヘッダー情報「HTTP_X_FORWARDED_PROTO」を確認します。
PHPだと「$_SERVER[‘HTTP_X_FORWARDED_PROTO’]」で取得可能です。

この変数の値が「NULL」でなく「https」である場合に行う処理となります。

ただし、「HTTP_X_FORWARDED_PROTO」の値が「SSL」を表していても実際には「http://」でアクセスされているので「$_SERVER[‘HTTPS’]」の値が「off」になっていますので、それを「1」つまり「on」にします。

合わせて利用するポート情報である「$_SERVER[‘SERVER_PORT’]」の値も「80」になっているので「443」にしてSSLで処理してもらうようにお膳立てをします。

これで、何も問題がなければサイトがSSL化されています。

まとめ

CLOUDFLAREは非常に便利ですが特殊な動きをするサービスでもあるので動作を理解していないと罠にかかり、抜け出せなくなる恐れもあります。

是非、CLOUDFLAREとWordPressとうまく付き合ってみてください。

ではではー。