manager - ssl amazon ec2

La distribución de origen personalizado de Cloudfront devuelve 502 "ERROR La solicitud no pudo ser satisfecha" para algunas URL (12)

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

Tras una investigación adicional, Cloudfront devuelve un extraño mensaje de error que nunca he visto antes para la URL en cuestión :

ERROR
La solicitud no pudo ser satisfecha.
Generado por 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 para lo que funciona y lo que no funciona.

Algunos otros puntos de datos:

Las URL de origen funcionan bien. No ha habido interrupciones recientes en el servicio, que yo sepa.
Invalidé específicamente la URL del logotipo, sin ningún efecto.
He invalidado 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>

Acabo de solucionar este problema y, en mi caso, estaba relacionado con redireccionamientos, pero no con configuraciones incorrectas 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 sus URL de la nube . Parece que esto es muy común si olvidas cambiar las configuraciones. Por ejemplo, digamos si tiene www.yoursite.com CNAME en 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 redireccionar 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.

El problema, en mi caso, era que estaba usando Cloudflare de Amazon y Cloudfront''s Cloudfront en tándem, ya 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, establecí la "Configuración mínima de TLS" en 1.2, sin habilitar la configuración de comunicación de 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 contra Cloudflare.

Para solucionarlo, 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 solucionar este problema, utilicé las versiones de línea de comando de curl, para ver qué Cloudfront realmente estaba devolviendo cuando solicitó una imagen desde su CDN, y también usé la versión de línea de comandos de openssl, para determinar exactamente qué protocolos Cloudflare era ofreciendo (no estaba ofreciendo TLS 1.0).

tl: dr; asegúrese de que todo acepte y solicite TLS 1.2 o cualquier TLS reciente y más grande que todos estén usando para cuando lea esto.

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

Si otros obtienen este error, verifique que el certificado SSL sea válido. Puede habilitar el inicio de sesión en s3 a través de la interfaz de AWS CloudFront Distribution para ayudar en la depuración.

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

En mi caso, uso nginx como proxy inverso para una URL de puerta de enlace API. 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 hacer llamadas de API a API Gateway

En nuestro caso, eliminamos el soporte para SSL3, TLS1.0 y TLS1.1 para cumplir con PCI-DSS en nuestros servidores de origen. Sin embargo, debe agregar manualmente soporte para TLS 1.1+ en su configuración de servidor de origen CloudFront . La consola de AWS muestra la configuración de SSL de cliente a CF, pero no muestra fácilmente la configuración de CF a origen hasta que desgloses. Para solucionarlo, en la consola de AWS en CloudFront:

Haga clic en DISTRIBUCIONES.
Seleccione su distro
Haga clic en la pestaña ORÍGENES.
Seleccione su servidor de origen.
Haga clic en EDITAR.
Seleccione todos los protocolos que su origen admite en "Protocolos SSL de origen"

En nuestro caso, todo PARECÍA bien, pero tomó 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 emitirse 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

Si el servidor de origen devuelve un certificado no válido o un certificado autofirmado, o si el servidor de origen devuelve la cadena de certificados en el orden incorrecto, CloudFront elimina la conexión TCP, devuelve el código de error HTTP 502 y establece el encabezado X-Cache en Error desde la nube.

Hemos habilitado los sistemas de cifrado correctos según: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption

Nuestro certificado fue válido de acuerdo con Google, Firefox y ssl-checker: https://www.sslshopper.com/ssl-checker.html

Sin embargo, el último certificado en la cadena de correctores ssl era "COMODO RSA Domain Validation Secure Server CA", emitido por "COMODO RSA Certification Authority".

Parece que CloudFront no posee el certificado para "COMODO RSA Certification Authority" y, como tal, cree que el certificado proporcionado por el servidor de origen está autofirmado.

Esto estuvo funcionando 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 ellos 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 "COMODO RSA Certification Authority", 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 volver a señalar AddTrust / USERTrust. Nota: también puede abrir el certificado raíz incorrecto de la ruta, hacer clic en "Detalles" -> "Editar propiedades" y luego desactivarlo de esa manera. Esto actualizó la ruta de inmediato. También es posible que deba eliminar varias copias del certificado, que se encuentra en "Personal" y "Autoridades de certificación de 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 CA Raíz externa"

Finalmente, CloudFront aceptó el certificado del servidor de origen y la cadena provista como de confianza. ¡Nuestro CDN comenzó a funcionar correctamente otra vez!

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

Encontré mi respuesta y la agregué aquí en caso de que ayudara 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 causó que CloudFront no encuentre mi archivo y arroje 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!

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

Recientemente tuve un problema similar que se debió a ssl_ciphers que estaba usando.

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

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

Tuve que cambiar mi confg de nginx para agregar AES128-SHA (RC4 en desuso: ALTO) 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;

Se solucionó este problema concatenando 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

Entonces:

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

¡Espero eso ayude!

Tuve este error hoy con Amazon Cloudfront. Debido a que el cname que utilicé (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 la nube en mi panel de control de sitio / hosting, pero también debe agregarlo al panel de Amazon CloudFront.

Una solución más posible: tengo un servidor intermedio que sirve el sitio y los recursos de Cloudfront a través de HTTP. Tenía mi origen configurado en "Visor de coincidencias" en lugar de "Solo HTTP". También uso la extensión HTTPS Everywhere, que redirigió todas las URL http://*.cloudfront.net a la versión https://* . Dado que el servidor intermedio no está disponible a través de SSL y Cloudfront estaba haciendo coincidir el visor, no pudo encontrar los activos en https://example.com y almacenó en caché un montón de 502 en su lugar.