非SSL環境で動かしていたWordPressをSSL化するときの手順です。ちょうどLet’s Encryptを使って認証された証明書が手に入ったので、これを使ってWordPress全体をSSL化してみました。手順を備忘録として残しておきます。
wp-config.phpの修正
まずは基本ですね。WP_HOMEとWP_SITEURLを書き換えます。また、FORCE_SSL_ADMINを設定することで管理画面はHTTPSを強制できます。
|
1 2 3 4 5 6 |
- define( 'WP_HOME', 'http://saku.io' ); - define( 'WP_SITEURL', 'http://saku.io' ); + define( 'WP_HOME', 'https://saku.io' ); + define( 'WP_SITEURL', 'https://saku.io' ); + define('FORCE_SSL_ADMIN', true); |
データベースの修正
WordPressのデータベースに接続し、(WPプレフィックス)_options テーブルを開きます。
option_nameカラムがsiteurlになっているレコードを探し、値のhttp://をhttps://に書き換えます。続いてoption_nameカラムがhomeになっているレコードを探し、同じように書き換えます。
HTTP接続をHTTPSにリダイレクト
上の2ステップでWordPressのシステム的な部分の移行が終わりました。HTTPSで適当なページを開いて正しくリンクが遷移できるか、リンク遷移後もページもHTTPSになっているか、画像や画像のサムネイルが正しく読み込めているか、管理画面へHTTPSのままログインできるか、などをチェックします。
問題がないようであれば、httpでの接続はすべてhttpsにリダイレクトするようにします。（任意です。httpsにすると若干サーバーの負荷も増えますので、ハイトラフィックなブログを運営されている方はhttpの方が有利という考え方もできます。ブログであれば、http/httpsどちらでもアクセス出来るようにしておき、通信を暗号化するかどうか判断をユーザーに委ねるのも良い方法です。）
今回nginxを使っているので、nginx.confを書き換えることにしましょう。リダイレクトにはrewiteを使っているブログも多く見られますが、nginx.orgではreturnが使われていたのでreturnを使うことにします。計った訳ではないですが、シンプルな分処理も早そうです。
|
1 2 3 4 5 6 7 8 9 10 |
+ server { + listen 80; + server_name saku.io; + return 301 https://$host$request_uri; + } server { - listen 80; listen 443 ssl; } |
保存したらnginxを再起動します。
|
1 |
sudo service nginx restart |
再起動が終わったら、適当なURLを叩いてみてHTTPSに正しくリダイレクトされることを確認します。
安全でないリソースを排除する（Mixed Content問題）
これで9割方終わっていて、SSLにするという目的自体は達成なのですが、次のように「このページに安全でない他のリソースが含まれています。」と表示され、URLのアイコンや文字色も緑色にならないことがあります。
これは、アクセスしているページはSSL接続にも関わらず、そのページ内から非SSLの静的ファイル等をロードしているためです。例えば、サードパーティのCSSやJavaScript、フォントファイル、画像ファイル等を絶対パスでhttp:// に続く形でロードしていることに起因するものが多いです。
これらを見つけて、httpsが提供されているコンテンツはhttpsでロードするように、提供されていない場合はライセンスを確認して自分のサーバーでホスティングできるか確認して移行するなどの対策を行います。量が多いと結構大変ですね…。
どのファイルがMixed Contentなのかは、Google Chromeのデベロッパーツールにあるコンソールが助けになります。
例えば上の画像のように、過去にアップロードした画像ファイルに起因するものであれば、次の項を読んでみてください。テーマやプラグインに起因するものは、手動で直さなければいけません。
ちなみに、Protocol Relative URLという仕様により、CSSやJavaScriptをロードする際のhttpやhttpsを省いて記述すると、読み込み元のスキーム（SSLか非SSLか）に従って読み込むスキームも変更されポータビリティが高まります。（例えば //example.com/main.js をSSLのページからロードさせた場合はhttps://〜と解釈され、非SSLのページからロードさせた場合はhttp://〜と解釈されます。）
アップロード画像に起因するMixed Contents問題を直す
この場合、基本的には記事を編集して、画像へのURLを書き直すことで修正できますが、過去の記事・画像が多いと直すのに骨が折れます。
一気に前述したProtocol RelativeなURLに画像リンクを書き換えるSQL文を使うと一瞬で解消できるでしょう。テストしていますが、万一のために必ず実行前にテーブルのバックアップを取ってください。
|
1 2 3 4 5 6 |
UPDATE wp_posts # 適宜プレフィックスがあれば読み替えてください SET post_content = ( Replace (post_content, 'src="http://', 'src="//') ) WHERE Instr(post_content, 'jpeg') > 0 OR Instr(post_content, 'jpg') > 0 OR Instr(post_content, 'gif') > 0 OR Instr(post_content, 'png') > 0; |
無事にMixed ContentsによるSSLの警告も消えました。
雑感
サクっとこなすつもりが意外と色々気にすることがあって大変でした。一度やっておくとノウハウ的に使い回せるので、知識として蓄えておきたいですね。
次はHTTP/2, SPDY対応や、証明書の透明性確保あたりを触れたらいいなと思っています。
