Cloudfront + S3 access denied for signed URL, but only when Chrome/Browser promoted from http:// to https://

0

I have a product I sell with it sending an automated email with a signed URL to the customer when they purchase. This week I started getting emails from customers that the URL wasn't working. I found out that Chrome (and other browsers) are now promoting http URLs to https URLs. For some reason, the way I have Cloudfront+S3 configured, it is giving an Access Denied error when trying with https, but if they explicitly copy the URL and paste in an Incognito browser window (or non-cached normal browser window) then the download will start fine.

My first attempts were to modify the Cloudfront settings for the distribution and set up a custom SSL certificate. I got all that configured and talking with my DNS CNAME record, but that didn't fix it.

I turned on logging for the cloudfront distribution, but those are pretty sparse about reasons and just show an error, but not details about the error. I also checked the permissions and setting on S3 to see if there was anything changes need to allow a Cloudfront URL accessed via https to get access to the bucket. It seems that the OAI on the CLoudfront should work as-is

So, I have a couple of questions:

  1. How do I debug where this is happening? I can see the S3 logs and the Cloudfront logs and the details are very limited other than seeing the access denied in the cloudfront log, ONLY when accessing the URL with https
  2. Any other obvious pieces I am missing?
asked 5 months ago132 views
1 Answer
0

I would follow these debugging steps

Verify CloudFront Distribution Configuration:

  • Ensure that your CloudFront distribution is configured to serve HTTPS traffic. Check the "Viewer Protocol Policy" under the "Behaviors" tab of your CloudFront distribution. It should be set to "Redirect HTTP to HTTPS" or "HTTPS Only".

  • Confirm that your CloudFront distribution has a valid SSL/TLS certificate associated with it. This can be a certificate from ACM (AWS Certificate Manager) or a custom SSL certificate that you've uploaded.

  • Check the Origin Access Identity (OAI):

  • Verify that your S3 bucket is using an Origin Access Identity (OAI) and that the bucket policy allows this OAI to access the files. The OAI should have permissions to access the objects in your S3 bucket.

  • The bucket policy should specifically grant GetObject permission to the OAI used by your CloudFront distribution.

  • Inspect S3 Bucket Permissions:

  • Double-check the S3 bucket and object permissions to ensure there are no explicit "Deny" statements that might be interfering with access via CloudFront, especially over HTTPS.

  • Ensure that there are no bucket policies or IAM policies that specifically restrict access based on the protocol used (HTTP vs HTTPS).

  • Review CloudFront Custom Error Pages:

  • In the CloudFront distribution settings, check if there are any custom error pages configured that might be handling HTTPS requests differently from HTTP requests.

  • Test with Alternate Methods:

  • Use tools like curl to test accessing your CloudFront URLs directly from the command line, both with HTTP and HTTPS, to see if the issue can be replicated outside of a browser. This can help isolate whether the issue is browser-specific or a broader configuration issue.

  • Analyze CloudFront and S3 Logs:

  • While you've mentioned that logs are sparse, try to correlate the timestamp of an "Access Denied" error in CloudFront logs with the corresponding S3 access logs. This might give clues, especially regarding the request headers or the request protocol.

  • Check DNS Configuration:

  • Ensure that your DNS records are correctly pointing to your CloudFront distribution and that there are no issues with DNS propagation.

  • Additional Considerations

  • HTTPS Enforcement by Browsers: If browsers are upgrading HTTP URLs to HTTPS and causing issues, ensuring that your CloudFront distribution fully supports HTTPS is critical. This includes having a valid SSL certificate and correctly configured DNS records.

  • Mixed Content: If your page is served over HTTPS but contains mixed content (some resources are loaded over HTTP), browsers may block those resources. Ensure all resources are loaded over HTTPS.

profile picture
EXPERT
answered 3 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions