2017年以前の旧ブログ

BLOG2017

AWSでSSL

OB・OG Other Blog

どうも、バンチです。
このサイト、前に比べてセキュアな感じになったと思いませんか?

はい。https化してみました!

そんな威張るような話ではありませんが・・・
ただ、AWSでSSL対応するにあたっていろいろ調べてみると結構古い話題が多く、最善手を選択するのに少々迷いました。

なので2016年版としてちょっとメモしておこうかという次第。

構成

単純にSSL化するだけなら、SSL証明書取ってサーバーに設定すれば終了なのですがそれだけじゃ面白くないということで・・・

・SSL証明書はACMを利用
・ACM使うためにCloudFront or ELBを利用 ・・・今回はELB
・DNS解決の効率UP(+設定簡略化)のためネームサーバーはRoute53を利用

こんな感じで進めました。

無料SSL証明書

証明書、それなりに維持費がかかります。(1000円/年くらい?)
この証明書、AWS内で使えるやつをAmazonさんが無料で用意してくれます。
以前は北米リージョンのELB、またはCloudFrontでしか使えませんでした。
が、現在はカバー範囲が増えて各リージョンのELBでも使えるようになっています。

申請は自身が管理しているドメインであれば、コントロールパネルから簡単に行えます。
管理者確認のため、特定のアドレスのメールが受け取れる必要があります。(admin@hogeやwebmaster@hogeなど)
送られてきたメール記載の確認リンクを開けば、即時利用可能です。

ELB

Elastic Load Balancing 略してELB。
その名の通りロードバランサーなのですが、リバースプロキシでもあります。
ここにSSL証明書をもたせておくと、クライアントとの通信はHTTPS、ELBとインスタンスとの通信はHTTP、ということができます。

Route53

AWSで用意されているネームサーバーです。
dp778.co.jpは以前から利用しているドメインですので、Whois情報のネームサーバーをRoute53に切り替えるだけで移管できます。

これが便利なのは、独自拡張である「エイリアス」が使える点です。
本来AレコードはIPアドレスを指定する必要があるのですが、エイリアスを使うとELBのドメインがそのまま指定できます。
通例であればCNAMEを利用するシチュエーションなのですが、エイリアスを使うことで
・パフォーマンスが向上する
 → CNAMEだと解決までに問合せが2回発生
・ZoneApexで使用できる
という恩恵が得られます。

弊社の場合、2項目が地味に重要でした。
当サイトではアドレス欄の通り、サブドメインなしのZoneApexなアドレスを使用しています。
CNAMEはZoneApexのマッピングには使用できないため、必然的にエイリアスの機能が必要となっていました。

WordPressカスタマイズ

この構成ではELBの後段となるため、Wordpress自体はHTTPで動作しています。
サイトURL、WordpressURLを"https"にするだけではisSSL関数なんかが適切に動作しないために、メディアのURLがhttpのままになったりします。
そのために参照するのが、”X-Forwarded-Proto"ヘッダーです。
ELBはクライアントとの通信プロトコルがなんであったかをHTTPヘッダーに追加してインスタンスに渡してくれます。
WordPress側はこのヘッダーを参照してSSLフラグを立ててやれば解決します。
また、HTTPをHTTPSにリダイレクトする場合もこのヘッダーを参照する必要があります。
単純にリクエストアドレスだけ見てリダイレクトすると、一向にHTTPSにはならないためにリダイレクトループが発生してしまいます。

あと、稼働中のサイトを移行する場合は投稿内のリンクもhttp→httpsに変更する必要があります。
自分の場合はDBの内容を一括変換してしまいましたが、プラグインやカスタマイズで置換するのもありです。

感想

WordPressが行うリダイレクトが適切にできるかには神経使いましたが、まとめてしまうと特に複雑なところはない印象です。
AWS使用しているのであれば、手軽に導入できるSSLといえるのではないでしょうか?

欲を言えばCloudFront使いたかったです。
試しては居たのですがリダイレクト時の処理が時間内には詰め切れなかったので断念しました。
キャッシュが効いたときのレスポンスの良さは是非とも導入したいところ。
また、機会あればトライしてみようかと思います。