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.
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/
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.
So, I am trying to get the SSL certificate to show up on my website but even after following all the steps from the aws documentation and various internet tutorials. The SSL lock sign is still not visible up on my website.
I found this website really helpful and tried to follow all the steps listed there : https://blog.webinista.com/2016/02/enable-https-cloudfront-certificate-manager-s3/index.html
What I think the problem is that I am not quite certain how to reconfigure the DNS server after creating the cloudfront distribution. In this instance, I just created an alias target for my domain name (shamveelahammed.com) to point towards the cloudfront distribution. But this hasn't worked at all for me. At the moment, I only have 4 entries in my domain record set.
https://www.dropbox.com/s/5g2nkyxip1c22oo/Screen%20Shot%202017-07-05%20at%2002.05.31.png?dl=0
Any help with figuring out my next steps will be massively appreciated. (N.B I am very new to this and still learning how to use AWS.)
As you have restricted bucket access when creating cloudfront .So you dont need the additional alias record for s3 in Route53. you have to generate certificate for both domains www.shamveelahammed.com and shamveelahammed.com OR you can generate wildcard certificate for your domain as *.shamveelahammed.com .
In your case it seems you have generated certificate only for www.shamveelahammed.com Domain only.
Well, thanks for all the helpful answers. I managed to find a work around to solve the issue I was having.
I generated a new certificate for the domain www.shamveelahammed.com .
Created a target alias for cloud distribution pointed towards www.shamveelahammed.com .
And finally, redirected all the requests made in www.shamveelahammed.com in s3 bucket to shamveelahammed.com.
This fixed my problem. Hope this helps...
DNS isn't the issue.
In CloudFront, each Cache Behavior needs its Viewer Protocol Policy configured for Redirect HTTP to HTTPS.
I have tried setting up a static hosting solution for our web platform by using AWS S3 and CloudFront. It is required to use https, and it needs to be accessed via a custom subdomain.
This is my S3 bucket:
These are the settings for the CloudFront:
The certificate settings look ok to me:
And finally my DNS record is like this:
CNAME: "static" -> "d1fd407fp9coo4.cloudfront.net."
edit: using my default domain provider for DNS, not Route 53.
The aim is to have the resource available at static.dmaglobal.com/logo-frontpage.png via https. It loads fine without (http://static.dmaglobal.com/logo-frontpage.png), but the https-version (https://static.dmaglobal.com/logo-frontpage.png) gives an SSL-error stating the current certificate is for *.s3.eu-west-2.amazonaws.com instead of *.dmaglobal.com. I do not understand where this mismatch comes from, as it seems like the current certificate is correctly set up for our custom domain.
Anyone able to give some pointers on how to proceed from here with this issue?
As you have noticed your DNS record resolves to S3 still.
Instead of CNAME you should create an ALIAS record to Cloudfront distribution. In static record pick A type record, check Yes for Alias and pick the Cloudfront distribution on the dropdown.
The reason for this: ALIAS records are free of charge and they resolve faster.
To answer my own question: In the end, it was the proper CNAME value that had not propagated properly yet (as it was initially pointing to S3 before I was aware that CloudFront was required for SSL). As soon as it was, the settings in the OP worked perfectly.