横やり失礼します。
環境変数を任意で設定したい場合は.env.distではなく、.envファイルを修正すれば認識されると思います。

ちなみに、アプリ側に常にSSLと認識されて構わない場合は
.envに「HTTPS=true」と追記してしまえば、php側で常にSSLであると認識してくれるようです。

自分の環境(nginxでバーチャルホスト＋リバプロ)ではホスト名も正しく認識されなかったため、
HTTP_HOST=ec.moeland.moe(実際のドメイン名)
HTTPS=true
を追記したところ上手くいっています。

よろしくお願いいたします。

引用：

.env.distの上記箇所のコメントアウトを外しましたが、特に変化ありません。
（example.comの箇所を、サイトのFQDNに変更しても同様に変化ありませんでした）

$_SERVER['TRUSTED_PROXIES']、$_SERVER['TRUSTED_HOSTS']となるよう、ヘッダーを付与しようと思ったのですが、上手くいきませんでしたので下記のように書き換えました。（あまり良い方法ではないかと思いますが・・・）

./index.php

Line: 45
$trustedProxies = isset($_SERVER['TRUSTED_PROXIES']) ? $_SERVER['TRUSTED_PROXIES'] : false;
↓
$trustedProxies = isset($_SERVER['TRUSTED_PROXIES']) ? $_SERVER['TRUSTED_PROXIES'] : '127.0.0.1';

Line: 50
$trustedHosts = isset($_SERVER['TRUSTED_HOSTS']) ? $_SERVER['TRUSTED_HOSTS'] : false;
↓
$trustedHosts = isset($_SERVER['TRUSTED_HOSTS']) ? $_SERVER['TRUSTED_HOSTS'] : 'localhost,サイトのFQDN';

※もっとスマートな方法があればよかったのですが・・・＾＾：

情報、ありがとうございました。

以下の環境変数を設定することで、使えるようになりませんか？？
TRUSTED_PROXIES=127.0.0.1,127.0.0.2
TRUSTED_HOSTS=localhost,example.com

すみません。
こちらのスレッドの質問主様は自己解決されていらっしゃるのですが、同様の現象が起こっておりますのでご相談させていただければと投稿しております。

当方環境として、nginxをリバースプロキシとして利用しており、SSL証明書はnginx側へ設定、Apacheへは8080ポートを使用してForwardかけております。
既にSSL環境が構築済の状態にてEC-CUBE4のインストールを実行すると、「httpsからの接続でなければSSL制限を設定できません。」とエラーとなり、SSL強制の設定ができないようになってしまっています。

ECCUBE_FORCE_SSLが影響しているようなので、.env.dist、eccube.yamlの当該項目をtrueへ変更してみましたが、変化がありません。

SymfonyでのisSecureを使用してhttps判定しているようですが、このメソッドで使用しそうなヘッダーはnginxにて設定済です。

以下、関係ありそうなヘッダー設定（nginx）
--------------------------------------------
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
--------------------------------------------


引用：

こちら、具体的にどのあたりとなるのでしょうか？
強制SSL化できないため、管理画面のリンク等がすべてhttp://となっており、Chromeでワーニングが出ます。

EC-CUBEしか入れていないサーバであればnginxでのリバースプロキシそのものを諦めてもよいのでしょうが、Mattermostを同サーバへインストール済であり（こちら、Apache以外のWEBサーバとなります）リバースプロキシが必要となってしまっています。
Apacheでのリバースプロキシは正直しんどいですし、折角nginxでSSLアクセラレーションを行えるのでこれを諦めるのも惜しいです。

サーバーの環境担当に確認したところHTTPSをtcp/80にプロキシしており、
これをやめたところ正常にHTTPS化できました。

SymfonyなのかEC-CUBEなのかはわかりませんが
80ポートはhttpへルーティングしているのだと思います。

こちらの設定ミスで発生していたことでした。。
お騒がせしてすみませんでした。。

手元にELBを利用していないEC2が無いので、検証できないのですが、
確認いただいた状態というのは、
apache側の設定は何もしていない状態で、.envのみ設定されたという事でよかったですか？

キャッシュのクリアは、管理画面のコンテンツ管理から操作されましたか？
(サーバのファイル操作でcacheディレクトリ内を削除しても反映されませんでした。多分、私が削除したファイルが間違っているのだと思いますが...)
私の環境（AWSでは無い）では、上記キャッシュクリアの操作後から、httpsに正常に遷移するようになりました。

----------------
株式会社シロハチ
■ECCUBE2系、3系構築カスタマイズご相談ください。
■EC-CUBE3マニュアル
■blog

ELBは利用していません。
AWS内部でNATによりIPの変換が行われているようですが、それの影響でしょうか？

もしかしてELBをご利用ですか？
あと、SSL証明書はELBにインストールされていますか？
上記の場合、インターネットとELBはSSL通信となりますが、
ELBとWEBサーバは普通のhttp通信となる為、誤動作するかもしれません。
（eccube自体がhttps通信を認識できない）

3系の時にも同じところで問題があって、判定を直した記憶があるのですが、
4系もリダイレクトを行う箇所の判定を修正する必要があるのかもしれません。
一度、確認してみたいと思います。

----------------
株式会社シロハチ
■ECCUBE2系、3系構築カスタマイズご相談ください。
■EC-CUBE3マニュアル
■blog

468 様

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

同様にやってみたのですが、上手く行かず、
trusted_proxies等を設定してみても上手く行きませんでした。

AWSの問題なのか、よく分かりませんが、
似たような環境で上手く動作した方がいらっしゃれば
お教え頂けると幸いです。

私も同じところでハマったのですが、
.envでECCUBE_FORCE_SSL=trueに設定した後、キャッシュのクリアが必要なようです。
管理画面にログインしておいて、
.envの設定を書き換えた後、キャッシュをクリアしてみてください。

私の場合は、それで問題は解消しました。

----------------
株式会社シロハチ
■ECCUBE2系、3系構築カスタマイズご相談ください。
■EC-CUBE3マニュアル
■blog