Best IT Recipes

Cloudfront user-origin distribution returns 502 "ERROR. Request could not be satisfied." for some urls

We have a Cloudfront distribution with a customizable origin that has been working very well for quite some time now, serving static assets for one of our sites. This morning we noticed that our logo appears as a broken link.

After further study, Cloudfront returns a strange error message that I have never seen before for a URL :

Mistake

The request could not be satisfied.





Created by a cloud area (CloudFront)

Several other Cloudfront URLs from this distribution return the same error, but others (again from the same distribution) work fine. I do not see a template of what works and what doesn’t.

Some other data points:

  • source urls are working fine. As far as I know, there has not been a recent service interruption.
  • I really didn’t invalidate the logo URL, without any consequences.
  • I invalidated the root URL of the distribution without affecting.

Any idea what is going on here? I have never seen Cloudfront do this before.

UPDATE:

Here's the verbatim HTTP response from Cloudfront:

$ http GET https://d2yu7foswg1yra.cloudfront.net/static/img/crossway_logo.png HTTP/1.1 502 Bad Gateway Age: 213 Connection: keep-alive Content-Length: 472 Content-Type: text/html Date: Wed, 18 Dec 2013 17:57:46 GMT Server: CloudFront Via: 1.1 f319e8962c0268d31d3828d4b9d41f98.cloudfront.net (CloudFront) X-Amz-Cf-Id: H_HGBG3sTOqEomHzHubi8ruLbGXe2MRyVhGBn4apM0y_LjQa_9W2Jg== X-Cache: Error from cloudfront <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>ERROR: The request could not be satisfied</TITLE> </HEAD><BODY> <H1>ERROR</H1> <H2>The request could not be satisfied.</H2> <HR noshade size="1px"> </BODY></HTML> <BR clear="all"> <HR noshade size="1px"> <ADDRESS> Generated by cloudfront (CloudFront) </ADDRESS> </BODY></HTML>
+64
ssl amazon-cloudfront cdn
Dec 18 '13 at 16:58
source share
12 answers

I recently had a similar problem that turned out to be caused by ssl_ciphers, which I used.

From http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html ,

"CloudFront redirects HTTPS requests to the source server using SSLv3 or TLSv1 and AES128-SHA1 or RC4-MD5 ciphers. If your source server does not support AES128-SHA1 or RC4-MD5 ciphers, CloudFront cannot establish an SSL connection to your source . "

I had to change my nginx config to add AES128-SHA (deprecated RC4: HIGH) to ssl_ciphers to fix error 302. Hope this helps. I inserted a line from my ssl.conf

 ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5;
+31
Apr 28 '14 at 19:04
source share

I had this error today with Amazon Cloudfront. This is due to the fact that the cname that I used (for example, cdn.example.com) was not added to the distribution settings in the "alternative names" section, I only had cdn.example.com redirected to the cloud domain in the panel site / hosting management, but you also need to add it to your Amazon CloudFront dashboard.

+125
May 12 '14 at
source share

Found his answer and added it here if he helps David (and others).

It turns out that my source server (say, www.example.com) has 301 redirect settings for it to change HTTP to HTTPS:

 HTTP/1.1 301 Moved Permanently Location: https://www.example.com/images/Foo_01.jpg

However, my Origin protocol policy was configured only for HTTP. This caused CloudFront to not find my file and throw error 502. In addition, I think it cached error 502 for 5 minutes or so, since it did not work right after deleting the 301 redirect.

Hope this helps!

+14
Dec 18 '13 at 20:23
source share

In our case, everything WATCH OK, but it took most of the day to figure it out:

TL; DR: Check the certificate paths to make sure the root certificate is correct. In the case of COMODO certificates, it should say "USERTrust" and the "AddTrust External CA Root" should be released. NOT "COMODO" issued by "COMODO RSA Certification Authority".

In CloudFront docs: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

If the source server returns an invalid certificate or a self-signed certificate, or if the source server returns the certificate chain in the wrong order, CloudFront removes the TCP connection, returns the HTTP error code 502, and sets the X-Cache header to Error from cloudfront.

We had the correct ciphers according to: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption

Our certificate is valid according to Google, Firefox and ssl-checker: https://www.sslshopper.com/ssl-checker.html

SSL Checker result without all required certificates

However, the last certificate in the ssl verification chain was "CAODO RSA Domain Validation Secure Server CA" issued by the "COMODO RSA Certification Authority"

It seems that CloudFront does not have a certificate for the "COMODO RSA Certification Authority", and therefore believes that the certificate provided by the origin server is signed on its own.

This worked for a long time before it suddenly stopped. It so happened that I just updated our certificates for the year, but during the import something was changed in the path to the certificate for all previous certificates. They all started referring to the “COMODO RSA Certification Authority”, whereas before the chain was longer and the root was “AddTrust External CA Root”.

Bad certificate path

Because of this, switching to the old certificate did not fix the cloud problem.

I had to remove an additional certificate called "COMODO RSA Certification Authority", which did not refer to AddTrust. After that, all the certificate paths of my websites are updated to return to AddTrust / USERTrust again. A note can also open a bad root certificate from a path, click Details → Change Properties, and then disable it this way. This will immediately update the path. You may also need to delete several copies of the certificate found in the Personal and Trusted Root Certificate Authorities sections.

Good certificate path

Finally, I had to re-select the certificate in IIS in order to get it to serve the new certificate chain.

After that, ssl-checker began to display the third certificate in the chain, which pointed to "AddTrust External CA Root"

SSL Checker with all certificates

Finally, CloudFront accepted the server of origin certificate and the provided chain as trusted. Our CDN started working correctly again!

To prevent this from happening in the future, we will need to export our newly created certificates from a machine with the correct certificate chain, i.e. do not trust or remove the certificate "COMODO RSA Certification Authroity" issued by "COMODO RSA Certification Authroity" (expiring in 2038). Apparently, this affects Windows machines where this certificate is installed by default.

+8
Jun 04 '15 at 3:01
source share

I just went through fixing this problem, and in my case it is really connected with redirection, but not connected with incorrect settings in my CloudFront Origin or Behavior. This will happen if your source server is still redirecting to the source URLs, rather than what you configured for your cloud network URLs . This seems to be very common if you forgot to change the configs. For example, let's say if you have www.Yoursite.com CNAME for your cloud distribution, with a source of www.yoursiteorigin.com. Obviously, people will come to www.yoursite.com. But if your code tries to redirect to any page on www.yoursiteorigin.com, you will get this error.

For me, my background still redirected http-> https to my source URLs, not my Cloudfront URLs.

+2
Dec 20 '14 at 2:06
source share

In my case, this happened because we had an invalid ssl certificate. The problem was in our intermediate box, and we also use our prod certificate. It worked over the past few years with this configuration, but all of a sudden we started getting this error. It’s strange.

If other users get this error, make sure the ssl certificate is valid. You can enable logging on s3 using the AWS CloudFront Distribution interface to help debug.

Alternatively, you can refer to the amazon docs on this subject: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

+2
Jan 23 '15 at 22:02
source share

Another possible solution: I have an intermediate server that serves the Cloudfront site and resources through HTTP. I had the value set to "Match Viewer" instead of "HTTP Only". I also use the HTTPS Everywhere extension, which redirects all http://*.cloudfront.net to the https://* version. Since the staging server was unavailable over SSL, and Cloudfront matched the viewer, he could not find the assets at https://example.com and instead cached a bunch of 502s.

+2
Jun 15 '15 at 10:22
source share

In our case, we refused support for SSL3, TLS1.0, and TLS1.1 for PCI-DSS compliance on our source servers. However, you must manually add support for TLS 1. 1+ in the configuration of your original CloudFront server . The AWS console displays the SSL settings between the client and CF, but it is not so easy to display the CF-to-origin settings until you complete the granularity. To fix this, in the AWS console under CloudFront:

  1. Click DISTRIBUTIONS.
  2. Choose your distribution.
  3. Click on the ORIGINS tab.
  4. Choose your source server.
  5. Click EDIT.
  6. Select all the protocols that your source supports in the "Origin SSL Protocols" section
+1
Apr 09 '18 at 22:16
source share

I ran into this problem that resolved after I stopped using proxies. CloudFront might blacklist some IP addresses.

0
Apr 01 '14 at 4:42
source share

Fixed a bug related to the concatenation of my certificates to create a valid certificate chain (using GoDaddy Standard SSL + Nginx).

http://nginx.org/en/docs/http/configuring_https_servers.html#chains

To create a chain:

 cat 123456789.crt gd_bundle-g2-g1.crt > my.domain.com.chained.crt

Then:

 ssl_certificate /etc/nginx/ssl/my.domain.com.chained.crt; ssl_certificate_key /etc/nginx/ssl/my.domain.com.key;

Hope this helps!

0
Nov 13 '15 at 16:31
source share

In my case, I use nginx as a reverse proxy for the API gateway URL. I got the same error.

I solved the problem by adding the following two lines to the Nginx configuration:

 proxy_set_header Host "XXXXXX.execute-api.REGION.amazonaws.com"; proxy_ssl_server_name on;

Source here: Configuring proxy_pass in nginx to make API calls to the Gateway API

0
Feb 22 '18 at 8:50
source share

The problem, in my case, was that I used Amazon Cloudflare and Cloudfront Cloudfront in tandem, and Cloudfront did not like the settings that I provided to Cloudflare.

In particular, in the Crypto settings on Cloudflare, I set the “Minimum TLS Settings” to 1.2 without turning on the TLS 1.2 communication option for distribution to Cloudfront. This was enough for Cloudfront to report a 502 Bad Gateway error when trying to connect to a secure Cloudflare server.

To fix this, I had to disable SSLv3 support in the source settings for this Cloudfront distribution and enable TLS 1.2 as a supported protocol for this origin server.

To fix this problem, I used curl versions for the command line to see what Cloudfront actually returned when you requested the image from its CDN, and I also used the openssl version for the command line to determine exactly which protocols Cloudflare was. offering (not offering TLS 1.0).

TL: dr; make sure everyone accepts and requests TLS 1.2 or any of the latest and best TLS that everyone is using at the time of reading.

0
Jul 06 '18 at 22:02
source share


More articles:


All Articles