Static Web Application hosted in Amazon S3 Bucket suddenly not working - amazon-web-services

The hosted application worked until yesterday but suddenly not working today.
What I have done?
Using Cloudfront - To host my website from Amazon’s edge locations with a custom SSL certificate setup for my domain.
Amazon
Certificate Manager - To get HTTPS Certificate
Hosted my client application in S3. They wanted to access their site using a domain name. To achieve this I have provided two records as given below.
Type Host Value TTL
A # IP of the client domain 600
CNAME www CloudFront distribution URL 600
The thing is Endpoint which I got while configuring Cloudfront "d3ajo2v2g7lf33.cloudfront.net" is working but the domain name which I added as an alias to this endpoint is not working.
Probable findings from my side:
1) Used let's encrypt to get the SSL and it's about to expire within a week.
2) Added A record with the IP address of the domain. As am using Cloudfront am doubting that the domain does not have a static IP.
Also please let me know CloudFront distribution domain name IP will change every time or will it be static.
Kindly help me to resolve this.

CloudFront has CNAME record as well. So you have to register your domain name in the CloudFront distribution.
as for the SSL certificate for your custom domain, take a look at AWS ACM. It may be easier than using lets encrypt certificate (your call).
and yes. use the cloudfront's domain URL. it won't change unless you delete the distribution.

Related

Cloudfront domain defaults to HTTP when HTTPS is available

Similarly to other stacks, I have hosted a website using AWS services:
Registered domain on Route 53 (example.net)
Content is hosted on an S3 bucket
Got an SSL certificate using AWS Certificate Manager
Created a CloudFront distribution, pointed it to S3 and connected it to my domain with Route 53.
All of this works except for an issue at what seems to be the final hurdle. When I enter my domain url into the search bar, example.net, the connection isn't secure by default. I've illustrated the problem here.
I'm relatively new to hosting and can't find a solution relating to this. My thoughts are that I'm missing some Cloudfront or Route 53 configuration, since another thing that doesn't work is connecting via www (I don't care about that issue as much). Any input is appreciated.
By default enabling HTTPS on a website doesn't disable HTTP. They are both available, on separate ports. That's why you have to type https:// in the browser's address bar to go directly to the HTTPS version of your website. You can get CloudFront to redirect all HTTP requests to HTTPS by following this guide.

A custom sub-domain via AWS CloudFront fails over https on S3 website, but works fine over HTTP

I created a Let's Encrypt wildcard certificate for *.example.cz on Amazon Linux EC2 instance using CertBot.
The certificate attached to nginx web server on EC2, website works fine both over HTTP and HTTPS. There are couple of DNS records www.example.cz and *.example.cz of type A with EC2 IP Address.
Then to point a subdomain cdn.example.cz to a S3 Static Website Bucket:
I imported the same wildcard SSL certificate from EC2 to AWS Certificate Manager.
Created a CloudFront distribution with the imported SSL Certificate.
Created a CNAME record cdn.example.cz and pointed it to S3 bucket's URL.
When I request an object from S3 using http://cdn.example.cz/object.jpg it works, but the request over HTTPS keeps busy until reaches time out.
I tried CloudFront's Alternate domain names to be cdn.example.cz, and also tried www.example.cz example.cz. None worked.
AWS Certificate Manager
CloudFront Distribution
CloudFront Distribution Origins
CNAME record had to be pointed to CloudFront Distribution domain name
xxxxxxx..cloudfront.net
I'm not sure about this but I also removed eu-south-1 from Origin domain name so it's now cdn.example.cz.s3.amazonaws.com
Once I updated CloudFront distribution, I had to wait few hours for the change propagated properly (as it was initially pointing to S3 before I was aware that CloudFront was required for SSL). As soon as it was, this settings worked perfectly.

AWS S3 Website with Route 53 Domain, needs https through CloudFront

So I created two buckets in S3. One with my domain name xxx.ninja and the other with the www. subdomain. The www one I redirected to the first. Then I created a domain in Route 53. And because I wanted https on my site I created a cloudfront distribution with redirect http -> https.
The s3 bucket url works just fine, but the site URL does not. I think I may have set it up incorrectly.
In AWS CloudFront I created my distribution and used the cloudfront default SSL cert. I choose redirect http -> https. And I pasted in my s3 website URL.
Then I copied the domain name and went to Route 53. After I created my domain I open its hosted zone and added an A record with the alias of the cloudfront domain name.
But the URL doesn't work. I get a 403 CloudFront error in the browser.
Thoughts?
IF you're using the default CloudFront SSL this indicates to me that you're not using a custom hostname (which would deny access to the CloudFront distribution).
You will need to add additional names to your CloudFront distribution (specifying every hostname that will have a DNS record resolving to the CloudFront distribution). In addition you will need to generate an SSL in ACM (which is free), this must be in region us-east-1.
More information on how to add a custom domain to your CloudFront distribution is available here.

Setup of Amazon Cloudfront with EC2 instance as origin and custom domain name

Can you guys help me out in identifying what I am doing wrong in setting up the cloudfront for my ec2 instance (web server) for a custom domain of mine.
I am using my domain name (www.example.com) as the origin domain name.
I have also supplied a certificate to the cloudfront (*.example.com) using ACM.
The problem I am facing is, when i point out my custom domain name to the cloud fronts domain name in route53 using an alias record.
My website responds with an error 502. I'll really appreciate any help. I have explored all the content provided by AWS in respect to this but nothing seems to work till now.
Most 502 from CloudFront caused by the SSL communication between CloudFront and Origin.
CloudFront makes sure that your origin:
1.Has Trusted certificate
2. Ciphers matches
3. CloudFront uses the SNI filed in Client hello which is defined as Origin domain name, it most cases if you have cert on EC2 with www.example.com CN, you can forward HOST header and it should solve your problem.
If you don't have HTTPS running on Origin, you can select HTTP only in Origin protocol policy as its bydefault set to Viewer match.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html

Routing example.at to S3 bucket and *.example.at to load balancer with HTTPS

I have set up a multi tenant application which should be available to clients via a subdomain (e.g. https://client1.example.at). Requests to *.example.at are routed to a load balancer via Route 53. The load balancer has an AWS signed wildcard certificate (e.g. supporting example.at and *.example.at). From this side, everything is working as expected and I can access https://client1.example.at, https://client2.example.at, etc.
Based on this setup, I wanted to route specific request without subdomain (except www) such as https://www.example.at or https://example.at to a bucket (which is also named www.example.com) and not to the load balancer (I just want to serve a static site for requests to the "main domain"). It works but I can only access www.example.at and example.at without using HTTPS. My setup can be seen below:
I then found out that I have to use Cloudfront in order to use HTTPS for a custom domain with S3 buckets (if that is correct?). Now I have a few questions:
Is it necessary to use Cloudfront to serve content from my S3 bucket for www.example.at and example.at via HTTPS?
If Cloudfront is necessary then I have to request a new certificate for www.example.at and example.at in region US EAST according to the official AWS docs. Is it possible to create two certificates for the same domain with AWS certificate manager or can I get some conflicts with this setup?
Is it ok to use *.example.at as A type record with alias to the load balancer at all?
Generally speaking, is my Route 53 setup valid at all?
I wanted to route specific request without subdomain (except www) such as https://www.example.com or https://example.com to a bucket (which is also named www.example.com)
Each of those "domains" must route to a different bucket unless you are using a proxy (which reroutes the hostname passed from the browser) in front of S3, the domain name must match the bucket name. If they don't then your requests are going to a bucket matching the DNS name you routed from, the routing has nothing to do with the hostname of the S3 bucket endpoint.
In other words, let's say your hostname was www.example.com, and you set the CNAME to example.com.s3.amazonaws.com (or you could use the website endpoint, it doesn't matter for this example).
When a request hits the DNS name www.example.com it then is sent to the S3 server which is behind the S3 hostname. That request from the browser is for hostname "www.example.com", the actual CNAME referenced which pointed to the S3 endpoint is irrelevant because S3 never knows what actual CNAME was used to by your browser to connect to S3. So S3 will attempt to pull the requested object from the www.example.com bucket.
URL -> S3 Bucket
https://www.example.com -> s3://www.example.com
https://example.com -> s3://example.com
It works but I can only access www.example.at and example.at without using HTTPS.
CNAME DNS routing like this when using SSL to an S3 bucket does not work. The reason for this is that the S3 wild card certificates are 1 level deep (*.s3.amazonaws.com) so your bucket www.example.com.s3.amazonaws.com will fail to match it because it has 2 extra levels above the wild card. So your browser rejects the certificate as invalid for the hostname.
To accomplish this you must use a proxy of some sort in front of S3 with your own certificates for the domain in question.
Is it necessary to use Cloudfront to serve content from my S3 bucket for www.example.at and example.at via HTTPS?
CloudFront is an excellent option for addressing the HTTPS with CNAME routed DNS to an S3 bucket issue we just mentioned.
If Cloudfront is necessary then I have to request a new certificate for www.example.at and example.at in region US EAST according to the official AWS docs. Is it possible to create two certificates for the same domain with AWS certificate manager or can I get some conflicts with this setup?
I can't answer that one, I can only suggest you try and find out what happens. If it doesn't work then it's not an option. It shouldn't take much time to figure this one out.
Is it ok to use *.example.at as A type record with alias to the load balancer at all?
To clarify, an A Record can only ever be an IP address, an A Alias is similar to a CNAME (but is Route53 specific).
I highly recommend CNAMES (or ALIASES, they are similar). Pointing directly at one of S3's A-Records is a bad idea because you don't know if or when that IP will be removed from service. By referencing the hostname with a CNAME/ALIAS you don't have to worry about that. Unless you can be 100% sure that the IP will remain available then you shouldn't reference it.
Generally speaking, is my Route 53 setup valid at all?
I don't see any issues with it, based on what you described it sounds like like things are working as expected.
If Cloudfront is necessary then I have to request a new certificate for www.example.at and example.at in region US EAST according to the official AWS docs. Is it possible to create two certificates for the same domain with AWS certificate manager or can I get some conflicts with this setup?
As suggested by #JoshuaBriefman I simply tried to create another certificate for the same domain in another region now and it worked. I could also use the certificate for the CloudFront distribution (additional certificate was created in US EAST) and all works now without any problems so far.