How to force https on Amazon elastic beanstalk without health checks

Question

I set up the Elastic Beanstalk environment to redirect all pages to https, the redirection works, but the instance does not check the operation and ends, any ideas on setting the rewrite rules?

My configuration:

NameVirtualHost *:80 <VirtualHost *:80> . . . RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule !/_hostmanager/healthcheck https://%{SERVER_NAME}%{REQUEST_URI} [L,R] </VirtualHost> 

Answer 1

There are several hostmananger URLs that need access to an elastic beanstalk, in addition to a health check. Grepping /var/log/httpd/elasticbeanstalk-access_log , I see requests /_hostmanager/tasks and /_hostmanager/healthcheck .

Here are the rules I added to /etc/httpd/sites/elasticbeanstalk in my EC2 instances:

 RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{REQUEST_URI} !^/status$ RewriteCond %{REQUEST_URI} !^/version$ RewriteCond %{REQUEST_URI} !^/_hostmanager/ RewriteRule . https://%{SERVER_NAME}%{REQUEST_URI} [L,R] 

Please note that I also allow traffic other than https to my /status and /version pages. I actually use /status as the actual URL for health checks, so if you skip this traffic, rewriting will avoid redirects and speed up the status search (I assume).

Answer 2

I think some of the other answers here may not be based on what is currently set up by the custom AWS User-Agent . When I look at the Apache logs, I see this User-Agent:

ELB-HealthChecker/1.0

Since writing this, the following mod_rewrite rule has worked for me:

 RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTP_USER_AGENT} !^ELB-HealthChecker.* RewriteRule . https://%{SERVER_NAME}%{REQUEST_URI} [L,R] 

Answer 3

As of 2016, none of these answers work for me, but it worked:

1 Get /etc/httpd/conf.d/wsgi.conf

2 Add the following to the virtual host: (Note that the third line prevents the problem when the script /opt/elasticbeanstalk/hooks/config.py waits 5 minutes without loading the / path.)

 RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTP_HOST} !localhost RewriteCond %{HTTP_USER_AGENT} !^ELB-HealthChecker.* RewriteRule . https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301] 

3 Put the file in your repository and add the following container command:

 06_https: command: "cp wsgi.conf /opt/python/ondeck/wsgi.conf" 

This file is then automatically copied by installing the script in /etc/httpd/conf.d .

Answer 4

AWS Health Checker seems to be using AWSHealthCheck user agent.

I got around this by avoiding forwarding if the request came from the User Agent of the health check agent.

SOmething like:

 RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{USER_AGENT} !^AWSHealthCheck$ RewriteRule . https://%{SERVER_NAME}%{REQUEST_URI} [L,R] 

Answer 5

You can configure ELB to use a specific path to test for health, such as / ping. You can then explicitly tell apache not to redirect this URL, and not rely on the UserAgent string.

You can also tell ELB to use HTTPS for health checks, and then redirect all HTTP URLs to HTTPS, including health checks.

Both of these settings can be changed in the EC2 console under the "Load Balancing" section.

Answer 6

If you are trying to do this in Wordpress or PHP, you can configure your .htaccess as follows without changing anything through .ebextensions:

 <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{REQUEST_URI} !^/status\.html$ RewriteCond %{REQUEST_URI} !^/_hostmanager/ RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L] </IfModule> # BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress 

Remember to change status.html to whatever path you use to test the health of your elastic beanstalk

See my answer here for more details.

Answer 7

Create static health.html. If possible, as a configuration template.

Answer 8

this is a simple solution

• ssh to your EC2 instance
• copy the contents of the /etc/httpd/conf.d/wsgi.conf file to the local wsgi.conf file, which will be placed in the base folder of your application.

• Edit the local version of wsgi.conf and add the following forwarding rules to <VirtualHost> </ VirtualHost Tags>

   RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301] 

• Change "/ status" to any page you use on the health check page.

• Save file

• Edit your <app> .conf inside your ebextensions directory to add a container command to copy this version of wsgi.conf on top of the Amazons version

   container_commands: 01_syncdb: command: "django-admin.py syncdb --noinput" leader_only: true 02_collectstatic: command: "django-admin.py collectstatic --noinput" 03_wsgireplace: command: 'cp wsgi.conf ../wsgi.conf' ... 

• Expand the code.

• The deployed version of wsg.conf at /etc/httd/conf.d/wsgi.conf will now specify the necessary redirection rules.

It should work, and the file will be updated accordingly for each deployment. The only thing you need to pay attention to is that Amazon will change the contents of its base wsgi.conf file in the future, then your copy may stop working.

Autor rickchristianson

Answer 9

For me copying wsgi.conf to a place never worked. Either the EB cannot be deployed, or the file will be overwritten.

The only answer I found that worked was here . Essentially, he used sed to insert the necessary rewrite rules into wsgi.conf . He says the container command added

 container_commands: 01_http_to_https_redirect: command: sed -i '/\<VirtualHost \*:80\>/a RewriteEngine On\nRewriteCond %{HTTP:X-Forwarded-Proto} !https\nRewriteRule \!/robots.txt https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]' /opt/python/ondeck/wsgi.conf 

Remember to change the health check endpoint with robots.txt .

Answer 10

As a general strategy, what worked for us, with the Apache and Nginx EC2 instances located behind the AWS protected load balancer, is:

• On the load balancer, move port 80 to port 80 on instances
• direct port 443 to port 8080 (for example) in instances
• On the web server, listen on both ports (80 and 8080).
• forward port 80 to port 443
• Add the environment variable "HTTPS" with the value "on" in EC2, for example. using elastic beanstalk software configuration.

Step 1 ensures that AWS internal traffic is handled naturally.

Step 2 allows only protected external traffic to reach our code

Step 5 tells the web server and what is behind it (Laravel, in our case) that the generated URL should be provided to the https: scheme. Other frameworks may require some other environment variables set in order to cause this behavior.

Answer 11

This answer assumes that you have already enabled https in the load balancer security group, added the SSL certificate to the load balancer, added 443 to the ports redirected by the load balancer, and entered your domain name in Elastic Beanstalk using Route 53 (or equivalent DNS) .

All you have to do is add the following to one of the .conf 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> 

Description

It is moderately right outside the elastic beanstalk. Typically an Apache rewrite rule is added, for example:

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

Or, if behind the load balancer, as in this case:

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

However, these configurations only work in the <VirtualHost> block. Changing the RewriteCond block to <If> allows us to work correctly outside the <VirtualHost> block, which allows us to insert a standalone Apache configuration file. Please note that the standard Apache installation on CentOS (including the setting on ElasticBeanstalk) includes all files corresponding to /etc/httpd/conf.d/*.conf , which correspond to the path of the file in which we store this file.

Part of the condition -n '%{HTTP:X-Forwarded-Proto}' prevents redirection if you are not behind a load balancer, which allows you to have a common configuration between a production environment with a load balancer and https and an intermediate environment, which is a single instance and does not have https. This is not necessary if you use load balancers and https in all your environments, but it doesn’t hurt.

Bad decisions I've seen

I have seen many bad solutions to this problem, and it is worth reading them to understand why this solution is necessary.

• Use Cloudfront:. Some people suggest using Cloudfront's non-cached configuration before Elastic Beanstalk to redirect HTTP to HTTPS. This adds a whole new service (which adds complexity), which is not entirely suitable (Cloudfront is a CDN, it is not the right tool to force HTTPS for inherited dynamic content). Apache configuration is the normal solution to this problem, and Elastic Beanstalk uses Apache so we can go.

• SSH to the server and ...: This completely contradicts the Elastic Beanstalk point and has so many problems. Any new instances created by autoscaling will not have a modified configuration. Any cloned environment will not be configured. Any amount of a reasonable set of environmental changes will destroy the configuration. This is such a bad idea.

• Overwrite Apache configuration with a new file: This falls into the correct area of ​​the solution, but leaves you with a maintenance nightmare if Elastic Beanstalk changes server configuration aspects (which they can very well do). Also see Problems in the next item.

• Dynamically edit the Apache configuration file to add a few lines: This is a good idea. The problem with this is that it will not work if Elastic Beanstalk ever changes the name of its default Apache configuration file and that this file can be overwritten when you least expect it: https: //forums.aws.amazon. com / thread.jspa? threadID = 163369