AWSでACM証明書を発行したにも関わらず、wordpressインスタンスのサイトをhttpsで、表示できない。

Question

###wordpressで、httpsで、接続できない。

###やったこと
・EC2でサーバーを立ち上げ（WordPress powered by Bitnami）
・ローカルで作ったwordpressを移植
・お名前.comで取得したドメインをRoute53に設定
・ACMで証明書発行 ドメインも紐付け
・ELB設定 ACM証明書も設定
・cloudfrontも設定 ACM証明書も設定
・wordpressのwp-config.phpも修正
参考にした記事

# for https on
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
    $_SERVER['HTTPS'] = 'on';

###その他、設定がわかるように画面キャプチャを貼りました。
acmで、下記の通り、全て認証済み

ELBにも設定済み

cloudfrontにも設定済み

試しに、CloudFrontのdomainnameで、
httpsアクセスしたら表示されました。（緑にはなっていませんが）
cssなどは読み込めなかったので、表示崩れしていましたが。。

何か重要な手順を忘れているのかもしれないのですが、
全く見当がつきません、、

アドバイスお願いいたします。

###追記
ブラウザのコンソールのエラー表示

Aレコード、cloudfrontのエイリアスのものを作った時に出ているアラート

###さらに追記

###さらに追記

Answer 1

何となく、Route53周りの設定のような気がします。

最終的にブラウザからアクセスしたいURLがhttps://example.comだとして、

• Route53のAレコード: example.com → CloudFrontのドメイン名(xxxxxxx.cloudfront.net)
• CloudFrontのOrigin: ELBのドメイン名(yourelbname.yourregionname.elb.amazonaws.com)

という感じかと思います。

example.comのAレコードをEIPに向けて、CNAMEをCloudFrontに向けたりしてないですよね？

Comments

[Tatsurou]

ご回答ありがとうございます。

> example.comのAレコードをEIPに向けて、CNAMEをCloudFrontに向けたりしてないですよね？
恐らく、そのように設定しているかもしれません。
AレコードニEIP、
さらにAレコードで、valueにALIASでcloudfrontに向けています。

[Tatsurou]

下記の記事の通り設定しました。
http://qiita.com/Ichiro_Tsuji/items/38592e737257cb45ca13

ただ、ここの説明がわからなかったです。
https://qiita-image-store.s3.amazonaws.com/0/80392/51e0a070-433e-6bc6-5a40-790e0baf2f78.png

[tsuemura]

> AレコードにEIP、さらにAレコードで、valueにALIASでcloudfrontに向けています
ということなので、CloudFront を見ずにEC2に直接接続しているので、CloudFrontに設定したACM証明書が使われてないんだと思うんですよ。CloudFront向きのレコードだけ残して、EIP向けのレコードは削除してはどうでしょうか。

> ただ、ここの説明がわからなかったです。
このドメイン名をAレコードに登録するということですね。

[Tatsurou]

> このドメイン名をAレコードに登録するということですね。
Create Hosted Zoneに、cloudfrontで作られたドメインネームを登録しました。
その後、Aレコードで、valueにEIPを入れました。

> CloudFront向きのレコードだけ残して、EIP向けのレコードは削除してはどうでしょうか。
EIP向けのレコードを削除したら、cloudFront向けのレコードも削除されてしまいました。

証明書が、「example.com」となっているのが気になります、、

[tsuemura]

Create Hosted Zoneで、example.comを作成して、
AレコードでvalueにCloudFrontのドメイン名を入れるのではどうでしょうか？

http://qiita.com/Ichiro_Tsuji/items/8471fe0b3d4d17cde146#a%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89alias%E3%81%AE%E7%99%BB%E9%8C%B2
上記URLなど参考になるでしょうか。

[Tatsurou]

Create Hosted Zoneで、example.com（使いたいドメイン）を作成し、
Aレコードのエイリアスに、手入力でcoudfrontのドメインを入力しましたが、
やはりダメでした。。
Evaluate Target Health が「No」となっているのも気になりました。

[tsuemura]

> Evaluate Target Health が「No」となっているのも気になりました。
これは、ヘルスチェックを有効にするかどうかなので、多分関係ないです。

DNS浸透まで時間がかかると思いますので、nslookup example.comで浸透したかどうか確認しましょう。
EIPを指すようであればまだ浸透していません。

[Tatsurou]

「nslookup abcd.work」をターミナルで実行しました。
////////////////////////////
Server: 8.8.8.8
Address: 8.x.x.x#5x

Non-authoritative answer:
Name: abcd.work
Address: 3x.xxx.x.xx ← EIP
////////////////////////////
結果ですが、これは浸透しているということでしょうか？

また、下記の記事をみて、お名前ドットコムの
ネームサーバー（1プライマリネームサーバー、2セカンダリネームサーバー）を、
記事の通り追加したりもしてみました。

[tsuemura]

EIPを指すようであればまだ浸透していません。
下記の記事とはどちらの事でしょうか。

ドメインをRoute53に移管したのであれば、お名前ドットコムのコンソールでRoute53のネームサーバーを既に追加しているはずです。していないのであれば、移管処理が漏れています。
もし万一、お名前ドットコムのコンソールでAレコードがEIPを指していて、移管処理も出来ていないとすれば、Route53をどう触っても解決しません。

[Tatsurou]

> EIPを指すようであればまだ浸透していません。
先ほどの転記した結果だと、AddressがEIPなので、浸透していないという事ですね。
となると、これは少し待たないといけないという事でしょうか。

> 下記の記事とはどちらの事でしょうか。
失礼しました。こちらです。
http://qiita.com/Ichiro_Tsuji/items/8471fe0b3d4d17cde146#dot-tk%E3%81%A7%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E3%82%92%E5%8F%96%E5%BE%97%E3%81%97route-53%E3%81%A7%E3%83%9B%E3%82%B9%E3%83%88%E3%81%99%E3%82%8B

> お名前ドットコムのコンソールでAレコードがEIPを指していて
こちらについて、お名前.comでは下記のキャプチャの通りになっています。
https://teratail.storage.googleapis.com/uploads/contributed_images/49d26f818758cf9e9b10c048653c2fce.png

後、気になった点ですが、
Aレコード、cloudfrontのエイリアスのものを作った時に出ているアラートなのですが、
ここは無視しても良いでしょうか？
https://teratail.storage.googleapis.com/uploads/contributed_images/be39a7dca55a750ee52ea0b20deb3b15.png

[tsuemura]

うーん、
> お名前.comで取得したドメインをRoute53に設定
こちらの具体的な手順を知りたいですね。

僕はてっきり、下記URLの2.のやり方を取ったのだと思っていました。
http://qiita.com/sadayuki-matsuno/items/4c371ba984d9b22b3737

この方法では、Route53が指定するNSレコードを、お名前.comのコンソールで登録する必要があります。
ですが、頂いたキャプチャだとNSレコードにはお名前.comのサーバが指定されています。
おまけにAレコードはお名前.comにも登録されていて、EIPが指定されているようなので、CloudFrontには向いてくれないと思います。

それとも、1.の方法を取ってたりするのでしょうか？

[tsuemura]

ちなみに、無理にRoute53を使わずとも、お名前.com側の設定でも実現できます。
Route53の設定に自信が無いようでしたら、とりあえずお名前.comの設定だけでやってしまってはどうでしょう？

[Tatsurou]

> > お名前.comで取得したドメインをRoute53に設定
> こちらの具体的な手順を知りたいですね。
これが、正確には覚えていなくて、

> NSレコードにはお名前.comのサーバが指定されています。
NSレコードは、この画像のように既に登録されていました。
しかも変更ができないようです。
もしかすると、ネームサーバーの切り替わりには最大3日かかるとの事なので、
そのため、お名前のサーバーのままなのかもしれませんね。

1日程度、待ったほうが良いのかもしれませんね、、
https://teratail.storage.googleapis.com/uploads/contributed_images/49d26f818758cf9e9b10c048653c2fce.png

> Aレコードはお名前.comにも登録されていて、EIPが指定されているようなので、CloudFrontには向いてくれないと思います。
お名前に登録してしまったAレコードは削除した方が良いという事でしょうか。

> Route53の設定に自信が無いようでしたら、とりあえずお名前.comの設定だけでやってしまってはどうでしょう？
下記の記事のセクション「」通り、やるという事ですね。試してみます。
http://qiita.com/sadayuki-matsuno/items/4c371ba984d9b22b3737#3%E3%81%8A%E5%90%8D%E5%89%8Dcom%E3%81%AE%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AB%E7%9B%B4%E6%8E%A5aws%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AEfqdn%E3%82%92cname%E3%81%A7%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B

[tsuemura]

僕もちょっと勘違いしていました。そうですね、ネームサーバを切り替えた場合は時間がかかりますね。

もし実際にネームサーバを切り替えたのでしたら、今度はお名前.comで設定した内容が無駄になってしまう可能性があります。もどかしいと思いますが、少し待ってみたほうがいいかもしれません。

[Tatsurou]

かしこまりました。
では、24時間ほど待って、再度、試してみますね。
その際は、また、こちらで結果などご報告させていただきたく存じます。
長いやり取りにお付き合いいただきありがとうございました。
また、引き続き、よろしくお願いいたします。

[tsuemura]

分かりました。結果楽しみにしてます。
お名前.comを使うにしろRoute53を使うにしろ、ドメイン名をnslookupして、EIPではなくCloudFrontが表示される事がゴールです。

EIPが表示されている状態ではCloudFrontを経由せず直接Webサーバを見に行ってしまっているので、SSLが効かないことも含めてCloudFrontの恩恵が全く得られません。
理屈が分かってしまえば何てことはないので、頑張ってみて下さい。

[Tatsurou]

続き）
先ほど、
nslookup -type=ns abcd.work したところ、

結果が、
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
abcd.work nameserver = ns-xxxx.awsdns-xx.org.
abcd.work nameserver = ns-xxxx.awsdns-xx.co.uk.
abcd.work nameserver = ns-xxx.awsdns-xx.com.
abcd.work nameserver = ns-xxx.awsdns-xx.net.

と返ってきました。

ということは、反映されたという事ですよね？

[Tatsurou]

nslookup abcd.work と入力して

//////////////////////////////////////////
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: abcd.work
Address: 3x.xxx.x.xx ← ここが、cloudfrontのドメインになっていればという事ですね。
//////////////////////////////////////////

あ、でも、cloudfrontのドメインは、
「 cf. 」なので、再度、nslookupしてみました。

nslookup cf.abcd.work
//////////////////////////////////////////
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: cf.abcd.work
Address: 5x.xxx.xxx.x8
Name: cf.abcd.work
Address: 5x.xxx.xxx.x8
Name: cf.abcd.work
Address: 5x.xxx.xxx.x8
Name: cf.abcd.work
Address: 5x.xxx.xxx.x8
Name: cf.abcd.work
Address: 5x.xxx.xxx.x8
Name: cf.abcd.work
Address: 5x.xxx.xxx.x84
Name: cf.abcd.work
Address: 5x.xxx.xxx.x835
Name: cf.abcd.work
Address: 5x.xxx.xxx.5
//////////////////////////////////////////

といった結果が返ってきました。

[tsuemura]

SSL、まだ効かないですか？

[Tatsurou]

https://cf.abcd.work
は、アクセスできました！！
ただ、アドレスバーの色が変わったりしませんね、、
また、cssは、「abcd.work（cf.じゃない）」のものを読みにいっているようで、
反映されません。

本当に効いて欲しいのは、
大元の「 abcd.work 」の方なのですが、
相変わらず、エラーとなってしまいます。

なかなか、一筋縄ではいかないですね、、、

[Tatsurou]

一旦、Aレコードを全部削除して、
再登録してみました。

まず、Aレコードに、
「abcd.work」、エイリアスをcloudfrontのドメインを手打ち入力。

すると、
今度は、https://abcd.work
で接続ができました！
しかもアドレスバーに保護された通信と表示されています。

ただ、エラー表示となってしまいます。
エラー内容
/////////////////////////
ERROR

The request could not be satisfied.

Bad request.
Generated by cloudfront (CloudFront)
Request ID: BZwl1lfMn1zOcVuJc9RBBo9LT1qO8R5732gug_u56ce2qszD67KOtA==
/////////////////////

[tsuemura]

cf.abcd.workというサブドメインの設定が必要、という話がどこから出てきたのか分からないんですが、
abcd.workで接続したい、というだけなら特に必要ないはずです。

で、CloudFrontのコンソールで「Alternate Domain Names (CNAMEs)」という項目があると思うんですが、
こちらが"cf.abcd.work"になっていると"abcd.work"からの接続は拒否するはずなので、
"abcd.work"に直してみて下さい。

あと一歩っぽい感じですね！

[Tatsurou]

> cf.abcd.workというサブドメインの設定が必要、という話がどこから出てきたのか分からないんですが、
abcd.workで接続したい、というだけなら特に必要ないはずです。
↑
こちらは、僕もよくわかっていないのですが、
wordpressを使うので、アクセスの度に、
ページを生成させたくなかったので、
キャッシュサーバーを使うために、cloudfrontを選択することにしました。
参考にした記事に、サブドメインを使うといった記事があったので作成したのですが、
そもそもサブドメインにする必要があるのでしょうか。。
http://qiita.com/Ichiro_Tsuji/items/38592e737257cb45ca13

> こちらが"cf.abcd.work"になっていると"abcd.work"からの接続は拒否するはずなので、
> "abcd.work"に直してみて下さい。
今、originと、CNAMEs、どちらも、
「 abcd.work 」に変更いたしました。
In Progressとなっていますので、しばらく、待ってみます。

あと、一歩な感じで、凄く嬉しいです、、

[Tatsurou]

やはり、ダメでした、、

httpsで、証明書もしっかり確認はできているのですが、
また、cloudFrontのErrorが出ますね、、
chromeのコンソールには、下記のようなエラーが出ております。
/////////////
Failed to load resource: the server responded with a status of 403 ()
katsuobushi.work/ Failed to load resource: the server responded with a status of 403 ()
/////////////

[tsuemura]

* EIP
* ELBのエンドポイント
には繋がりますか？

[tsuemura]

見落としてました。
> originと、CNAMEs、どちらも「abcd.work」に変更いたしました。

originはabcd.workにしてはいけません。
abcd.workにアクセスするとCloudFrontにつながり、CloudFrontはabcd.workを見に行くというループになってしまいます。

回答の内容をもう一度書きますが
* Route53のAレコード: example.com → CloudFrontのドメイン名(xxxxxxx.cloudfront.net)
* CloudFrontのOrigin: ELBのドメイン名(yourelbname.yourregionname.elb.amazonaws.com)
としてみてください。

[Tatsurou]

ご回答ありがとうございます。

> * EIP
> * ELBのエンドポイント
> には繋がりますか？
EIP、ELB共に繋がりますが、
HTTPS接続すると、Route53で、Aレコードで、
EIPを紐づけていないため、
下記の画像のように「保護されていない通信」となってしまいます。
https://teratail.storage.googleapis.com/uploads/contributed_images/b7d03830969ec6255aeef8df074f6399.png
ELBも同様です。

> originはabcd.workにしてはいけません。
こちらは、「cf.abcd.work」に戻しました。

> * Route53のAレコード: example.com → CloudFrontのドメイン名(xxxxxxx.cloudfront.net)
→ 以前、登録していたもう一つのAレコードのエイリアスがcloudfront選択の「cf.example.com」は削除し、
エイリアス手打ちのCloudFrontのドメイン名(xxxxxxx.cloudfront.net)のAレコードのみに設定しました。

> * CloudFrontのOrigin: ELBのドメイン名(yourelbname.yourregionname.elb.amazonaws.com)
としてみてください。
こちらも修正いたしました。

cloudfrontが 反映されるまで少し待ってみます。

[tsuemura]

CloudfrontのOriginはcf.abcd.workにしたんですか？それともELBのドメイン名にしたんですか？
cf.abcd.workのAレコードは削除しているとのことなので、Originをcf.abcd.workにしていると動かないはずです。

OriginというのはCloudfrontが配信するコンテンツの配信元ですので、CloudfrontはOriginに指定されたURLに接続できる必要があります。

[Tatsurou]

再度、アクセスしてみましたが、

http://CloudFrontのドメイン名(xxxxxxx.cloudfront.net)
→ 結果は、The request could not be satisfied.

ssl https://CloudFrontのドメイン名(xxxxxxx.cloudfront.net)
→ 結果は、The request could not be satisfied.
.cloudfront.netの証明書となる

http://abcd.work/
→ 結果は、The request could not be satisfied.

http://abcd.work/
→ 結果は、
「このサイトは安全に接続できません
abcd.work ではサポートされていないプロトコルが使用されています。
ERR_SSL_VERSION_OR_CIPHER_MISMATCH」
となる。

このような状態ですね。。

やはり、EIPを紐づける必要がありそうですね。
難しいです、、

[tsuemura]

CloudFrontのドメインで接続できない→Originが間違っている可能性があります。
abcd.workでアクセスできない→CloudFrontに設定したCNAMEsが間違っている可能性があります。

CloudFrontの
* Origin: ELBのドメイン名
* CNAMEs: abcd.work
となる必要があります。

> やはり、EIPを紐づける必要がありそうですね。
何に対して紐付けるのですか？abcd.workにEIPをひも付けた場合、abcd.workでACM証明書は使えません。

[Tatsurou]

> Originが間違っている可能性があります。
ここは、
CloudFront Distributions > origins の 「Origin Domain Name」を abcd.workに変更

> CloudFrontに設定したCNAMEsが間違っている
こちらは、
CloudFront Distributions > general の、
cNamesを「abcd.work」に変更。

上記の2点の修正という認識であっておりますでしょうか。

画像を追加しました。
https://teratail.storage.googleapis.com/uploads/contributed_images/0e9c76e331057bc9972191009ec634ac.png
https://teratail.storage.googleapis.com/uploads/contributed_images/8d8b71321a3c4d4fea19f12ca7fc78c3.png

[tsuemura]

画像の注釈に書いてある方法が正しいです。
CloudFront Distributions > origins の 「Origin Domain Name」を "ELBのドメイン名に変更"
CloudFront Distributions > general の、cNamesを「abcd.work」に変更。
です。

[Tatsurou]

アドバイス頂いた方法で、
https://abcd.work で、アクセスしたところ、
表示されました！

ただ、下記のようなエラーメッセージが出ており、
css jsなどが読み込めないようです。
なので、表示崩れとなっています。
///////////////
(index):31 Mixed Content: The page at 'https://abcd.work/' was loaded over HTTPS, but requested an insecure script 'http://xxxx-20xxxxx8.us-east-1.elb.amazonaws.com/wp-includes/js/wp-emoji-release.min.js?ver=4.8.1'. This request has been blocked; the content must be served over HTTPS.
////////////////////////

長いお時間アドバイスを頂きありがとうございました。

ただ、ここからですね、、。
正解があるようなないような状態なのですが、
wordpressでの設定が必要なようです。

[Tatsurou]

> CloudFront Distributions > origins の 「Origin Domain Name」を "ELBのドメイン名に変更"
↑
こちらの設定をした為なのか、
管理画面や、トップページから別ページに移動すると、
ELBのアドレスが表示されてしまいますね。

うーん、かなり難しいですね、、泣

[tsuemura]

* css, jsが読み込めていないのは、「CloudFront→ELBへの通信がHTTPだから」です。HTTPSにする必要があります。サブドメイン(例えば、elb.abcd.work)のAレコードをELBに向け、ELBにACM証明書を設定しましょう。同時に、設定したサブドメインをCloudFrontのOriginに設定する必要があります。
* 管理画面でELBのアドレスが表示されるのはWordPressの設定の問題です。下記URL（と言っても度々出ているものですが）の、「WordPressの設定を変更する」を参照してください。
http://qiita.com/Ichiro_Tsuji/items/38592e737257cb45ca13

CloudFront + ELB + EC2 という3段構え、かつSSL対応ということで、慣れていないとかなり難しく感じるはずです。もし身近に詳しい人がいらっしゃれば、対面またはSkypeなどで指導してもらえると手っ取り早いんですけどね。

[Tatsurou]

> CloudFront→ELBへの通信がHTTPだから
↑
こちらは、下記の画像のようにHTTPS Onlyに変更しました。
https://teratail.storage.googleapis.com/uploads/contributed_images/a5b2fe169dfdfe70a0d927675d1b3c5f.png

css jsのパスはなんとか変わってくれました。
ありがとうございます。

ただ、今までのアドバイス通り、
cloudfrontの「origindomainname」には、ELBのドメインを選択しております。
https://teratail.storage.googleapis.com/uploads/contributed_images/a5b2fe169dfdfe70a0d927675d1b3c5f.png

↑ただ、こちらの設定の「origindomainname」を、
下記の画像のように
elb.abcd.work（例）に変更するという事でしょうか。
https://teratail.storage.googleapis.com/uploads/contributed_images/860d6591efcd50486b2b273c22e2dbd3.png

[tsuemura]

> HTTPS Onlyに変更しました
あ、そういうこと出来るんですね。私が無知でした。失礼いたしました。
(elb.abcd.workなどの)サブドメインへの変更は不要だと思います。変更しないとELBにSSLが効かないような気がしていましたので、そう回答してしまいました。

[Tatsurou]

> サブドメインへの変更は不要だと思います。
かしこまりました。では、そのままにいたします。

ただ、気になっているのは、せっかくのcloudfrontなのに、
キャッシュされていないっぽいんですね、、
そこが、もしかすると、サブドメインなどの設定が必要なのかなと思ったり、、

[tsuemura]

Behaviorタブあたりに、Minimum TTL / Maximum TTL / Default TTLなどの設定があると思うので、ドキュメントと格闘してみてください。
http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

[Tatsurou]

返答遅くなりました。
承知致しました。
cloudfrontを見にいっているかの確認が、できなかったので、一旦、諦めようかと思います。
cloudfrontが今、関係しているのかすらわからなくなってきました。。汗

[tsuemura]

わかりました。お力になれず残念です。

[Tatsurou]

SSL証明書で、困っています。質問を追加したので、もし、お分かりになられたらアドバイスいただきたいです。お願いいたします。
https://teratail.com/questions/90480?modal=q-comp

Answer 2

ブラウザの開発者ツールを使って、consoleを開いてみてもらえますか？
その結果次第でお答えできるかもしれないです。

Comments

[Tatsurou]

ありがとうございます。
chromeの開発者ツール、コンソールを開きました。

[Yashichi]

コンソールに何か書かれてたりしますか？

[Tatsurou]

今、質問に、キャプチャを追加しましたので、ご確認いただけますでしょうか。

[Tatsurou]

Security > Security overview
にて、「This page is not secure (broken HTTPS).」と表示されています。

[Yashichi]

ありがとうございます、開発者ツールの"Network"とか"Security"とかの並びにある"Console"の中身を見せていただけますか？

[Tatsurou]

ご確認いただきありがとうございます。
ただ、Consoleを確認しましたが、何も表示されません。

[Yashichi]

ありゃ...
今確認されたのって、ご自分でつくられたWordPressのサイト上のConsoleの値ですよね、すみません、お役に立てないです...(T_T)

[Tatsurou]

はい、、
https://abcd.work という aws ec2で作ったWordPressのサイトを開いてのコンソールです。
http://ではもちろん接続はできるんですが、、