Ответ 1

Недавно у меня была аналогичная проблема, которая, как оказалось, была вызвана ssl_ciphers, которую я использовал.

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

"CloudFront перенаправляет HTTPS-запросы на исходный сервер с использованием протоколов SSLv3 или TLSv1 и шифров AES128-SHA1 или RC4-MD5. Если ваш исходный сервер не поддерживает шифры AES128-SHA1 или RC4-MD5, CloudFront не может установить SSL-соединение с вашим источником."

Мне пришлось изменить свой конфиг nginx, чтобы добавить AES128-SHA (устаревший RC4: HIGH) в ssl_ciphers, чтобы исправить ошибку 302. Надеюсь, это поможет. Я вставил строку из моего ssl.conf

ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5;

Ответ 2

У меня была эта ошибка сегодня с Amazon Cloudfront. Это связано с тем, что cname, который я использовал (например, cdn.example.com), не был добавлен в настройки распространения в разделе "альтернативные имена", у меня только был cdn.example.com, перенаправленный в облачный домен на панели управления сайтом/хостингом, но вам также нужно добавить его на панель Amazon CloudFront.

Ответ 3

Нашел свой ответ и добавил его здесь, если он помогает Дэвиду (и другим).

Оказывается, мой исходный сервер (скажем, www.example.com) имеет 301 настройку перенаправления на него для изменения HTTP на HTTPS:

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

Однако моя политика протокола Origin была настроена только на HTTP. Это вызвало CloudFront, чтобы не найти мой файл и выбросить ошибку 502. Кроме того, я думаю, что он кэшировал ошибку 502 в течение 5 минут или около того, так как он не работал сразу после удаления перенаправления 301.

Надеюсь, что это поможет!

Ответ 4

В нашем случае все СМОТРЕТЬ ОК, но это заняло большую часть дня, чтобы понять это:

TL;DR: Проверьте пути сертификатов, чтобы убедиться, что корневой сертификат правильный. В случае сертификатов COMODO он должен сказать "USERTrust" и должен быть выпущен "AddTrust External CA Root" . НЕ "COMODO", выданный "Центром сертификации COMODO RSA".

В документах CloudFront: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

Если исходный сервер возвращает недопустимый сертификат или самозаверяющий сертификат, или если исходный сервер возвращает цепочку сертификатов в неправильном порядке, CloudFront удаляет TCP-соединение, возвращает код ошибки HTTP 502 и устанавливает X-Cache заголовок в Error from cloudfront.

У нас были правильные шифры в соответствии с: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption

Наш сертификат действителен в соответствии с Google, Firefox и ssl-checker: https://www.sslshopper.com/ssl-checker.html

Однако последним сертификатом в цепочке проверки ssl был "CAODO RSA Domain Validation Secure Server CA", выпущенный "Центром сертификации COMODO RSA"

Кажется, что CloudFront не имеет сертификата для "Центра сертификации COMODO RSA", и поэтому считает, что сертификат, предоставленный сервером происхождения, подписан сам по себе.

Это работало долгое время, прежде чем вдруг внезапно остановилось. Случилось так, что я только что обновил наши сертификаты за год, но во время импорта что-то было изменено в пути к сертификату для всех сертификатов previous. Все они начали ссылаться на "Сертификационный центр COMODO RSA", тогда как до того, как цепь была длиннее, а корень был "AddTrust External CA Root" .

Из-за этого переход на старый сертификат не устранил проблему облачного режима.

Мне пришлось удалить дополнительный сертификат под названием "Центр сертификации COMODO RSA", который не ссылался на AddTrust. После этого все пути сертификатов моих веб-сайтов обновляются, чтобы снова вернуться к AddTrust/USERTrust. Примечание также может открыть плохой корневой сертификат из пути, нажмите "Подробности" → "Изменить свойства", а затем отключите его таким образом. Это немедленно обновит путь. Вам также может потребоваться удалить несколько копий сертификата, найденного в разделе "Личные" и "Доверенные корневые центры сертификации"

Наконец, мне пришлось повторно выбрать сертификат в IIS, чтобы заставить его обслуживать новую цепочку сертификатов.

После этого ssl-checker начал отображать третий сертификат в цепочке, который указывал на "AddTrust External CA Root"

Наконец, CloudFront принял сертификат сервера происхождения и предоставленную цепочку как доверенную. Наш CDN снова начал работать правильно!

Чтобы это не происходило в будущем, нам нужно будет экспортировать наши вновь созданные сертификаты с машины с правильной цепочкой сертификатов, т.е. не доверять или удалять сертификат "COMODO RSA Certification Authroity", выпущенный "COMODO RSA Certification Authroity" ( истекающий в 2038 году). По-видимому, это влияет на машины Windows, где этот сертификат установлен по умолчанию.

Ответ 5

Я только что прошел через устранение этой проблемы, и в моем случае это действительно связано с переадресацией, но не связано с неправильными настройками в моем CloudFront Origin или Behavior. Это произойдет, если ваш исходный сервер все еще перенаправляется на исходные URL-адреса, а не то, что вы настроили для своих URL-адресов облачной сети. Кажется, это очень распространено, если вы забыли изменить конфиги. Например, скажем, если у вас есть www.Yoursite.com CNAME для вашего облачного распространения, с источником www.yoursiteorigin.com. Очевидно, люди придут на сайт www.yoursite.com. Но если ваш код пытается перенаправить на любую страницу на www.yoursiteorigin.com, вы получите эту ошибку.

Для меня мое происхождение по-прежнему выполняло перенаправления http- > https на мои исходные URL-адреса, а не на мои URL-адреса Cloudfront.

Ответ 6

В моем случае это произошло потому, что у нас был недействительный сертификат ssl. Проблема была в нашей промежуточной коробке, и мы также используем наш сертификат prod. Он работал в течение последних нескольких лет с этой конфигурацией, но внезапно мы начали получать эту ошибку. Странно.

Если другие пользователи получают эту ошибку, убедитесь, что сертификат ssl действителен. Вы можете включить ведение журнала на s3 с помощью интерфейса AWS CloudFront Distribution, чтобы помочь отлаживать.

Кроме того, вы можете обратиться к документам amazon по этому вопросу: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

Ответ 7

Еще одно возможное решение: у меня есть промежуточный сервер, который обслуживает сайт и ресурсы Cloudfront через HTTP. У меня было установленное значение "Match Viewer" вместо "HTTP Only". Я также использую расширение HTTPS Everywhere, которое перенаправило все URL http://*.cloudfront.net в версию https://*. Поскольку промежуточный сервер недоступен через SSL, а Cloudfront соответствовал зрителю, он не мог найти активы в https://example.com и вместо этого кэшировал кучу 502с.

Ответ 8

В нашем случае мы отказались от поддержки SSL3, TLS1.0 и TLS1.1 для соответствия PCI-DSS на наших исходных серверах. Тем не менее, вы должны вручную добавить поддержку TLS 1. 1+ в конфигурации вашего исходного сервера CloudFront. Консоль AWS отображает настройки SSL между клиентом и CF, но не так просто отображает настройки CF-to-origin до тех пор, пока вы не выполните детализацию. Чтобы исправить это, в консоли AWS под CloudFront:

1. Нажмите РАСПРЕДЕЛЕНИЯ.
2. Выберите свой дистрибутив.
3. Перейдите на вкладку ORIGINS.
4. Выберите свой исходный сервер.
5. Нажмите РЕДАКТИРОВАТЬ.
6. Выберите все протоколы, которые поддерживает ваш источник, в разделе "Origin SSL Protocols"

Ответ 9

Я столкнулся с этой проблемой, которая разрешилась после того, как я прекратил использовать прокси. Возможно, CloudFront занесет в черный список некоторые IP-адреса.

Ответ 10

Исправлена ​​ошибка, связанная с конкатенацией моих сертификатов для создания допустимой цепочки сертификатов (с использованием GoDaddy Standard SSL + Nginx).

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

Чтобы создать цепочку:

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

Тогда:

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

Надеюсь, что это поможет!

Ответ 11

В моем случае я использую nginx в качестве обратного прокси для URL-адреса шлюза API. Я получил ту же ошибку.

Я решил проблему, добавив следующие две строки в конфигурацию Nginx:

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

Источник здесь: Настройка proxy_pass в nginx для выполнения вызовов API к API Gateway

Ответ 12

Проблема, в моем случае, заключалась в том, что я использовал Amazon Cloudflare и Cloudfront Cloudfront в тандеме, и Cloudfront не понравились настройки, которые я предоставил Cloudflare.

В частности, в настройках Crypto на Cloudflare я установил "Минимальные настройки TLS" на 1.2, не включив параметр связи TLS 1.2 для распространения в Cloudfront. Этого было достаточно, чтобы Cloudfront объявлял ошибку 502 Bad Gateway при попытке подключения к защищенному Cloudflare серверу.

Чтобы это исправить, мне пришлось отключить поддержку SSLv3 в настройках источника для этого дистрибутива Cloudfront и включить TLS 1.2 в качестве поддерживаемого протокола для этого сервера происхождения.

Чтобы устранить эту проблему, я использовал версии curl для командной строки, чтобы увидеть, что на самом деле возвращал Cloudfront, когда вы запрашивали образ из его CDN, и я также использовал версию openssl для командной строки, чтобы точно определить, какие протоколы были Cloudflare. предлагая (не предлагая TLS 1.0).

ТЛ: д-р; убедитесь, что все принимают и запрашивают TLS 1.2 или любой последний и самый лучший TLS, который каждый использует к моменту прочтения.