ELBの無償の証明書を使用しようと思いELB付きの環境を構築。WebサーバはNginx。設定が面倒なのでELB-EC2間はSSL暗号しないでできるという、どこぞやのブログを見ながらやってみたが「502 Bad Gateway」になり転送ができていない。CloudWatchとか見たりNginxのエラーログを見たが１６進数のエスケープ文字が出ているだけで文字化け？つーか文字がそもそも壊れている？Responseヘッダーなどの容量とかの問題ではなさそうだが…。
…とりあえず色々と試行錯誤しているうちに502エラーそのものはNginxではなくELBがResponseしていることがわかったので、ELB-EC2間がおかしいわけだけどそこについての情報はこれ以上は得られないと判断して、きちんとTLB-EC2間をSSL暗号化することにした（俺俺証明書）そしたら一応はSSL化されて正常に通信がされるようになった…。
「ELB-EC2の間はhttpでいい」というのだったのか、かなり昔にもはまったことがある気がします。どっかの掲示板にもインフラエンジニアが覚書していましたが…「安易に通信プロコル変換して通信しないほうが無難」と行っていました。そりゃそうですね。日本語を英語にして日本語にして会話したら情報に齟齬が発生する。デジタル通信と自然言語の翻訳は違う比喩と言われればそれまでですが(-_-;)。…そもそもロードバランサを使用したことが人生で2回目な気がするが、その時もIDC内のネットワークとはいえ平文で情報を流していいか悩んだ気がする。今回は得体の知れない？AWSのアベイラビリティゾーンてことでそれを信用せずにやはりSSL化しておくというのが色んな意味で無難なのでしょう。ロードバランサとネットワーク管理者が別で、そのネットワークのパケットを盗み見られる可能性が高くなるという意味では内部データも全て暗号化しておくべき。
…残るは所有しているドメインでのSSL化であったが…これもRoute53を使用してAレコードでもCNAMEレコードでもないエイリアスなるものを定義しないといけないらしく…探しても出てこない…ほかのどこぞやのブログにはあるのに…だいぶ画面の構成が違うな…結局、見つけて設定するのに１時間ぐらいかかった。
Aレコードに対しての別名なのでAレコードを指定した上で「Application Load Baralcer と Classic Load Barancerへのエイリアス」を選択することに気づくのが遅くなった。次はCloudFront導入のためにまたこの辺の設定を変えながらELBのフロントに設置することになるらしいのですぐ行けばいいのだが…ってところ。
１つここまでやって言えることはjs系の情報もだけど「これでお手軽にできるよ！！」系の情報はほんとうに信用できないので真面目にAwsの説明を読み込んでまずは正常系でやるべし。ということがいえる。
追伸）最終的に前段にCloudFrontをかますという設定もできたっぽい。S3の設定がまだけど…たぶん同じ要領でできる気がしている…AWSが分かってきた！？
コメント