My load balancer is responsible for two backend services. When the load balancer has the default URL mapping, the SSL certificate works fine. Unfortunately, I want to route all paths with /api/* to different backend service and doing so messes with https for my website.
After this change, the HTTPS on the address bar is slashed and my website is not secure.
Related
One ACM was issued to *.example.com. With this, it was applied to public route 53 called example.com as CNAME, and two load balancers were connected using it. The two load balancers ran front and back-end services, respectively.
However, the problem is that the frontend was applied with https, but the backend was not applied.
The domain of the backend is, for example, api.example.com, which was accessible to both http and https.
I redirected HTTP 80 to HTTPS 443 on the back-end load balancer, but why didn't it apply?
The front end is redirected to https even if it is accessed through http.
Record A was given 'api.example.com' and the backend load balancer is equally http 80 redirect https 443.
However, if you access through http, you can see a server that does not display ssl authentication, and if you access through https, you can see a server that shows ssl authentication.
Naturally, it was set to 80 redirect 443 forward.
Check the backend load balancer if it has an SSL cert associated with it.
When you associate Route53 with an ACM SSL cert, it only validates the ownership of the domain. Route53 is a DNS service, it does not participate in SSL encryption. It is the load balancer's job in your topology.
Also, you can use an Alias record instead of CNAME to route to load balancers deployed on AWS; then the Route53 DNS calls are free. (I was not sure whether the CNAME record you mentioned was the actual routing record or just the validation one, so decided to mention that.)
I have setup a GCP load balancer following the steps as displayed on https://cloud.google.com/load-balancing/docs/https/ext-http-lb-tf-module-examples#with_a_backend . I have create an A record at my dns provider and I am succesfully able to reach my service through the domain name. I have also created a http to https redirecting load balancer, which only redirects when visiting the domain name.
However my problem is that I can also still directly access my load balancers ip adress over http, which in turn redirects to my backend service thus allowing insecure access to my service. I am not sure what steps there are to debug my configurations or if anyone has experienced something similar.
The simplest method is to redirect HTTP to HTTPS at your backend. That method provides you with more options and control.
Tip: if the client arrives at an IP address, you most likely want to discard that traffic. That traffic is typically hackers, trolls, etc.
You can also set up a redirect in the load balancer:
Set up an HTTP-to-HTTPS redirect for global external HTTP(S) load balancer
I made a AWS Load Balancer for a simple ECS fargate server (with flask). Because the server will be used as my main server's api, and because the main server use 'https', I have to use https on my Load Balancer's url.
But when I want to make SSL certificate using ACM, I can't verify the URL of Load Balancer is mine because the load balancer has any information (I think).
If I add my email info on the url(or Load Balancer), I can do this, but I have no idea..
Until now, I thought using AWS Route 53 can help me, but I don't know what I have to do.
What Can I do for this problem?
To use ACM you need to have control of the domain you're attempting to validate, as the load balancer URL is owned by Amazon (not yourself), only an Amazon employee with domain control is capable of performing the actions to validate the domain.
Instead you would need to generate an ACM certificate for your own domain which you can validate, you would then need to add a DNS record resolving the domain to the CNAME of the load balancer. When you access in the browser you would need to access from that domain and not the load balancers.
I am trying to setup HTTPS across my app which consists in a frontend (S3 bucket distributed with CloudFront), and a backend (node.js app inside Elastic Beanstalk).
For the CloudFront part, I created an SSL certificate in N. Virginia (apparently I don't have a choice here) and I made the binding in the CloudFront distribution. It works and my app is served over HTTPS.
For the Elastic Beanstalk part, I created an SSL certificate in Ireland (where my EBS app is hosted) and I bound this certificate to the EBS load balancer using the port 443. It works and I can reach my server with HTTPS using Postman.
However, when my frontend tries to make an API call to the backend I get this error :
I guess I made a mistake while creating the certificates, but I cannot find it. I gave both certificates the same set of CNAMES, I am not sure if I am supposed to do that.
EDIT :
I get the exact same error after updating the frontend so that it points the DName of the load balancer (also mapped to subdomain with Route 53).
CloudFront is attempting to load an HTTPS URL from your load balancer. I assume you have an SSL certification assigned to the load balancer. The domain name of the SSL certificate on the load balancer needs to match the domain name that CloudFront is requesting.
For example if the load balancer's SSL certificate is something like beanstalk.mydomain.com then CloudFront would need to be making requests for https://beanstalk.mydomain.com. The error CloudFront is giving you says that the domain name of the SSL certificate served by the load balancer does not match the domain name djumbo-back-debug.eu-west-1.elasticbeanstalk.co.
You need to setup something like the following:
DNS Name www.mydomain.com points to CloudFront Distribution
Configured to serve www.mydomain.com
Configured with an SSL certificate for the domain www.mydomain.com
Configure to pull from the origin beanstalk.mydomain.com
DNS Name beanstalk.mydomain.com points to Elastic Beanstalk application
With a Load Balancer, with an SSL certificate for beanstalk.mydomain.com
I am attempting to add HTTPS to my AWS Elastic Load Balancer.
I obtained a certificate through AWS Certificate Manager:
I have enabled HTTPS on the load balancer:
I made sure the security group for the load balancer accepts 0.0.0.0/0 on 443:
When going to my domain on HTTP, it works.
However, when trying to load my domain with HTTPS, it does not work ("ERR_CONNECTION_TIMED_OUT")
EDIT and UPDATE:
It is the API that I am attempting to get HTTPS working for, not necessarily the domain. The domain serve's a static file (angular web app) from S3, and it is angular that is calling the load balancer (to transfer the request to an EC2 instance) for DB data.
When angular calls the api directly via the load balancer domain name over HTTP, the request responds as expected.
When angular makes the same api call over HTTPS, I get the following error:
You enabled HTTPS for your domain name, not the ELB domain which Amazon owns. You can only create SSL certificates for domains that you own. You can't enable SSL for "mydomain.com" and then excpect that to somehow work on a completely different domain. You need to change your AngularJS code to reference the API by your custom domain name which you have created an SSL certificate for. You need to point the domain to the ELB and install the SSL certificate for the domain on the ELB.
Mark B provided the almost full solution.
As my javascript code is calling the elastic load balancer (ELB) via it's DNS name provided by AWS, I can't obtain an SSL certificate for the domain I don't own.
As Mark B pointed out, I need to point my javascript code to the domain I do own, and have an SSL cert for.
So I can create a sub domain (e.g. api.mydomain.com) of the domain I own that then points to the ELB.
An A Record (e.g domain pointing to an IP) looks like it could fit the need.
However, an A Record can't point to the ELB because it's IP could change.
The missing step was to use AWS Route 53 to point the A Record to an alias (Route 53 allows you to do this) that represented my AWS Elastic Load Balancer.