I set up AWS cloudfront to work as a CDN to host some files for my site.
When I use the cloudfront integration – it works in HTTP and HTTPS.
When I use the custom domain – it only works in HTTP.
So, using dummy examples, here's what I mean:
http://www.12345.cloudfront.net/file - Works fine
https://www.12345.cloudfront.net/file - Works fine
http://www.cdn.domainname.com/file - Works fine
https://www.cdn.domainname.com/file - Prompts an insecure site warning message in browsers
I created a custom domain SSL certificate within AWS for cdn.domainname.com--as I thought that would remedy the issue. And, I added that to the cloudfront distribution, but this doesn't seem to have changed anything.
custom SSL certificates for Cloudfront have a different set of requirements than for ELB. You may need to issue a different certificate; also, it used to be that you had to import the certificate in US-East to use it in Cloudfront, not sure if that's still the case.
See details here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-requirements.html#https-requirements-aws-region
and:
https://aws.amazon.com/premiumsupport/knowledge-center/custom-ssl-certificate-cloudfront/
UPDATE: I was able to fix this issue by adding both cdn.domainname.com and www.cdn.domainname.com to the SSL certificate.
Related
I'm following the serverless-stack guide and have a website hosted in an Amazon S3 bucket. I purchased a domain using GoDaddy and I have set up cloudfront to work with this bucket, then have used AWS certificate manager to generate SSL certificates for my domain (both www.my_domain.com and my_domain.com).
In GoDaddy I then configured DNS forwarding to point to my cloudfront resource.
This all works nicely, and if I go to my_domain.com in a browser then I see my website.
However, I can't get SSL working. If I go to the https:// version of my website then I see a not secure error in the chrome address bar which shows a certificate pointing to shortener.secureserver.net rather than my own website.
Could someone point me at a way around this? Looking through S.E. and using google it seems that Amazon's route53 might be able to help, but I can't figure out how to do this.
Thanks!
(edit) To make things more clear, this is what I see in Chrome if I connect to https://my_website.com or to https://www.my_website.com
The warning message:
The certificate details:
What I do not understand is why, after configuring an AWS certificate for my domain, I see a certificate for shortner.secureserver.com rather than a certificate for my_website.com.
Go daddy has problems and does not redirect to https, There are two ways, the first is to change domain registrar and the second is the easiest, which is: Create a hosted zone on AWS router 53 with your domain name
Create 2 type A records, one for the root (of your domain) and one for www that point to your cloudfront. Router 53 allows you to create a type A record without having an IP, because it directly points to a cloudfront instance that you indicate, that's the best
Then in go daddy it gives you the option to change name servers and puts the ones assigned by aws in hosted zone with the record that says NS and you put those 4 in Godaddy, replacing the ones that had
Note: SAVE THE NAME SERVERS THAT YOU HAVE IN GO DADDY BEFORE REPLACING THEM, IN CASE YOU HAVE ANY PROBLEM, YOU CAN REPLACE THEM AGAIN
You have to wait at least a few hours until all the name servers are updated, you can use the who.is page to see if the DNS have already been updated with those of aws.
It turns out that this is not possible with GoDaddy. If anyone else reading this has a similar problem, only current solution is to cancel your domain registration and register with someone else.
(edit) As #aavrug mentions in their comment, Amazon now have a guide for this.
When you defined your CloudFront you can defined whether you want to use, and you can choose HTTPS only. In this case HTTP requests will be automatically redirected to HTTPS. Have in mind CloudFront changes may take a while to be replicated and your browser cache it as well, so the best way is to make a change, wait for the deployment and then check it in a new cognito browser.
It goes without saying that your certificate must be valid and verified as well.
It might be something wrong with your certificate or with your domain.
If you serving your content over HTTPS you must provide a SSL Certificate in Cloudfront. Have you done that?
Have you added your domain on Alternative Domain Names (CNAMEs)?
Please have a look on the image below:
-> AWS provides Free SSL Certificates to be used with Cloudfront, so you might want to use it (easier than you import your SSL from go daddy).
You can create a free SSL certificate on AWS and easily attach it to your cloudfront distribution.
-> You can also transfer your domains to AWS Route53. It is easy to integrate with any AWS Service and easy to use/maintain :)
I wrote a complete guide on my blog telling how you can add Custom SSL and attach custom domain to Cloudfront distribution, it might be useful :)
https://lucasfsantos.com/posts/deploy-react-angular-cloudfront/
I have a certificate in IAM, registered to the hostname azb.hostname.com.
Then I have 2 cloudfront distributions, with auto hostnames, something like d727.cloudfront.net and d838.cloudfront.net.
By default the certificate provided by cloudfront does not support TLSv1.1+ so I have to assign a custom certificate. I tried to use my certificate on one of them and...it works!
What I can't understand is why the cloudfront is still available on its default hostname *.cloudfront.net: shouldn't it have become azb.hostname.com?
And can I assign the same certificate to both of them? Will they keep working?
CloudFront will be available with *.cloudfront.net even though you have added your own cert and has added your domain in Alternate domain filed, this is expected. if you don't want that , you probably need to add a WAF to read HOST header and if it's d1234xxx.cloudfront.net, block it.
You can use IAM/Cert with multiple distributions, it will not cause any problem.
Also, accessing d123.cloudfront.net supports tls1.1 and tls1.2 and I think recently, you can also restrict tls version as well.
My Situation
I have a web api hosted in an EC2 instance. I am trying to configure a cloudfront instance "infront" of that EC2 instance.
However, I have not been able to get my cloudfront to forward requests to the EC2 instance. I get hit with an error response like this:
Access to XMLHttpRequest at 'https://api.example.com' from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No access-control-Allow-Origin header is present on the requested resource
However, if I change my DNS to point https://api.example.com to EC2 instance's IP address, it works.
What I have done so far
Configured to use correct SSL certificate (for a different problem earlier)
Configured my CF distribution's behaviors to Whitelist Headers: "Origin"
Configure my CF distribution's behaviors to "All" - (which disables caching)
Invalidated cloudfront cache
What I am trying to do
I came across this AWS doc titled "Configuring CloudFront to Respect CORS Settings".
Link
However, it only says "Custom origins – Forward the Origin header along with any other headers required by your origin."
But... How do I do that? How do I forward origin header along with any other headers required? The docs doesn't specify or link to another docs to do it.
I have spent 4 hours or so now and it's extremely frustrating because Cloudfront takes ~30 minutes to deploy.
I have managed to fix this issue it turned out I had overlooked another error returned by Cloudfront: 502 Bad Gateway. Even though Chrome will show the abovementioned error "Access to XMLHttpRequest...". This was caused by my improper DNS and SSL certificates configuration due to my inexperience.
I will try to answer my own question, seeing after hours of searching, there wasn't a straight answer regarding (Cloudfront, EC2 and HTTPS) in Stackoverflow and there are many unaswered questions.
The goal my group was trying to achieve was enabling HTTPS connectivity for the entire set-up: Users' browsers, Cloudfront distribution and my EC2 instance.
What I did to fix this:
Generated a free SSL certificate (e.g. Let's Encrypt) to use for EC2 instance using a sub-domain (i.e. ec2.example.com or wildcard *.example.com). *Note: ACM does not allow public SSL certificates to be exported that can be used in EC2 instances, so use other free online SSL services. Do not use self-signed certs.
Import this certificate into ACM to be used for Cloudfront later too.
Created a new DNS A record to map the sub-domain to the EC2 instance. (e.g. ec2.example.com to ec2-xx-xxx-xx.ap1-location.amazonaws)
Created a new Cloudfront distribution and set the origin as the sub-domain, ec2.example.com. Also, under "Cache Based on Selected Request Headers", set it to "Whitelist" and to forward "Origin" headers. For SSL cert in Cloudfront, use back the one generated back in step 1)
Created a new DNS A record and map an "api" sub-domain to the Cloudfront. (e.g. api.example.com to abcdxyz.cloudfront.net)
I am now able to use a sub-domain (api.example.com) to communicate with Cloudfront which in turns communicates back to my EC2 and performs caching, using HTTPS all along.
Reference links: link1,
link2
There is probably a better way to set this up and if so, please do correct me so I can improve too! Hopefully this answer will help someone else new like me in the future too.
I’m using CloudFront to setup a CDN for a WordPress installation. It worked for years, but I ran into an issue when I moved the whole site to HTTPS and set it up with a SSL certificate. A couple of things:
the site itself has a valid certificate, which I checked using a SSL checker;
the CNAME I’m using for the CDN (like image.website.com) also has its own SSL certificate, which I also checked. Intermediate certificate is also good and valid.
Of course the distribution is set to point to the custom CNAME, which was validated by AWS (using DNS protocole)
I tried different configuration of the Origin Protocol Policy setting in my distribution, but the problem persists.
Maybe something to do with the header. If anyone could help me troubleshooting this I would be greatly appreciated.
Thanks
The distribution is working. It seems that changing the Origin Protocol Policy to “HTTP only” did the trick. After implementing changes in distribution settings, some time is needed for them to fully take effect.
I can't get the Internet <-> CloudFront <-> S3 Bucket working, using an AWS certificate. This is what I did:
Created a certificate, a wildcard one, like: *.mydomain.example.
Created a S3 bucket, no fiddeling with properties.
Creating a CloudFront distribution, using the created S3 bucket URL as origin, selecting my certificate from step 1, choosing HTTP/2, HTTP/1.1, HTTP/1.0, and choosing HTTP to HTTPS redirect.
Created an A alias in my hosted zone for the domain the certificate is issued for, pointing at my distribution URL.
After the distribution is created, my browsers all tell me this:
Firefox: SSL_ERROR_NO_CYPHER_OVERLAP
Chrome: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Safari: Can't establish a secure connection.
I'm not sure if I've missed a step in the process of setting this up, I've tried fiddling with various parameters but nothing lets me through.
I read this blog post, saying that I might have forgotten adding alternate CNAMEs. This confuses me a bit, should I? In Route 53 I configured my full domain using something.mydomain.example and the certificate is a wildcard one.
Other blog posts and question answers indicates I should not, just use the A record and the CloudFront distribution URL/endpoint, as I have done.
So, in my update, I mentioned adding CNAMEs from a blog post. This was it, the second I did that, it started working.
To clarify, I did this to solve my problem:
Edit your CloudFront distribution.
Under the tab General, click edit.
In the Alternate Domain Names text box, add (at least) the something.mydomain.example that you have configured to this distribution's endpoint/URL in Route53.
Save your changes.
This solved it instantly for me, but remember that CloudFront configuration changes sometimes can take some time to be pushed out.
As stated by OP in an edit error caused when a CNAME entry for the apex (naked) domain, www subdomain, other subdomain or other domain(s) are not listed in the distribution.
To fix add at least one CNAME to the distribution in CloudFront.
Weird but true:
What actually fixed the issue for me was bumping the minimum cypher version up from TLSv1 to TLSv1.1_2016 in the CF Distribution.
Here's the relevant CloudFormation snippet:
HttpVersion: "http2"
ViewerCertificate:
AcmCertificateArn: !Ref SslCertificateArn
MinimumProtocolVersion: "TLSv1.1_2016"
SslSupportMethod: sni-only
Weird because I don't understand why this change fixes anything. The browser should automatically negotiate the higher TLS version.