Недавно у меня была аналогичная проблема, которая, как выяснилось, была связана с 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;

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

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

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

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

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

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

В нашем случае все выглядело нормально, но на то, чтобы разобраться в этом, ушла большая часть дня:

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 значение «Ошибка». от облачного фронта.

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

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

Однако последним сертификатом в цепочке проверки ssl был «ЦС безопасного сервера для проверки домена COMODO RSA», выданный «Центром сертификации COMODO RSA».

Похоже, что CloudFront не имеет сертификата для «центра сертификации COMODO RSA» и считает, что сертификат, предоставленный исходным сервером, является самоподписанным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исправлена ​​эта проблема путем объединения моих сертификатов для создания действительной цепочки сертификатов (с использованием 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;

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

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

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

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

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

tl: dr; к тому времени, как вы это прочитаете, убедитесь, что все принимает и запрашивает TLS 1.2 или любой последний и лучший TLS, который все используют.

В моем конкретном случае это было связано с тем, что исходный ALB за моим поведением CloudFront имел сертификат ACM ПО УМОЛЧАНИЮ, который указывал на другое доменное имя.

Чтобы исправить это, мне пришлось:

1. Перейти к ALB
2. На вкладке Listeners выберите my Listener и затем Edit
3. Под сертификатом SSL по умолчанию выберите правильный исходный сертификат.

В моем случае я использую 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

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

1. Щелкните РАСПРЕДЕЛЕНИЕ.
2. Выберите свой дистрибутив.
3. Щелкните вкладку ИСТОЧНИКИ.
4. Выберите ваш исходный сервер.
5. Щелкните ИЗМЕНИТЬ.
6. Выберите все протоколы, которые поддерживает ваш источник, в разделе «Протоколы SSL источника».

Остерегайтесь политики протокола происхождения:

Для запросов средства просмотра HTTPS, которые CloudFront пересылает этому источнику, одно из доменных имен в сертификате SSL на исходном сервере должно совпадать с именем домена, которое вы указали в качестве имени домена источника. В противном случае CloudFront отвечает на запросы средства просмотра кодом состояния HTTP 502 (Плохой шлюз) вместо того, чтобы возвращать запрошенный объект.

В большинстве случаев вы, вероятно, захотите, чтобы CloudFront использовал только HTTP, поскольку он извлекает объекты с сервера, который, вероятно, также размещен на Amazon. На этом этапе нет необходимости в дополнительных сложностях HTTPS.

Обратите внимание, что это отличается от Viewer Политика протокола. Вы можете узнать больше о различиях между двумя здесь < / а>.