Q&A
クライアント（例えば、ウェブブラウザ）がHTTPまたはHTTPSリクエストを送信するとき、クライアントはエフェメラルポート（動的に割り当てられる一時的なポート）を使用します。このエフェメラルポートは、範囲1024から65535の中で使用されていないポートから自動的に選ばれます
Qiitaの記事が間違ってます。アウトバウンドは80とか443に縛ってはいけません。全開でいいです。セキュリティ的にも問題ありません。
実現したいこと
AWSのバックエンドをwebサイトからHTTPSでfetchしたいです。
発生している問題・分からないこと
ローカルでは完璧にfetchできていたサイトを本番環境にデプロイしたところ、blocked:mixed-content（HTTPSのサイトなのにHTTPでfetchしているぞ）というエラーが出ました。そこで、
AWS EC2上のアプリのhttpリクエストをhttpsにした【初学者】
を参考にAWSのHTTPS化を行いましたが、今度はnet::ERR_SSL_PROTOCOL_ERRORが直りません。
ロードバランサー：
証明書：
DNS設定：
ローカルからHTTPでならfetchでき、HTTPSからのアクセスはそこにリダイレクトしているだけのはずなのですが、何が原因でできないのでしょうか？
エラーメッセージ
error
1net::ERR_SSL_PROTOCOL_ERROR
試したこと・調べたこと
- teratailやGoogle等で検索した
- ソースコードを自分なりに変更した
- 知人に聞いた
- その他
上記の詳細・結果
やったことの詳細をメモします（時系列は一部前後しているかもしれません）
・EC2でapiを立ててローカルからHTTP接続で動作を確認する
・本番サイト（HTTPS）からfetchしたらmixed contentエラーが出る
・fetchするurlをhttps://x.xx.xxx.xx:8000/[api名]にするとエラーがnet::ERR_SSL_PROTOCOL_ERRORに変わる
・当該apiのVPCでApprecationロードバランサーを新規作成しようとする
・ロードバランサーにHTTPおよびHTTPSリスナーを追加
・そのためにSSL証明書が必要と言われたのでサイトと同じドメインについてACM証明書をリクエストし、XServerのDNS設定にCNAMEをコピペして発行
・ターゲットグループが必要と言われたので当該インスタンスをターゲットとするターゲットグループを追加
・２箇所以上のサブネットが必要と言われたので当該VPCにus-east-1c サブネットを追加
・ロードバランサー作成に成功
・HTTPおよびHTTPSリスナーに「到達できません」と表示されていたので、当該セキュリティグループに任意IPからのHTTPおよびHTTPSインバウンドを追加
・Qiitaの記事に従い任意パスからのHTTPアクセスをHTTPSにリダイレクトするルールを追加
・net::ERR_SSL_PROTOCOL_ERRORになる
・ターゲットグループのポートを80から8000にしてみる（Unhealthy解消）
・ドメインをサイトのものではなく、Route53にフィールドを作った完全に新しいものに変えてみる（変化無し）
・セキュリティグループのインバウンドを全許可にしてみる（変化無し）
・fetchするURLの最後を:8000から:443や:80にしてみる（変化無し）
・インスタンスやfast-apiを再起動してみる（変化無し）
コメントありがとうございます。アウトバウンドは元から縛っていません。散漫な質問ですみません。HTTP経由のfetchはできている状態で、HTTPSからのfetchで`net::ERR_SSL_PROTOCOL_ERROR`になる原因は何が考えられますでしょうか？
そもそもSSL証明書が正常に発行されたかどうか文面からは読み取れませんでした。
発行済みになってますでしょうか？
https://dev.classmethod.jp/articles/for-begginer-ssl-communication-by-aws-certificate-manager/
はい、そちらの記事も参考にして作業していました。質問に画像を追加しました。ほかに確認したいパネルがあれば教えてください。
わからないのが、そもそもドメインはこのapiにfetchするサイトと同一でなければならないのか、完全にAWSのためのものでなければならないのか？（どちらも試してできませんでした）
また、fetchするときのurlは独自ドメインの方なのか、もともとのhttps://xx.xxx.xx.xx:8000/[api名]なのか？（どちらも試してできませんでした、そもそも前者はXServerの初期ページに飛ぶ）
紐付けはRoute53にNS欄を売ってレコード作成しなければいけないのか、DNS名をXServerにCNAME転記でよいのか？（どちらも試してできませんでした、そもそも前者はいつまで待てば反映されるのか）
あるいは、よく見るhttps://xxxxx.execute-api.us-east-1.amazonaws.com/xxxxxxにすべきというわけではないのか？
難しいですが勉強したいです、よろしくお願いします
セキュリティグループが一つだけ貼られていますが、これがどこに紐づいているか明確にわかるようなスクリーンショットを追加してください。
コメントを見るにドメイン周りが怪しい気がします。
まず、ALBのエンドポイントにはどこにどうやってレコードを設定しているのでしょうか。
ALBの443リスナーに設定した証明書のドメインとALBにアクセスするドメインが異なれば、証明書は何も証明していることにならないのでもちろんエラーになります。
あと、8000のリスナーがどのように設定されているのかが不明ですが、そもそもいらないと思います。下にあるアプリケーションは普通の80や443に対するアクセスと8000に対するアクセスでは挙動が異なるなら話は別ですが、見る限りおそらくそうではないですよね？（ターゲットグループのポートを8000にしたという表記を見る限り）
あと、DNSをXServerのもののまま扱いたいのかRoute53上で管理したいのかをはっきりさせましょう。
もともとXServerで管理していたなら、それをRoute53で管理するにはちょっと設定が必要です。
そのうえで、管理に使うDNS上でALBのエンドポイントにドメインを指定する必要があります。
> また、fetchするときのurlは独自ドメインの方なのか、もともとのhttps://xx.xxx.xx.xx:8000/[api名]なのか？
前者です。後者はどうやっても証明書のドメインと一致しないので無理です。（IPで証明書を発行することは不可能）
> あるいは、よく見るhttps://xxxxx.execute-api.us-east-1.amazonaws.com/xxxxxxにすべきというわけではないのか？
それはAWSの管理ドメインなのでしたくてもできません。
>blocked:mixed-content
これってウェブブラウザのエラーだと思うのですがfetchって具体的に何をどのようにやっていますか？
>EC2でapiを立ててローカルからHTTP接続で動作を確認する
これが成功するのがおかしいです。
ALBでのSSL化の設定が正しければ https へリダイレクトされるはず
識者が集まってきてくれたのでなにより。
yu_1985さんのコメントで気付いたのですが、ACMで発行した証明書のドメインはXServerの（たぶん、Aレコード）ドメインと一致してますか？ 念のため。
あ、Route53に変えたのか。
もしかしてローカルからHTTPと言ってるのはhttp://x.xx.xxx.xx:8000/[api名]ですか？（x〜の部分はEC2のIP）
それだとALBを経由せずEC2に直接アクセスしているだけなので、ALBに設定した証明書を使ってhttpsでアクセスしたいならALBにアクセスする必要があります。また、前述の通りIPで証明書は発行できないため、IPでのアクセスをhttpsで行おうとすると確実に証明書のエラーが出るはずです。
みなさんご助言ありがとうございます。
＠yu_1985さん
＞セキュリティグループがどこに紐づいているか
スクショを追加しました。証明書は当該ALBのHTTPSリスナーに紐づいています。また、8000のリスナーが不要とのことだったので削除してみました。
＞DNSをXServerのもののまま扱いたいのかRoute53上で管理したいのか
どちらでもできるならXServerのDNSで管理したいです。
＞ALBのエンドポイントにはどこにどうやってレコードを設定している
こちらもスクショを追加しましたが、以下の記事：
https://qiita.com/haru0u0/items/4513b56e883d34b2ea7c
を参考に、CNAMEのペアをDNS設定にコピペして証明書を発行したあと（青）、さらにALBのDNS名のCNAMEレコードを追加しています（緑）。その際、もとから設定されている空ホストのAレコードおよびMXレコードと両立できませんというエラーが出たので、両者を適当なホスト名に設定して避けました（赤）。
＞ローカルからHTTPと言ってるのはhttp://x.xx.xxx.xx:8000/[api名]ですか
そうです。なるほど「https://[ALBに証明書を紐づけたドメイン]/[API名]」にfetchすればよいのですね。現状はCORSエラーが出たり、XServerの初期ページがブラウザで開けたりするのですが、これは反映までのタイムラグなのでしょうか。
＠tabuuさん
＞fetchって具体的に何をどのようにやっていますか
素のJSで
fetch(url, {signal: controller.signal, method: "POST", headers: head, body: JSON.stringify(request)}) .then...
みたいにやっています。APIは自作キーボードの設定ファイルからファームウェアをビルドするもので、知人が作ってくれました。
＠winterboumさん
＞ローカルからHTTP接続で動作確認が成功するのがおかしい
yu_1985さんの仰っていた通り、インスタンスのIPに（ALBを介さず）fetchしていたからかもしれません。http://[独自ドメイン]/[API名]へのfetchは成功していません。
ターゲットグループの対象インスタンスへの接続はHTTPですよね？ HTTPSにしてポート8000にしてないですよね。
はい、HTTPです。
というか、XServerのDNSからやり直して数時間待っていたら、SSL化自体はできたっぽいです！！！
登録したドメインにアクセスするとXServerの初期ページではなくAPIの黒画面になりました。
また、fetchすると即座に出ていた「net::ERR_SSL_PROTOCOL_ERROR」が出なくなりました。
ただ、今度はfetchして１分後くらいに必ず以下のCORSエラーと504が出るようになりました。
1.
Access to fetch at 'https://[fetch先のapiのアドレス]' from origin 'https://[fetch元のサイトのアドレス]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
2.
POST https://[apiのアドレス] net::ERR_FAILED 504 (Gateway Timeout)
もともと３分ぐらいかかるAPIなので、どこで止まっているのかわからないのですが、これもAWSの設定の問題なのでしょうか？
もしAPI側の問題なのであれば、勘違いしていた点を自己解決としてまとめて、このケースはいったん閉じようと思います。
上記、ロードバランサー＞属性＞接続アイドルタイムアウトを60→300秒にしたら解決し、無事APIが開通しmした！！！！
みなさまありがとうございました！！！！
回答1件
0
自己解決
コメントしてくださった複数の方の指摘を参考に、多岐にわたる勘違いを修正した結果、無事開通させることができました：
インスタンスのIPではなく、設定したドメインにfetchする
開発段階ではhttp://xxx.xxx.xx.xx/[API名]にfetchしていたが、これはロードバランサーを通さずにインスタンスに直接アクセスするアドレスである。したがってHTTPS化する際のfetch先のURLは、https://xxx.xxx.xx.xx/[API名]ではなく、https://[ロードバランサーのHTTPSリスナーに証明書を紐づけたドメイン]/[API名]にする。
APIに設定するドメインはフロントエンドと共有してはいけない
ACMの認証は、AWSに「証明書を提供する」ためだけに手持ちのドメインのどれかで適当に済ませれば良いものだと思い、当該APIにfetchする元のwebサイトに使っているドメインで認証していたが、設定するドメインはAPIのfetch先になるものであり、そこへのアクセスは全てAWSへ献上しなければいけない。したがって、どこにも使っていない新しいドメインを設定する。
ドメインへのアクセスをAWSへ向けるDNS設定をしなければいけない
CNAMEレコードを使った認証が発行され、ロードバランサーのリスナーに紐づけても、実際にそこにアクセスできなければ意味がない。したがって、そのドメインに来たアクセスを（既定のwebサイトなどではなく）ロードバランサーへ向けるためのCNAMEレコードをさらに追加しなければならない。
XserverでDNS管理しているドメインの場合の手順：https://qiita.com/haru0u0/items/4513b56e883d34b2ea7c
DNS設定の反映にはタイムラグがある
上記設定をしても、実際にアクセスの振り分けが反映されるには数時間（〜48時間？）かかる。したがって、すぐに変化無しと判断して戻してはいけない。
その他
・ロードバランサーやターゲットグループはVPCをインスタンスのものと揃えなければいけない。
・違う場所からSSH接続するときはセキュリティグループのSSHの「マイIP」を更新しなければいけない。
・インスタンスを再起動したあとはAPIも再起動しなくてはいけない。
・ターゲットグループのポート番号はAPIのポート番号に合わせなくてはいけない。
・リスナーのポート番号をターゲットのポート番号は合わせる必要はない。
・Xserverでドメインを管理しているのに無理にRoute53に明け渡す必要はない。
・１分以上かかるAPIはインスタンスのタイムアウト時間を伸ばさなくてはいけない。
誰もあえて注意書きしないような基本的な部分がわかっておらず、また何がわからないのかもわからない状態で丸投げしてしまいました。最初に取り合ってくださったmike2mike4さん、核となるドメイン周りを明快に説明してくださったyu_1985さんのどちらかにBAを上げたいのですが、これ以上回答をお願いするのも憚られるので自己解決としてケースを終わりたいと思います。
ほかにもコメントをくださったみなさま、ありがとうございました。
投稿2024/08/09 18:16
総合スコア4
あなたの回答
tips
プレビュー
