In the deployment scenario I am using, there is a single ELB, balancing multiple EC2 instances, serving a multi-domain system. Since ELB doesn't support multiple SSL certificates on HTTPS, ELB port 443 is configured as TCP 443, which points to port 9443 on EC2 instances (with Proxy Protocol enabled).
This way installing multiple SSL certificates using a single ELB is possible, as described in this blog post.
The problem now is that stickiness policy cannot be associated only with a listener with HTTPS as frontend protocol.
However, I cannot use HTTPS as frontend protocol, because of the multiple domains/SSL certificates point made above.
What would be the best way to handle the issue?
As it was suggested by #Castaglia, I ended up with configuration of separate ELBs, one for each domain/certificate pair.
In the auto scaling configuration, you have option to specify multiple ELBs.
Related
Greetings!!
I am using an EC2 machine and running an application in 3000 port in EC2. We have created an autoscaling group and added an Elastic load balancer to it.
I want to use HTTPS connection. Instead of using SSL certificate, we have added a Cloudfront. Cloudfront provides the HTTPS url. In Security group we have opened PORT 80, 443 and 3000
Please help me, is there any best way to achieve this requirement.
I want to use HTTPS connection. Instead of using SSL certificate, we have added a Cloudfront. Cloudfront provides the HTTPS url. In Security group we have opened PORT 80, 443 and 3000
Please help me, is there any best way to achieve this requirement.
As you already have an ELB, you can use AWS ACM to get free SSL & attach to your ELB. This way you get HTTPS
I have the following beanstalk environment: https(443) -> ALB -> http(80) to instance.
ALB listener accept only HTTPS request and authenticate with SSL certificate and then process to default port 80.
Everything works fine but I wonder if is it also possible to redirect HTTP port 80 requests back to ALB HTTPS listener without the need to support HTTPS on the instance?
When I tried to create redirect process it failed since it tried health-check on port 443 and the instance doesn't support it.
P.S. Is it a security issue if authentication done only in ALB and it communicate instances on port 80? (Instance security group accept requests only from ALB)
The redirection from port HTTP to HTTPS is best set using EC2 console, not EB console. For that you have to go to EC2 console-> Load Balancers.
Then you can modify the existing rule on HTTP:80 listener from Forward to Redirect as shown below:
The above change should not affect any of your health checks.
Is it a security issue if authentication done only in ALB and it communicate instances on port 80?
Yes. This is how it is most commonly done. The HTTP traffic between ALB and your instances traverses only AWS network, not the internet. So its safe from public eyes. But obviously, you can still setup HTTPS between ALB and the instances, but this requires extra work and puts more stress on your instances as they now have to handle SSL encryption and decryption as well.
AWS Network Load Balancers support TLS termination. This means a certificate can be created in AWS Certificate Manager and installed onto a NLB and then TCP connections using TLS encryption will be decrypted at the NLB and then either re-encrypted or passed through to a non-encrypted listener. Details are here: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html.
The benefits of using AWS Certificate Manager are that the certificate will be managed and rotated automatically by AWS. No need to put public-facing certificates on private instances.
I'd like to route TCP connections to the NLB based on the SNI, i.e. connections to the same port and IP can be routed to different targets based on the server name that was requested by the client. Whilst I can see that multiple TLS certificates for a given listener are supported using SNI to determine which certificate to serve up, I don't see how to configure listeners based on SNI.
I have therefore put HAProxy behind a NLB and want to route to different backends using SNI. I terminate TLS with the client at the NLB, reencrypt the traffic between NLB and HAProxy using a self-signed certificate on HAProxy, then route to the backends using unencyrpted TCP.
(client) --TLS/TCP--> (NLB on port 443) --TLS/TCP--> (AWS target group on port 5000, running HAProxy) --TCP--> backends on different IPs/ports
Does AWS NLB pass through the SNI details to the target groups?
If I connect directly to HAProxy (not via NLB) then I can route to the backend of choice by using SNI, but I can't get the SNI routing to work if I connect via the NLB.
According to this SO answer and to the istio docs, if you terminate TLS on the load balancer it won't carry SNI to the target group. I had the exact same issue and I ended up solving it by setting the host as '*' on the ingress Gateway and then specifying the hosts on the different VirtualServices (as recommended here).
I think that this solution could also work but didn't tried it. You would have to set the certificate on istio Gateway secret and do a TLS pass through on the NLB, but then you can't use the AWS ACM SSL certificates as pointed out on the previous link.
I have an EC2 Instance which is having multiple virtual hosts and serve different websites on different domains. (Let say ABC.com, DEF.com, XYZ.com)
For one specific domain let say ABC.com, its running on HTTP. I have been given free credit from AWS. Now I want to run this ABC.com on https without spending any money.
So I have decided to use ELB as it will come with a free SSL. And I want to target that to ABC.com on my EC2 instance.
I know that with ELB I can target to my instance or my IP. Is it possible to target just one virtual host somehow as this website is not my primary website on a server?
ELB is using Listeners. Every listener has:
inbound port - in which you can connect to the ELB
target port - the host on the machine you transfer traffic to
If you're ABC.com can use a different port (let's say 8081) than DEF.com, XYZ.com it will be possible to create a listener that listens on port 443 - SSL and configured to send the traffic to port 8081.
You can potentially achieve this via Application Load Balancer using Host Based Routing. Different Target Groups can listen on different ports (HTTP / HTTPS).
Host-Based Routing Support for AWS Application Load Balancers
I'm using Amazon ELB and have https setup with a certificate, however I need to support many domains (several thousand). Is there a way to have an ELB forward port 443 to the resolving EC2 instance(s) and let them handle https? or would there be an alternative way to support this? From what I've seen it looks like you can only one listener to 443 with a single certificate associated.
It is possible to do this now.
You need AWS ACM certificates. Assuming you already have one:
Select your load balancer and Under "Listeners", check the https listener and open the certificate selector on "View/edit certificates".
Then in the selection menu use the '+' or '-' buttons to add or remove ACM certificates from said balancer:
The short answer to your question is no, an ELB can only have 1 associated certificate. Assuming you aren't in a situation where a wildcard cert would work (e.g. *.example.com) you won't be able to use ELB the way that the GUI makes it seem like it should work. This is because ELB does not support SNI which is what makes something like apache able to bind multiple SSL domains to a single host.
That said, there is a workaround. You can forward 443 through your ELB directly to the assigned server. This is done by setting up port 443 in TCP pass-through mode rather than in HTTPS mode. To do that:
Go to the AWS console and select the ELB you want to edit.
Choose "Listeners" tab.
Select "Edit"
Change the "Load Balancer and Instance Protocols to "TCP" (see screenshot)
Set the Load Balancer and Instance Ports to 443
Alternatively, if you don't yet have an HTTPS listener, choose "Add" in step 3.
Note, setting it up this way will force your EC2 Instances to encrypt/decrypt traffic which will be an additional load on your EC2 CPU.