I am following the these instructions for enabling HTTPS on the EC2 instance managed by Elastic Beanstalk. I can see that Elastic Beanstalk creates the /etc/pki/tls/certs/server.crt & /etc/pki/tls/certs/server.key files. However, Elastic Beanstalk is not creating the /etc/httpd/conf.d/ssl.conf file. Manually creating the /etc/httpd/conf.d/ssl.conf file, post environment creation, does enable HTTPS though. I am using Apache server.
P.S. I had to change line 3 to mod_ssl : [] (original was mod24_ssl : [])
You are following instruction for EB platform based on Amazon Linux 1 (AL1). However, it seems that you are using platform based on AL2, where proxy (httpd or nginx) are setup differently then on AL1. Specifically, they should be in .plaftorm folder, not .ebextentions. From docs:
Configuration file location – You should place proxy configuration files in the .platform/nginx and .platform/httpd directories on all Amazon Linux 2 platform versions.
Further details how to setup httpd on AL2 platforms are in Configuring Apache HTTPD.
Related
It is a security best practice to disable TLS Renegotiation in production.
What is the best way to do this in an Apache2-based Elastic Beanstalk Deployment (Python/Django)?
To disable TLS Renegotiation in Amazon Elastic Beanstalk for Linux AMI, you can modify the Apache configuration file. Here's the steps:
Step 1 : Connect to your EC2 instance using SSH.
Step 2 : Open the Apache configuration file using a text editor:
sudo nano /etc/httpd/conf.d/ssl.conf
Step 3 : Add the following line to the end of the file:
SSLInsecureRenegotiation off
Step 4 : Save and close the file.
Step 5 : Restart Apache to apply the changes by typing:
sudo service httpd restart
I have a NodeJS API application running on a single instance (no load balancer) on AWS Elastic Beanstalk. Previously the app was on the old Amazon Linux environment which was deprecated, so this is now just freshly created in a brand new "Node.js 16 running on 64bit Amazon Linux 2/5.6.0" environment. I verified the new environment is up and running properly and now the domain is pointing to the new version. When using normal HTTP traffic the application responds normally.
The previous version had SSL enabled. The certificate purchased a year ago was just reissued for another year (from NameCheap - third-party CA). I generated the new cert/key per NameCheap's instructions. To configure EB for using SSL, I followed these instructions from Amazon exactly: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/https-singleinstance-nodejs.html And currently have the contents of the cert, the ca_bundle, and the private key in my .ebextensions/https-instance.config file (just to get it working... for production this would reference files on S3). I ran the contents through a YAML formatter to make sure the spacing was correct.
While my application responds OK without HTTPS, if I simply add the S I get ERR_CONNECTION_REFUSED. I've looked through all the logs available from Elastic Beanstalk and there are no errors.
How can I get more detail on why the traffic is not forwarding? How would I be able to determine if the problem is the certificate, or the key, or some other error in a config file, etc?
I'm switching from nginx to Caddy so I set up Caddy and created a new AMI. When I deploy this AMI to my EB environment, it fails to launch because nginx fails to start during the launch.
Using EB platform Ruby 2.7 running on 64bit Amazon Linux 2, how is it possible to prevent nginx from launching?
If you choose to modify the default AMI, and not create a new one, then ...to override the Elastic Beanstalk nginx configuration, add the following line to your nginx.conf per AWS documentation, do the above "...to pull in the Elastic Beanstalk configurations for Enhanced health reporting and monitoring, automatic application mappings, and static files."
Have a look here... I posted some of those copied sample snippets for you below to walk you through,
a) you would setup your daemon by overriding the nginx default config,
then b) tell the overridden ngix config to look for Caddys extensions
c) and that extension would read its config file
// this where you over ride nginx config
include conf.d/elasticbeanstalk/*.conf;
a) For e.g. Configuring Apache HTTPD
The Tomcat, Node.js, PHP, and Python platforms allow you to choose the Apache HTTPD proxy server as an alternative to nginx. This isn't the default. The following example configures Elastic Beanstalk to use Apache HTTPD.
Example, here we replace the reverse proxy with apache .ebextensions/httpd-proxy.config (you try caddy)
option_settings:
aws:elasticbeanstalk:environment:proxy:
ProxyServer: apache
Background:
By default it ships with Nginx as the reverse proxy on port 80 to find your app. on EBS. So, you have two options a 1) new Custom AMI or 2) Modifying your AMI
"...Proxy configuration files provided in the .ebextensions/nginx directory should move to the .platform/nginx platform hooks directory. For details, expand the Reverse Proxy Configuration section in Extending Elastic Beanstalk Linux platforms."
Then look at predeploy and postdeploy config options here
As it is currently not possible to configure an application loadbalancer using the Elastic Beanstalk UI, I have managed configuring an ALB using .ebextensions/*.config files as described here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-applicationloadbalancer.html
Unfortunately, this leads to my application bundle having all configuration including the ARN of AWS Certificate Manager hard coded, so my application bundle cannot be used for different domains / regions. How can I cleanly separate the application loadbalancer configuration from my application bundle, or is this the wrong approach at all?
I'm a pretty new developer and deployed my first Django app via Elastic Beanstalk. I want to serve https requests and have configured my SSL certificate and have my load balancer set up correctly. When I go into EB > Configuration > Secure listener port and set it to 443 I'm getting the error upon saving:
LoadBalancerHTTPSPort: You have specified both the #deprecated(:default.aws:elb:loadbalancer:LoadBalancerHTTPSPort)
option as well as one in the new aws:elb:listener:443 namespace.
The :default.aws:elb:loadbalancer:LoadBalancerHTTPSPort option will be ignored.
Not sure what I'm missing because I'm still not able to serve https requests
I had the same problem with a NodeJS Elastic Beanstalk app. However, I was able to get around it by updating the Listener/Certificate settings via the AWS EC2 console (https://console.aws.amazon.com/ec2/), via the Load Balancers section (under LOAD BALANCING).
I was updating the certificate for a staging version of a cloned environment. This was the only way I could assign a different certificate to the staging environment.
See more at http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-create-https-ssl-load-balancer.html