Bei dieser Antwort wird davon ausgegangen, dass Sie bereits https in der Load Balancer-Sicherheitsgruppe aktiviert, das SSL-Zertifikat zum Load Balancer hinzugefügt, beide Ports 80 und 443 vom Load Balancer weitergeleitet haben und Ihren Domänennamen auf die Elastic Beanstalk-Umgebung mit Route 53 verwiesen haben (oder gleichwertiger DNS-Dienst).
HINWEIS: Diese Antwort gilt für Elastic Beanstalk-Umgebungen, die Apache verwenden. Bei einer Docker-basierten Bereitstellung funktioniert dies möglicherweise nicht.
Sie müssen lediglich Folgendes zu einer Ihrer .configDateien im .ebextensionsVerzeichnis Ihres Projekts hinzufügen :
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>
Erläuterung
Dies ist außerhalb von Elastic Beanstalk mäßig einfach. Normalerweise fügt man eine Apache-Umschreiberegel wie die folgende hinzu:
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Oder wenn wir uns hinter einem Load Balancer befinden, wie wir es in diesem Fall sind:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
Diese Konfigurationen funktionieren jedoch nur innerhalb eines <VirtualHost>Blocks. Wenn Sie das RewriteCondin einen <If>Block ändern, funktioniert es außerhalb eines <VirtualHost>Blocks ordnungsgemäß , sodass wir es in eine eigenständige Apache-Konfigurationsdatei einfügen können. Beachten Sie, dass das Standard-Apache-Setup unter CentOS (einschließlich des Setups unter ElasticBeanstalk) alle übereinstimmenden Dateien enthält /etc/httpd/conf.d/*.conf, die dem Dateipfad entsprechen, in dem wir diese Datei speichern.
Der -n '%{HTTP:X-Forwarded-Proto}'Teil der Bedingung verhindert, dass sie umgeleitet wird, wenn Sie sich nicht hinter einem Load Balancer befinden. Auf diese Weise können Sie eine gemeinsame Konfiguration zwischen einer Produktionsumgebung mit einem Load Balancer und https und einer Staging-Umgebung mit einer einzelnen Instanz und ohne https durchführen. Dies ist nicht erforderlich, wenn Sie Load Balancer und https in all Ihren Umgebungen verwenden, aber es tut nicht weh, sie zu haben.
Schlechte Lösungen habe ich gesehen
Ich habe viele schlechte Lösungen für dieses Problem gesehen, und es lohnt sich, sie durchzugehen, um zu verstehen, warum diese Lösung notwendig ist.
Cloudfront verwenden: Einige Benutzer empfehlen die Verwendung eines nicht zwischengespeicherten Cloudfront-Setups vor Elastic Beanstalk, um die HTTP-zu-HTTPS-Umleitung durchzuführen. Dies fügt einen völlig neuen Dienst hinzu (wodurch die Komplexität erhöht wird), der nicht genau angemessen ist (Cloudfront ist ein CDN; es ist nicht das richtige Tool, um HTTPS für inhärent dynamische Inhalte zu erzwingen). Die Apache-Konfiguration ist die normale Lösung für dieses Problem, und Elastic Beanstalk verwendet Apache. Deshalb sollten wir diesen Weg gehen.
SSH in den Server und ...: Dies ist völlig entgegengesetzt zu Elastic Beanstalk und hat so viele Probleme. Neue Instanzen, die durch automatische Skalierung erstellt wurden, haben keine geänderte Konfiguration. In geklonten Umgebungen ist die Konfiguration nicht vorhanden. Eine beliebige Anzahl angemessener Umgebungsänderungen löscht die Konfiguration. Das ist einfach so eine schlechte Idee.
Überschreiben Sie die Apache-Konfiguration mit einer neuen Datei: Dies führt zum richtigen Lösungsbereich, führt jedoch zu einem Alptraum bei der Wartung, wenn Elastic Beanstalk Aspekte des Server-Setups ändert (was sehr gut möglich ist). Siehe auch die Probleme im nächsten Punkt.
Bearbeiten Sie die Apache-Konfigurationsdatei dynamisch, um einige Zeilen hinzuzufügen: Dies ist eine anständige Idee. Das Problem dabei ist, dass es nicht funktioniert, wenn Elastic Beanstalk jemals den Namen der Standard-Apache-Konfigurationsdatei ändert, und dass diese Datei überschrieben werden kann, wenn Sie es am wenigsten erwarten: https://forums.aws.amazon.com/thread .jspa? threadID = 163369