假設您已在負載平衡器安全組中啟用https，將SSL證書添加到負載平衡器，將443添加到負載平衡器轉發的端口，並使用Route 53將您的域名指向Elastic Beanstalk環境(或等效DNS服務)。它還假定您沒有使用基於docker的部署

所有你需要做的是將以下內容添加到您的一個.config files in the .ebextensions directory of your project：

files:
    "/etc/httpd/conf.d/ssl_rewrite.conf":
        mode: "000644"
        owner: root
        group: root
        content: |
            RewriteEngine On
            
 
<If "-n ‘%{HTTP:X-Forwarded-Proto}‘ && %{HTTP:X-Forwarded-Proto} != ‘https‘">
            RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
            </If>

這在Elastic Beanstalk外是適度直接的。通常會添加一個Apache重寫規則，如下所示：

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
 

或者，如果在負載均衡器後面，就像我們在這種情況下：

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

然而，這些配置僅在< VirtualHost>塊。將RewriteCond改變為< If>塊允許它在< VirtualHost>塊，允許我們放入一個獨立的Apache配置文件。請註意，CentOS上的標準Apache設置(包括ElasticBeanstalk上的設置)包括所有匹配/etc/httpd/conf.d/*.conf的文件，這與我們存儲此文件的文件路徑相匹配。

條件的-n’％{HTTP：X-Forwarded-Proto}’部分阻止它重定向，如果您不在負載平衡器後面，允許您在生產環境與負載平衡器和https之間共享配置，一個臨時環境是單實例，沒有https。如果您在所有環境中使用負載平衡器和https，這不是必需的，但它不會受到傷害。

我見過的壞解決方案

我看到了很多壞的解決方案，這個問題，值得通過他們來了解為什麽這個解決方案是必要的。

>使用Cloudfront：有些人建議在Elastic Beanstalk之前使用非緩存的Cloudfront設置來執行HTTP到HTTPS重定向。這增加了一個不完全合適的全新服務(因此增加了復雜性)(Cloudfront是一個CDN;它不是對繼承動態內容強制使用HTTPS的正確工具)。 Apache配置是這個問題的正常解決方案，Elastic Beanstalk使用Apache，所以這是我們應該去的方式。
> SSH到服務器和…：這是完全對立的Elastic Beanstalk的點，並有這麽多的問題。通過自動擴展創建的任何新實例將不具有修改的配置。任何克隆的環境將不具有配置。任何數量的合理設置的環境更改都將擦除配置。這只是一個壞主意。
>用一個新文件覆蓋Apache配置：這是進入正確的解決方案領域，但如果Elastic Beanstalk改變了服務器設置的方面(他們很可能做的)，那麽會給你帶來維護噩夢。也看到下一個項目中的問題。
>動態編輯Apache配置文件以添加幾行：這是一個不錯的想法。這樣做的問題是，如果Elastic Beanstalk更改其默認Apache配置文件的名稱，並且該文件可以被覆蓋，當你最不期望的時候它不會工作：https://forums.aws.amazon.com/thread.jspa?threadID=163369

原文：https://codeday.me/bug/20171210/105195.html

How to force https on amazon elastic beanstalk