[AMIMOTO] AWS上のWordPressのSSL化

2017年8月6日2019年1月11日 Bluebear-IO 1056 Views 0 Comments

Googleの検索結果にも影響するということで、AWS上のWordpressをSSL化してみたが、何回か躓いたが案外簡単だったので方法を紹介する

WordPressはAMIMOTOで構築されており、CloudFrontの基本的設定は完了していることが前提となっている。

AWS上でSSL証明書を取得

SSL証明書は世の中基本的に独自ドメインのSSL証明書は有料だが、AWSのCloudFrontもしくはELB上でAmazonが発行する独自ドメインの証明書が無料で利用できる。

今回はCloudFrontで構築するため、CloudFrontに証明書を設定する

Distribution設定

対象のDistributionの開き、Edit DistributionでCustom SSL Certificate (example.com)にチェックを入れる。

すぐ下に証明書一覧が表示されるが、もちろん証明書は未発行のため、「Request or Import a Certification with ACM」をクリック。

証明書のリクエストが別ウィンドウで開くので、発行したいドメイン名を入力する（例：hogehoge.com）

「確認とリクエスト」を２回クリックすると独自ドメインの指定メールアドレスにメールが送信される。（事前にwebmaster@hogehoge.comというメールアドレスを作成しておくとよい）

おそらく独自ドメインはRoute53で設定されていると思われるので、メールを受信するためには、MXレコードが事前に設定されている必要がある。

証明書発行許可メールが到着していたら、メール内にあるURLをクリックして、Approvalボタンを押す。

先程の証明書の発行依頼をしたウィンドウに戻り、確認ボタンを押すと証明書一覧が表示される。証明書の状況が「発行済み」であればOKだし、「検証保留中」であればまだ承認作業がこちらで完了していないことを意味している。

発行済みになれば、CloudFrontの画面に戻り、証明書一覧の横にあるReloadアイコンをクリックして、証明書一覧を再取得する。

おそらく先程発行した証明書が表示されるので、選択。画面一番下にある「Yes,Edit」で確定させる。

WordPressの設定

SSL化プラグインのインストール

サイト全体をSSL化するためには独自ドメインから読み込むリソース（imgやjs , cssなど）の読み込みURLがすべてHTTPSになっている必要がある。

記事やコンテンツがかなりある場合は１個１個修正していくのはかなりしんどい。

といって、置換プラグインでHTTPをHTTPSに変更してもよいが、そもそも量が多いとスペックの問題で置換できなかったりするので、SSL化専用プラグインを使用するのが最も楽。

SSL Insecure Content Fixerというプラグインは、指定レベルでSSL化を手伝ってくれるので、インストールしておく。

インストールが完了したら、設定を行う。

修正コンテンツはデフォルトではSimpleになっているが、今回はコンテンツもSSL修正して欲しいので「Content」にチェックを入れた。

HTTPS detectionは「HTTP_CLOUDFRONT_FORWARDED_PROTO」もしくは「unable to detect HTTPS」が望ましいと思われる。

WordPressURLのHTTPS化

WordPress側のURLをHTTPSに変更する。

「設定」→「一般」の「WordPress アドレス (URL)」と「サイトアドレス (URL)」をHTTPからHTTPSへ変更して確定させる。

wp-config.phpで設定されている場合はwp-config.phpを変更する

確定させるとリダイレクトループが発生するが焦らない。

wp-config.phpでSSL有効

wp-config.phpに以下のコードを追加

/**
 * SSL
 */

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

これによりHTTPSのリダイレクトループが発生しないようになる

CloudFront Behaviors設定

AWS CloudFront Behaviorsタブに移動して、それぞれのBehaviorsにHTTPS通信を行うように設定していく

WordPressに最低限必要なBehaviorsは

/wp-admin/*
/wp-login.php
Default

となっており、Default以外はCacheしないようにTTLを０にしておく。

それぞれのBehaviorsをEditで開き、Viewer Protocol Policy欄を「Redirect HTTP to HTTPS」に変更する。

これによりユーザがHTTPでアクセスしてきてもHTTPSへリダイレクトすることができ既存トラフィックをSSL化することができる。

HTTPS OnlyにするとユーザがHTTPでアクセスしてきたものは拒否するので、あまりよろしくない。

余談だが、/wp-login.phpと/wp-admin/*のAllowed HTTP Methods欄は「GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE」にしておく必要がある。GET, HEADだけだとログイン自体ができないので注意。

Google Chromeでのチェック

これでページアクセスすると自動的にHTTPSにリダイレクトしてくれ、うまく行っていればAmazon発行の証明書でSSL化が成功している。

SSL化が完全に行われているか確認するブラウザはChromeが良い。アドレスバーが緑になっていれば、Googleが考えるSSL化ができていることになる。

もし表示がおかしい場合やブラウザに一部しかSSL化できていない警告が表示された場合は、Chromeの機能で確認することができ、ページを右クリック「検証」→「Security」で赤に表示されているところが修正すべき項目となる。

よくあるのが「Mixed Content」でHTTPとHTTPSが混在していることが多い。何がHTTPなのかは、「検証」→「Security」タブを開いた状態でページを再読込すると、Mixed Content欄に項目が再表示される。

修正したら、CloudFrontとNginxのキャッシュを削除することを忘れずに。

チェック中はCloudFrontのTTLを０にしてキャッシュしないようにしてもよい。

よくある修正ポイント

よくあるポイントを列挙してみた。

WordPressのTemplateファイルにhttp://と直接書いている場合はhttps://と修正する。下記のようにsiteurlと記述したほうが今後楽。
```
<?php echo site_url(); ?>
```
広告を貼り付けている場合、広告提供業者が提供しているコードがhttpの場合は表示されないかもしれないので、httpsのコードを取得して実装する必要がある。
どうしても修正できない場合は、先程インストールしたSSL Insecure Content Fixerの修正レベルを引き上げる。ただし引き上げれば引き上げるほどパフォーマンスに影響が出るようなので、注意。

Bluebear I/O: 技術備忘録

[AMIMOTO] AWS上のWordPressのSSL化