1

I have setup a cloudfront distribution with SSL, pointing to a s3 bucket which is public and setup as a static website. I chose the option to redirect HTTP to HTTPS, as I want to force HTTPS.

I setup route53 to have both A and AAAA records that are alias types, using example.com and having it resolve to the cloudfront domain name. When I did this the "hosted zone ID" automatically came up, showing that amazon recognizes the cloudfront domain.

I can visit the cloudfront endpoint in my browser and see my website, however, if I go directly to example.com (with no HTTPS, no www), then I see:

403 ERROR The request could not be satisfied. Bad request. Generated by cloudfront (CloudFront) Request ID: xDCmX7k8EFGGLAfjgpJcJ7AD-_mRfdBseTsqEP2aXfSWQ5S2mTMwuA==

However, if I try https://example.com, then I just get a blank page.

I tried putting both example.com and www.example.com in the cloudfront cnames field, but that did not seem to do anything, so I currently have them removed.

1

You will need to have both example.com and www.example.com in the CloudFront CNAMEs setting. However, after adding these, how long did you wait before testing? CloudFront needs to redeploy to all edge locations after changes are made, and this can sometimes take a while.

You can see the status in your list of distributions - anything that says 'Deploying', you'll need to wait for - often around 15 minutes, but I've seen it take up to an hour sometimes.

After your changes have deployed, you'll also need to clear your browser cache (perhaps try in an incognito window) to ensure you're requesting the latest from the server. 301 redirects (which is what CloudFront uses to redirect from HTTP to HTTPS) are considered 'permanent', and your browser will have likely cached this and won't ask CloudFront for it again.

The easiest way to be sure when you're testing can often be to use curl:

curl --head --location http://example.com
curl --head --location http://www.example.com
curl --head --location https://example.com
curl --head --location https://www.example.com

For each of those, you should get responses such as a 301 redirect from the http to the https addresses, and then a 200 OK at the https addresses.

Ideally.. you'd probably actually want another CloudFront distribution set up for the www (or the naked domain, if the www is your main one), pointing to a bucket with a simple redirection on it to ensure everyone ends up at the address you prefer.

But the main thing to remember is... wait, after making any changes to your distribution. There's over 100 edge locations to be deployed to.

  • 1
    hah, you are right.. I tried again with the cnames added and it resolved! Thanks!! – patrick Jun 17 '18 at 4:57
  • Actually, I still am having trouble with www resolving. I have www as a cname in route53 pointing to the cloudfront domain. Is that the correct thing to do? – patrick Jun 17 '18 at 7:02
  • Yes; do you have it listed under the CNAMES in the Cloudfront distro as well? When you say not resolving, is it not resolving the DNS? Is it possible your local DNS cache needs refreshing? (try resolving it elsewhere, like at toolbox.googleapps.com/apps/dig to confirm if that's the problem) – Tim Malone Jun 17 '18 at 7:19
  • I do have it in the cloudfront distro-- I am using carriage return as a delimiter, not "," or something.. That is correct right? The toolbox shows nothing under "answer" when I do the www version. – patrick Jun 17 '18 at 7:34
  • 1
    Yeah that worked... So, the answer was: two s3 buckets, the default being www, the non-www is a redirect bucket. Two separate cloudfront distributions, one's origin is the www version, the other is the non-www version... Two sets of A and AAAA records in route53 aliased to those two different cloudfront domains. Now everything works! – patrick Jun 17 '18 at 22:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.