wordpressのサイトをhttpからhttpsへとSSL化する手順（保存版）

こんにちは、筋肉めがねです。

先日、クラシックのハウスコンサートにおいて、譜めくり、というものを体験させて頂きました。この経験により、クラシック音楽というものがグッと身近になったので、その過程をシェアさせて頂きます。

友人、家族にクラシック音楽に精通している人がいる、という環境ではないところで育った僕にとって、クラシック音楽、というのは、例えば茶道のような、何となく奥深いものではあるんだけれども楽しみ方が分からない。そういう対象でした。

そんな中、とある御方のご好意で、幾度かクラシック音楽のコンサートに行く機会に恵まれ、オーケストラの迫力、指揮者の熱意など、少しづつではあるけれどもクラシック音楽を楽しめるようになってきている。最近はそういう状況でございました。

そして譜めくりでございます。

譜めくりをさせて頂ける、というお話をいただいてネットで情報を集めました。譜めくりスト、と呼ばれる方達がいる、と。そして譜めくりはとても責任重大な仕事である、と。

nishiborikayoko.com

noctifer.hatenablog.com

yasunori.me

 いつかこちらの映画も鑑賞したいですね。

譜めくりの女 デラックス版 [DVD]

本番で失敗しないために、事前に曲を聴きながら譜面を追っていくんですよね。何度も何度も聞くんです。そうすると、不思議なことに、次第にその曲に対して愛着が湧いてくるんです。高校時代に何度も聞いた平井堅の「楽園」のように。

この曲に対して愛着が湧いてくる、という感覚を覚える事が、クラシックを知らない人間がクラシックに興味を持ち始める上でとても大事なんでしょうね。そんな事を感じた体験でございました。

そして、先日、とあるコンサートを客として鑑賞したのですが、本物の譜めくりストは別格でございました。譜めくり、という技術が素晴らしいだけではないのです。演奏が終わり、奏者が立ち上がり、お客様に礼をする。その時、譜めくりストは、ただ動かずに椅子に座っているのでしょうか。違います。奏者と共にサッと立ち上がり、お客様からは全く気づかれないような気配で持ってピアノの後ろへ移動するのです。

譜めくりは奥が深い。

何はともあれ、こんなに貴重な機会を与えてくださった方々には感謝でございます。

さて、冒頭で譜めくりについて書きましたが、本日は、これ以降、ワードプレスのSSL化手順について書いていきましょう。

• AWS EC2, php, MySQL, apache2
• FileZilla, Sequel Pro
• wordpress
• Route 53
• Elastic Load Balancer
• Certificate Manager

先ずは、AWSでEC2をセットアップし、そこにphp, MySQL, apache2を導入しますが、これらの手順、そしてFileZilla、Sequel Proのセットアップ方法、およびwordpressのイントール方法は以下の記事に書いております。

kinnikumegane.hatenablog.com

それでは、wordpressをインストールした、という前提で、これ以降の手順を書いていきます。

.htaccessファイルの有効化

.htaccessファイルとは、ざっくり言うと、WEBサーバーをコントロールするための設定ファイルです。例えば、サイト内の、あるURLにユーザーがアクセスしてきたときに、別の特定のURLにリダイレクトさせるために.htaccess内にリダイレクト処理を記述させる事ができます。

そこで先ずは、.htaccessファイルを有効化させる必要があります。

.htaccessファイルを有効化するには、apache2.confファイルを編集する必要があります。

/etc/apache2/フォルダ下にapache2.confファイルが格納されております。そのファイルを開けて、<Directory /var/www/>の箇所を見つけ、その中のAllowOverride NoneをAllowOverride Allに変更します。

それでは、.htaccessファイル自体はどこにあるかというと、僕の場合は、デフォルトでは作られていませんでした。ですので、新たに作る必要があるんですね。

もう一つ、.htaccessファイルを有効化するための手順として、mod_rewriteをインストールしておく必要があります。

terminalから、ec2へsshでアクセスし、root直下で以下を叩きます。

sudo a2enmod rewrite

インストールが完了したら、apacheサーバーを以下でrestartしましょう。

sudo systemctl restart apache2

これで、.htaccessの機能を有効にする事ができます。 

.htaccessファイルの作成

textエディターファイルで、新しくファイルを作り、中身に以下を記述します。そして、ファイル名を.htaccessとすれば出来上がりですね。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

そして、.htaccessを/var/www/html/直下へ格納します。

これで、.htaccessの設定は完了です。

Route53でDNS設定

AWSのRoute53で新しいHosted Zoneを作成します。

Domain nameには、 既に他のDNSサービス（GoDaddyなど）で取得したdomain nameを記入し、Typeはそのままで、"Create"ボタンを押します。

Hosted zoneを作成すると、デフォルトで、type NSとtype SOAのレコードが設定されています。ここで表示されているNS (Name Server)のvalueを、ドメインを取得したDNSサービス側で登録してあげる事でドメインとroute53を紐づける事ができます。

例えば、GoDaddyを使用している場合、取得したドメインの"DNS Management"のページを見てみると、デフォルトでいろんなレコードが設定されております。

ページを下の方にスクロールしていくと、Nameserversの設定のところで"Change"ボタンがあるので、それを押し、先ほどRoute 53のHosted Zoneで表示されたName serverを一つ一つ設定してあげるんですね。

これで、Route 53のhosted zoneと自分で取得したドメインを紐づける事ができます。

Certificate ManagerでSSLを取得

SSLとはSecure Socket Layerの略で、ざっくり言うと通信を暗号化するために使用されている技術です。

このSSLのcertificateについては、各DNSサービスで有料で取得する事はできますが、AWSでは無料で取得できるんですね。

AWSのCertificate Managerで"Request a certificate"ボタンを押し、ガイダンス通りに必要事項を記入していきます。

進めていくと、validationの方法をDNSにするか、emailにするか、という質問があるので、そこはDNSにしましょう。

Certifacateを作り終わると、Validation statusのところに、"Pending validation"という文字が表示されます。

ここで、もう一度Route53に戻り、先ほど作成したHosted zoneの中で、上で表示されているCNAMEというレコードを設定してあげる必要があります。

NameとValueについて、Certificate Managerの画面で表示されているところからコピペで、そして、タイプはCNAMEを選びます。

TTLというのは、保存後にどれぐらいの時間で設定が反映されるかを決めるものです。60秒にしても良いですね。

Route 53でCNAMEを設定後、60秒程度経ったのちに、先ほどのCertificate Managerに戻り、先ほど設定したドメインのstatusを見ると"Issued"と表示されています。

これで、Certificate Manager上での設定は完了です。

Load Balancerの設定

続いて、Load Balancerの設定です。Load Balancerとはざっくり言うとサーバーにかかる負荷を軽減してくれるものです。

AWSのEC2のページで、Load Balancerを選択します。

そして、Application Load Balnacerを作成します。

先ずは、Load Balancerの名前を決めます。

そして、Listenersについて、デフォルトではHTTPのみ作成されておりますが、SSLを導入するためにはHTTPSを追加する事が不可欠でございます。HTTPSを追加し、Portはデフォルトの443を使用します。

Availability zonesは選択可能なものを全て選択しましょう。

Tagsは未設定で問題ありません。

ACMですが、ここで先ほど作成したCertificateを選択します。

Security policyはデフォルトの設定でOKです。

Security groupの設定は、今回使用しているEC2に紐づいているSecurity groupと同じものを選択します。

RoutingのConfigurationについては、target groupのNameを設定してあげて、残りはデフォルトの設定で結構でございます。

ここで、SSLの設定をする、つまりHTTPSの設定をするんだ、というにも関わらず、HTTPをprotocolとして使用していることに、違和感を感じる方もいらっしゃると思います。

その理由について、以下のブログから該当箇所を抜粋しましょう。

A little more explanation: by default Apache is installed to use HTTP (port 80), therefore all configuration for this protocol was taken care of for you when your originally setup your server. Importantly, inbound traffic originating from the ELB also is traveling over HTTP as per the diagram above and thus we a) should continue to listen on port 80, and b) we should continue to use HTTP all the way to our WordPress server. Now then, to provide an end-to-end HTTPS connection for our users we’ll need our WordPress server to return all web pages over HTTPS rather than over HTTP.

blog.lawrencemcdaniel.com

要は、ユーザーがhttpsとURLを指定してサイトを見にいくときに、ELB (Elastic Load Balancer)がその処理をHTTPに変換してEC2 instanceへ信号を送る、という事なんですよね。

もしも、Load Balancerを使用してのSSLの設定がどうしても上手くいかない、という人がいらっしゃったら、この部分をきちんと理解する事に時間を使うと、だいぶスムーズに問題を解決できる事と思います。僕自身Load Balancerを使ってのSSLの設定が1週間弱できず、どうしようか途方にくれておりましが、順を追ってLoad Balancerの役割、信号の流れを理解する事で、その後1日でSSLの設定ができた、という経緯がございます。

そして、紐づけるEC2 instanceを選択し、Load Balancerの設定は完了です。

続いて設定したLoad BalancerをRoute53のHosted zoneと紐づける必要があります。

先ほど、設定したRoute53内のHosted zoneを選択し、新しくレコードセットを設定します。A typeを選択後、AliasをYesとすると、先ほど作成したELB (Elastic Load Balancer)を選択する事ができるので、それを選択し、Createボタンを押します。

これで、Load Balancerをドメインに紐づける事ができました。

この時点で、

http://xxxxxx.comにアクセスすると問題なく動作しており、

http://xxxxxx.com/wp-adminにアクセスすると、それも問題なく動作しています。

しかし、

https://xxxxxx.comにアクセスすると、cssがきちんと動作していない状態で表示されており、また、

https://xxxxxx.com/wp-adminにアクセスすると、http://xxxxxx.com/wp-adminにリダイレクトされる、という問題があります。

ちなみに、SSLの設定において、httpsにアクセスしているにも関わらずhttpへリダイレクトされる、もしくはその逆にリダイレクトされる、という問題が発生する事があると思いますが、その時に、どういうフローでリダイレクトされているのかトラッキングできるサイトがあるので、参考に以下に載せておきます。

www.redirect-checker.org

それでは、cssの問題、リダイレクトの問題を解決していきましょう。

CSSの問題、リダイレクトの問題を解消する

先ずは、httpsで、wordpressの管理画面にログインできるように設定をします。

wordpressのルート直下（/var/www/html/）にwp-config.phpファイルがあります。そのファイルに以下を記述します。記述する場所は、define( 'DB_NAME', 'xxxx' );の上としましょう。

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
     $_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

続いて、.htaccessファイルの一番上に以下を追記します。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]
</IfModule>

そして、最後にwordpressで設定されているsiteurl, homeのURLを変更します。

この時点では、ブラウザから管理画面には入れないと思いますので、Sequel Proからwordpressのdatabaseへアクセスします。

すると、database内のwp_optionsというテーブルの中に、以下2つのoption_nameがあるため、それぞれの値をhttp://xxxxxx.comからhttps://xxxxxx.comに変更します。

siteurl

home

ここまで終えて、サイトにアクセスしてみると、幾つかのページでサイトがSSL化されていない事があります。これは、サイト内で使用されているjavascriptファイル、およびimageファイルの中に、httpsではなく、httpで読み込まれているファイルがある、という事が原因ですね。 

そこで、最後のbug fixを行います。

Mixed contentのbug fixを行う

サイト内の問題のページに移動して、google chromeのdeveloper toolsを開くと、mixed contentというエラーを表示しており、そしてエラーの原因である問題のファイルを表示してくれます。

僕の場合は、webの、とあるページに使用している画像がhttpで読み込まれている事が問題でした。そこで、wordpressの管理画面から、一旦、問題の画像を削除し、そして改めて同じ画像をアップ、先ほどのページに貼り付ける、という処理を行う事で、画像がhttpsとして読み込まれました。これで、webの全ページがhttpsで表示されました。

以上で、wordpressのSSL化が完了しました。お疲れ様でございました。特段webのセキュリティを気にかけたり、SSLという技術を気にしなければ、web pageがhttpであってもhttpsであっても気づくところではないかもしれません。それでも、googleが正式に、"httpよりもhttpsを優先して上位に表示する。"と名言している以上、可能な限りSSL化しておきたいところですね。

それでは、本日は以上でございます。

にほんブログ村

Pythonランキング