Hoy tuve este error con Amazon Cloudfront. Fue porque el cname que usé (por ejemplo, cdn.example.com) no se agregó a la configuración de distribución en "cnames alternativos", solo tuve cdn.example.com reenviado al dominio de cloudfront en mi sitio / panel de control de alojamiento, pero también debe agregarlo al panel de Amazon CloudFront.

Recientemente tuve un problema similar que resultó ser debido a ssl_ciphers que estaba usando.

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

"CloudFront reenvía las solicitudes HTTPS al servidor de origen mediante los protocolos SSLv3 o TLSv1 y los cifrados AES128-SHA1 o RC4-MD5. Si su servidor de origen no admite los cifrados AES128-SHA1 o RC4-MD5, CloudFront no puede establecer una conexión SSL a tu origen ".

Tuve que cambiar mi confg nginx para agregar AES128-SHA (RC4 obsoleto: HIGH) a ssl_ciphers para corregir el error 302. Espero que esto ayude. He pegado la línea de mi ssl.conf

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

Encontré mi respuesta y la agregué aquí en caso de que ayude a David (y a otros).

Resulta que mi servidor de origen (digamos www.example.com) tenía una configuración de redireccionamiento 301 para cambiar HTTP a HTTPS:

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

Sin embargo, mi Política de protocolo de origen se configuró solo en HTTP. Esto hizo que CloudFront no encontrara mi archivo y arrojara un error 502. Además, creo que guardó en caché el error 502 durante 5 minutos más o menos, ya que no funcionó inmediatamente después de eliminar esa redirección 301.

¡Espero que ayude!

En nuestro caso, todo parecía estar bien, pero nos llevó la mayor parte del día resolver esto:

TLDR: Verifique las rutas de su certificado para asegurarse de que el certificado raíz sea correcto. En el caso de los certificados COMODO, debe decir "USERTrust" y ser emitido por "AddTrust External CA Root". NO "COMODO" emitido por "COMODO RSA Certification Authority".

De los documentos de CloudFront: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

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

Teníamos los cifrados correctos habilitados según: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption

Nuestro certificado era válido según Google, Firefox y ssl-checker: https://www.sslshopper.com/ssl-checker.html

Sin embargo, el último certificado en la cadena de verificación ssl fue "COMODO RSA Domain Validation Secure Server CA", emitido por "COMODO RSA Certification Authority"

Parece que CloudFront no posee el certificado de "Autoridad de certificación COMODO RSA" y, como tal, cree que el certificado proporcionado por el servidor de origen está autofirmado.

Esto funcionó durante mucho tiempo antes de que aparentemente se detuviera repentinamente. Lo que sucedió fue que acababa de actualizar nuestros certificados para el año, pero durante la importación, algo cambió en la ruta del certificado para todos los certificados anteriores . Todos comenzaron a hacer referencia a "COMODO RSA Certification Authority", mientras que antes la cadena era más larga y la raíz era "AddTrust External CA Root".

Debido a esto, volver al certificado anterior no solucionó el problema de la nube.

Tuve que eliminar el certificado adicional llamado "Autoridad de certificación COMODO RSA", el que no hacía referencia a AddTrust. Después de hacer esto, todas las rutas de los certificados de mi sitio web se actualizaron para apuntar nuevamente a AddTrust / USERTrust. Note también puede abrir el certificado raíz incorrecto de la ruta, haga clic en "Detalles" -> "Editar propiedades" y luego deshabilítelo de esa manera. Esto actualizó la ruta de inmediato. Es posible que también deba eliminar varias copias del certificado, que se encuentran en "Personal" y "Autoridades de certificación raíz de confianza".

Finalmente tuve que volver a seleccionar el certificado en IIS para que sirviera a la nueva cadena de certificados.

Después de todo esto, ssl-checker comenzó a mostrar un tercer certificado en la cadena, que apuntaba a "AddTrust External CA Root".

Finalmente, CloudFront aceptó el certificado del servidor de origen y la cadena proporcionada como confiables. ¡Nuestro CDN comenzó a funcionar correctamente nuevamente!

Para evitar que esto suceda en el futuro, necesitaremos exportar nuestros certificados recién generados desde una máquina con la cadena de certificados correcta, es decir, desconfiar o eliminar el certificado "COMODO RSA Certification Authroity" emitido por "COMODO RSA Certification Authroity" (que expira en 2038 ). Esto solo parece afectar a las máquinas con Windows, donde este certificado está instalado de forma predeterminada.

Una posible solución más: tengo un servidor provisional que sirve al sitio y a los activos de Cloudfront a través de HTTP. Tenía mi origen configurado en "Visor de coincidencias" en lugar de "Solo HTTP". También utilizo la extensión HTTPS Everywhere, que redirigió todas las http://*.cloudfront.netURL a la https://*versión. Dado que el servidor de ensayo no está disponible a través de SSL y Cloudfront coincidía con el visor, no pudo encontrar los activos en https://example.comy almacenó en caché un montón de 502.

Acabo de solucionar este problema y, en mi caso, estaba relacionado con las redirecciones, pero no con la configuración incorrecta en mi CloudFront Origin o Behavior. Esto sucederá si su servidor de origen todavía está redireccionando a las URL de origen, y no a lo que ha configurado para las URL de su nube . Parece que esto es muy común si se olvida de cambiar las configuraciones. Por ejemplo, digamos si tiene www.yoursite.com CNAME para su distribución en la nube, con un origen de www.yoursiteorigin.com. Obviamente, la gente vendrá a www.yoursite.com. Pero si su código intenta redirigir a cualquier página en www.yoursiteorigin.com, obtendrá este error.

Para mí, mi origen todavía estaba haciendo los redireccionamientos http-> https a mis URL de origen y no a mis URL de Cloudfront.

En mi caso, fue porque teníamos un certificado SSL no válido. El problema estaba en nuestra caja de preparación y también usamos nuestro certificado de prod. Había funcionado durante los últimos años con esta configuración, pero de repente comenzamos a recibir este error. Extraño.

Si otros reciben este error, verifique que el certificado ssl sea válido. Puede habilitar el registro en s3 a través de la interfaz de distribución de AWS CloudFront para ayudar con la depuración.

Además, puede consultar los documentos de Amazon sobre el tema aquí: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

Me encontré con este problema, que se resolvió solo después de que dejé de usar un proxy. Quizás CloudFront esté incluyendo algunas direcciones IP en la lista negra.

Se solucionó este problema al concatenar mis certificados para generar una cadena de certificados válida (usando GoDaddy Standard SSL + Nginx).

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

Para generar la cadena:

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

Luego:

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

¡Espero eso ayude!

El problema, en mi caso, era que estaba usando Cloudflare de Amazon y Cloudfront de Cloudfront en conjunto, y a Cloudfront no le gustaba la configuración que le había proporcionado a Cloudflare.

Más específicamente, en la configuración de Crypto en Cloudflare, había establecido la "Configuración mínima de TLS" en 1.2, sin habilitar la configuración de comunicación TLS 1.2 para la distribución en Cloudfront. Esto fue suficiente para que Cloudfront declarara un error 502 Bad Gateway cuando intentó conectarse al servidor protegido por Cloudflare.

Para solucionar esto, tuve que deshabilitar la compatibilidad con SSLv3 en la Configuración de origen para esa distribución de Cloudfront y habilitar TLS 1.2 como protocolo compatible para ese servidor de origen.

Para depurar este problema, utilicé versiones de línea de comandos de curl, para ver lo que Cloudfront estaba devolviendo realmente cuando solicitó una imagen de su CDN, y también usé la versión de línea de comandos de openssl, para determinar exactamente qué protocolos era Cloudflare. ofreciendo (no estaba ofreciendo TLS 1.0).

tl: dr; asegúrese de que todo acepte y solicite TLS 1.2, o cualquier TLS más reciente y mejor que todos estén usando en el momento de leer esto.

Para mi caso particular, se debió al hecho de que el ALB de origen detrás de mi comportamiento de CloudFront tenía un certificado ACM PREDETERMINADO que apuntaba a un nombre de dominio diferente.

Para arreglar esto tuve que:

1. Ir al ALB
2. En la pestaña Oyentes, seleccione mi Oyente y luego Editar
3. En Certificado SSL predeterminado, elija el Certificado de origen correcto.

Tenga cuidado con la política del protocolo de origen :

For HTTPS viewer requests that CloudFront forwards to this origin, one of the domain names in the SSL certificate on your origin server must match the domain name that you specify for Origin Domain Name. Otherwise, CloudFront responds to the viewer requests with an HTTP status code 502 (Bad Gateway) instead of returning the requested object.

En la mayoría de los casos, probablemente desee que CloudFront utilice "Solo HTTP", ya que obtiene objetos de un servidor que probablemente también esté alojado en Amazon. No hay necesidad de complejidad HTTPS adicional en este paso.

Tenga en cuenta que esto es diferente a la Política de protocolo de visor . Puede leer más sobre las diferencias entre los dos aquí .

En mi caso, uso nginx como proxy inverso para una URL de API Gateway. Tengo el mismo error.

Resolví el problema cuando agregué las siguientes dos líneas a la configuración de Nginx:

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

La fuente está aquí: Configuración de proxy_pass en nginx para realizar llamadas API a API Gateway

En nuestro caso, habíamos dejado de admitir SSL3, TLS1.0 y TLS1.1 para el cumplimiento de PCI-DSS en nuestros servidores de origen. Sin embargo, debe agregar manualmente la compatibilidad con TLS 1.1+ en la configuración del servidor de origen de CloudFront . La consola de AWS muestra la configuración de SSL de cliente a CF, pero no le muestra fácilmente la configuración de CF al origen hasta que se desglosa. Para solucionarlo, en la consola de AWS en CloudFront:

1. Haz clic en DISTRIBUCIONES.
2. Seleccione su distribución.
3. Haga clic en la pestaña ORÍGENES.
4. Seleccione su servidor de origen.
5. Haga clic en EDITAR.
6. Seleccione todos los protocolos que admite su origen en "Protocolos SSL de origen".