Esta respuesta supone que ya habilitó https en el grupo de seguridad del balanceador de carga, agregó el certificado SSL al balanceador de carga, el balanceador de carga reenvió los puertos 80 y 443 y apuntó su nombre de dominio al entorno Elastic Beanstalk con Route 53 (o servicio DNS equivalente).
NOTA: Esta respuesta es para entornos de Elastic Beanstalk que usan Apache. Es posible que no funcione para una implementación basada en Docker.
Todo lo que necesita hacer es agregar lo siguiente a uno de sus .configarchivos en el .ebextensionsdirectorio de su proyecto :
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>
Explicación
Esto es moderadamente sencillo fuera de Elastic Beanstalk. Por lo general, se agrega una regla de reescritura de Apache como la siguiente:
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
O, si está detrás de un equilibrador de carga, como estamos en este caso:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
Sin embargo, estas configuraciones solo funcionan dentro de un <VirtualHost>bloque. Cambiar RewriteConda un <If>bloque permite que funcione correctamente fuera de un <VirtualHost>bloque, lo que nos permite instalar un archivo de configuración de Apache independiente. Tenga en cuenta que la configuración estándar de Apache en CentOS (incluida la configuración en ElasticBeanstalk) incluye todos los archivos que coinciden /etc/httpd/conf.d/*.conf, lo que coincide con la ruta del archivo donde almacenamos este archivo.
La -n '%{HTTP:X-Forwarded-Proto}'parte de la condición evita que se redirija si no está detrás de un equilibrador de carga, lo que le permite tener una configuración compartida entre un entorno de producción con un equilibrador de carga y https, y un entorno de prueba que es de instancia única y no tiene https. Esto no es necesario si está utilizando balanceadores de carga y https en todos sus entornos, pero no está de más tenerlo.
Malas soluciones que he visto
He visto muchas malas soluciones a este problema, y vale la pena analizarlas para entender por qué es necesaria esta solución.
Use Cloudfront: algunas personas sugieren usar la configuración de Cloudfront sin caché frente a Elastic Beanstalk para realizar la redirección de HTTP a HTTPS. Esto agrega un servicio completamente nuevo (lo que agrega complejidad) que no es exactamente apropiado (Cloudfront es una CDN; no es la herramienta adecuada para forzar HTTPS en contenido inherentemente dinámico). La configuración de Apache es la solución normal a este problema y Elastic Beanstalk usa Apache, así que ese es el camino que debemos seguir.
SSH en el servidor y ...: Esto es completamente antitético hasta el punto de Elastic Beanstalk y tiene muchos problemas. Las instancias nuevas creadas mediante el ajuste de escala automático no tendrán la configuración modificada. Los entornos clonados no tendrán la configuración. Cualquier cantidad de un conjunto razonable de cambios ambientales eliminará la configuración. Esta es una mala idea.
Sobrescriba la configuración de Apache con un nuevo archivo: esto está entrando en el ámbito correcto de la solución, pero lo deja con una pesadilla de mantenimiento si Elastic Beanstalk cambia aspectos de la configuración del servidor (lo que muy bien pueden hacer). Consulte también los problemas en el siguiente elemento.
Edite dinámicamente el archivo de configuración de Apache para agregar algunas líneas: esta es una idea decente. El problema con esto es que no funcionará si Elastic Beanstalk alguna vez cambia el nombre de su archivo de configuración Apache predeterminado, y que este archivo se puede sobrescribir cuando menos lo espera: https://forums.aws.amazon.com/thread .jspa? threadID = 163369