How do you set cloudfront to use https without a domain name? - amazon-web-services

I want to set up https for my s3 bucket so I figured I do it via cloudfront
I have a CF distribution and requested a domain name via route 53, which can take 3 days apparently
I've seen lots of tutorials but they all require a domain name to be entered when requesting a certificate. is it possible to do with just CF and s3
so instead of going to do http://my-bucket.s3-website-us-east-1.amazonaws.com/ I can access https://my-bucket.s3-website-us-east-1.amazonaws.com/
how can I do this?
I tried putting in my cloudfront domain into the ACM request but it rejected it

The SSL will not be valid for that domain name. You will however, be able to access the CloudFront distribution via HTTPS.
Try accessing the CLoudFront hostname in the browser using HTTPS.

Related

How can I use aws to secure a domain with https for a non aws origin?

I did a search in the aws docs and couldn't find anything that could help me to setup a cloudfront distribution for a non aws origin server to secure my domain with https. I'm using route 53 to manage my dns for the domain, I'd like to setup https for the domain but it is not hosted with aws. How can I use aws to create a secure domain with https?
Update: I've created the cloudfront distribution and set the alternative cnames to the domain (example.com and www.example.com). In Route 53 I updated the A record for the domain - example.com - to be an alias and pointed it to the cloudfront distribution, but when I try to access the site I get page not working error. The domain does now have he secure padlock, but I can't access the site. Here is the error that I get when I access the site:
The simplest way is to use a CloudFront distribution in front of your non AWS endpoint. This endpoint would be configured as a custom origin endpoint.
You would need to generate or upload a certificate to ACM to attach to the resource. This must be done before you can use the distribution on your own domain, if you don't have it when you create the distribution you will need to edit it later.
The AWS documentation includes documentation for Creating a Distribution. If you follow this and reference your endpoint as the custom origin you will be able to create the host.
You will need to ensure you configure the Origins Origin Protocol Policy option to be HTTP Only if your host does not have a HTTPS certificate.
Be aware that as the CloudFront distribution communicates with your endpoint over the internet, any traffic between CloudFront and your endpoint will still not be encrypted.

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.

Static Web Application hosted in Amazon S3 Bucket suddenly not working

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.

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.

AWS S3 CloudFront - redirect from https://www.domain.com to https://domain.com

Here is my AWS Route 53 Setup:
The domain https://www.migranthire.com doesn't work. How can i redirect from this domain to https://migranthire.com
Your www site is pointing directly to an S3 bucket web site hosting endpoint, which is taking care of the redirect to the domain name without the www prefix.
The S3 website endpoints do not support HTTPS, so this works for http only.
Your solution is to create a second CloudFront distribution -- you need an additional one, because the second one has a different origin. Configure this distribution with your SSL certificate, configured to expect the www hostname as an alternative name, and set its origin to the www bucket -- however, when you are setting up this second CloudFront distribution, do not select the name of your bucket from the list. Instead, enter the website endpoint hostname -- www.migranthire.com.s3-website-eu-west-1.amazonaws.com. Set the origin protocol to HTTP only (CloudFront has to send the request to the bucket as HTTP even if the viewer protocol is HTTPS. You still get a green lock.)
Then, configure Route 53 to send www requests to the new CloudFront distribution, instead of directly to the bucket. CloudFront will speak SSL, sent the request to S3, which will return the redirect, as it is doing now.