La distribución de origen personalizado de Cloudfront devuelve 502 "ERROR No se pudo satisfacer la solicitud". para algunas URL

71

Tenemos una distribución de Cloudfront con un origen personalizado que ha estado funcionando bien durante bastante tiempo, sirviendo activos estáticos para uno de nuestros sitios. Esta misma mañana, notamos que nuestro logotipo se mostraba como un enlace roto.

Tras una mayor investigación, Cloudfront está devolviendo un extraño mensaje de error que nunca antes había visto para la URL en cuestión :

ERROR

The request could not be satisfied.



Generated by cloudfront (CloudFront)

Varias otras URL de Cloudfront de esta distribución devuelven el mismo error, pero otras (de nuevo, de la misma distribución) funcionan bien. No veo un patrón de lo que funciona y lo que no.

Algunos otros puntos de datos:

  • Las URL de origen funcionan bien. No ha habido ninguna interrupción reciente en el servicio, que yo sepa.
  • He invalidado la URL del logotipo específicamente, sin ningún efecto.
  • Invalidé la URL raíz de la distribución, sin ningún efecto.

¿Alguna idea de lo que está pasando aquí? Nunca antes había visto a Cloudfront hacer esto.

ACTUALIZAR:

Aquí está la respuesta HTTP literal de 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>
3
  • 3
    Interesante ... Acabo de crear mi primera distribución (sin CNAME personalizado) y obtengo lo mismo. Empecé con todo lo básico pero sin suerte todavía. 18 dic '13 a las 18:35
  • Sí, creé una nueva distribución para probar y lo mismo. : \ 18 dic 2013 a las 19:10
  • Tuve un problema similar, aunque obtuve un tiempo de espera de puerta de enlace 504 para algunos archivos estáticos de una distribución de CloudFront. Me di cuenta de que había habilitado lo pglcmdque estaba bloqueando los rangos de IP a través de iptables. Todavía no sé por qué CloudFront estaba buscando estos archivos, que tienen encabezados de vencimiento configurados para un año. 27 de marzo de 2014 a las 13:21
128

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.

4
  • 4
    En mi caso fue un error tipográfico en el CNAME. ¡Duh! 25 dic '14 a las 3:07
  • 2
    ¡Gracias, esto lo arregló! 27/01/15 a las 5:22
  • 4
    Después de agregar el CNAME alternativo, el Estado de distribución de CloudFront (en la pestaña 'General') tarda un tiempo en pasar de 'En curso' a 'Implementado'. Durante este tiempo, seguirá recibiendo un mensaje de error similar de CloudFront. Tomó alrededor de media hora en mi caso. 19 de ene. De 2017 a las 20:48
  • 1
    Para que algunos encuentren el cambio de cname: vaya a la CloudFrontsección => seleccione su frente de nube => seleccione General=> Edit=> agregue su URL CNAME en Alternate Domain Names (CNAMEs)(está en la tercera línea)
    seuling
    12/07/18 a las 6:16
35

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;
3
  • Esta parece ser la solución correcta para mi problema particular, aunque parece que puede haber varias formas de obtener ese mensaje de error, reflejado en las otras respuestas aquí. 25 de junio de 2014 a las 23:29
  • 5
    Es posible que desee utilizar en AES128-SHAlugar de RC4:HIGH. El uso de la RC4:HIGHcalificación degradada de la prueba de Qualsys SSL Labs de una A a una C. 25 de junio de 2014 a las 23:39
  • Esto también solucionó mi problema. Sin embargo, tuve que usar AES128-SHA1, con el "1". Sin el 1 no funcionó para mí. Además, AWS recomienda usar TLSv1y no SSLv3, que es menos seguro. 17/12/2016 a las 0:13
13

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!

4
  • ¡Hm! No es mi situación, pero apuesto a que está muy cerca. 18 dic 2013 a las 22:14
  • ¿Estás seguro? Ejecuté su URL como http y obtuve: HTTP / 1.1 301 Movido permanentemente Servidor: nginx / 0.7.65 Fecha: Jue, 19 de diciembre de 2013 05:00:15 GMT Tipo de contenido: texto / html Longitud del contenido: 185 Conexión: mantener -Ubicación viva: my.crossway.org/static/img/crossway_logo.png <html> <head> <title> 301 Movido permanentemente </title> </head> <body bgcolor = "white"> <center> <h1 > 301 Movido permanentemente </h1> </center> <hr> <center> nginx / 0.7.65 </center> </body> </html> 19 de diciembre de 2013 a las 5:01
  • 1
    Pero no estoy usando HTTP Onlyen mi Política de Origen, estoy usando Match Viewer. Lo extraño es que funcionó bien hasta hace poco. 19 dic 2013 a las 17:02
  • Creo que incluso si usa 'visor de coincidencias', puede causar un problema, incluso si no debería. Golpeé lo mismo donde tenía un 301 en la página de inicio y rompió esa página para la longitud de caché de 5 minutos.
    Peter
    19/12/2014 a las 23:24
9

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

Resultado de SSL Checker sin todos los certificados requeridos

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".

Ruta de certificado incorrecta

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".

Buena ruta de certificado

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".

Comprobador SSL con todos los certificados

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.

4

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.

2

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.

2

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

1

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.

1

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!

1

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.

1

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.
1

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í .

1
  • Esta solución funcionó en mi caso. Sin embargo, ¿es menos seguro? ¿Algún riesgo?
    JBS
    25 de agosto a las 14:31
0

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

0

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".