Front, backend https with one ACM, frontend is okay, but backend also https and htttp - amazon-web-services

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.)

Related

Can't access server since switching to https on aws

I am deploying a MERN stack using EC2 on AWS.
I have created SSL certificates for the following domains:
example.com
*.example.com
www.example.com
The cname and cvalue for example.com and *.example.com are identical but they are different for www.example.com
I have set up target groups and a load balancer and edited the listener to redirect from http to https.
I have set up 3 different records in the hosted zone of route 53 so that www.example.com, *.example.com and example.com are directed to the loadbalancer
I can load https://example.com
http://example.com directs to https://example.com
When the website loads (either by typing http or https) it does not connect to the server.
I am getting the following error in the console:
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://54.220.212.131:5000/events'. This request has been blocked; the content must be served over HTTPS.
54.220.212.131 is the site's IP and 5000 is the server's port. This is hard coded in the front end.
How should I get the client to send requests to the server for a https connection?
It sounds like you have two services running, a front-end service that you have correctly configured to run behind a load balancer, and a back-end service that you are connecting directly to via the server's IP address on port 5000.
Your backend on port 5000 is not secure, and that is exactly what the web browser's error is telling you. You need to configure all your services to run behind the load balancer. You need to create a second target group that sends traffic to port 5000 on your server, and setup a routing rule on the load balancer's listener to send all traffic for api.ticketglen.com to that target group. Then you need to change your hard-coded values in from http://54.220.221.131:5000 to https://api.ticketglen.com.
What worked for me was to create the SSL certificates from the server and delete them and the load balancer altogether from the AWS platform.
Process is outlined here

Issues putting Cloudfront infront of ALB

I want to have CloudFront infront of a load balancer for a web app (built with VueJs and Nuxt). but the issue is that I get DNS_PROBE_FINISHED_NXDOMAIN when going to the Cloudfront Url {key}.cloudfront.net.
I found that it might have with Certificates to do, I have the same certificate on bout ALB and CloudFront, but CloudFront certificate is stored in N.virginia and ALB is in Ireland which is suppose to give me this issue.
My question is how it should be setup to work.
Today ALB has listeners
Https listener on port 443 with certificate (located in Ireland region)
Http listener on port 80 which redirect all request to Https.
The ALB is publically available therefore I wanted the Http to Https redirect.

Google load balancer problem with ssl certificate if url mapping set to custom

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.

Elastic Beanstalk with Classic Load Balancer working with HTTP but not HTTPS

I have set up a load Balancer to my elastic beanstalk app. It has provided a DNS / URL which works on http.
I have set up my domain on Route 53. I'm trying to make it work with HTTPS for a subdomain app.example.com
I have set up a wildcard certificate using ACM *.example.com.
I have enable HTTPS and port 443 on the loadBalancer. But I can't access it using the domain name https://app.example.com but works with http://app.example.com
In Route 53, I have created an A record with Alias set to the load Balancer DNS Name.
I have gone through tonnes of answers on stackoverflow but nothing worked for me. No idea what I'm missing.
You do not need to map 443 of the target as the TLS will terminate before sending the request to target.
Map 8080 port of the target to 443 of the load balancer.
Below diagram show SSL/TLS termination work with ALB.
SSL Certificates
To use an HTTPS listener, you must deploy at least one SSL/TLS server
certificate on your load balancer. The load balancer uses a server
certificate to terminate the front-end connection and then decrypt
requests from clients before sending them to the targets.
/application/create-https-listener
This is what worked for me. Changing Instance Protocol to HTTP in first row and changing Instance Port to 80.

How to enable HTTPS on AWS Elastic Load Balancer?

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.