Amazon recientemente lanzó una nueva característica en CloudFront que soporta certificados SSL personalizados sin cargo usando SNI (Server Name Indication).

Tengo mi set de distribución con una Clase gratuita de 1 certificado de StartSSL y todo estaba funcionando cuando me había dado cuenta de que el sitio iba a ir por un corto tiempo después de que se implementa. Ejecución de SSL Corrector vuelve que mi certificado está funcionando correctamente:

CloudFront error al momento de servir a través de HTTPS usando SNI

Pero luego me iba a golpear esta página de error al intentar acceder al sitio a través de HTTPS (iba a trabajar para la primera solicitud luego de ir abajo en los posteriores intentos de conectarse).

CloudFront error al momento de servir a través de HTTPS usando SNI

Aquí un detallado salida al acceder con ssl (tiene éxito en el índice):

$ curl -I -v -ssl https://wikichen.is
* Adding handle: conn: 0x7f9f82804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f9f82804000) send_pipe: 1, recv_pipe: 0
* About to connect() to wikichen.is port 443 (#0)
*   Trying 54.230.141.222...
* Connected to wikichen.is (54.230.141.222) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_RC4_128_MD5
* Server certificate: www.wikichen.is (6w984WNu7vM5OrdU)
* Server certificate: StartCom Class 1 Primary Intermediate Server CA
* Server certificate: StartCom Certification Authority
> HEAD /HTTP/1.1
> User-Agent: curl/7.30.0
> Host: wikichen.is
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Content-Length: 1153
Content-Length: 1153
< Connection: keep-alive
Connection: keep-alive
< Date: Sun, 09 Mar 2014 16:09:54 GMT
Date: Sun, 09 Mar 2014 16:09:54 GMT
< Cache-Control: max-age=120
Cache-Control: max-age=120
< Content-Encoding: gzip
Content-Encoding: gzip
< Last-Modified: Wed, 05 Mar 2014 20:40:48 GMT
Last-Modified: Wed, 05 Mar 2014 20:40:48 GMT
< ETag: "34685bc45353d1030d3a515ddba78f3e"
ETag: "34685bc45353d1030d3a515ddba78f3e"
* Server AmazonS3 is not blacklisted
< Server: AmazonS3
Server: AmazonS3
< Age: 4244
Age: 4244
< X-Cache: Hit from cloudfront
X-Cache: Hit from cloudfront
< Via: 1.1 4f672256eaca5524999342dc8678cdd2.cloudfront.net (CloudFront)
Via: 1.1 4f672256eaca5524999342dc8678cdd2.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: h4TEULH44TCi7m2lL42A8lO-5-Gmx8iY2M2C1AOmRlK543zFN6jCtQ==
X-Amz-Cf-Id: h4TEULH44TCi7m2lL42A8lO-5-Gmx8iY2M2C1AOmRlK543zFN6jCtQ==

<
* Connection #0 to host wikichen.is left intact

Luego falla en otras páginas:

$ curl -i -v https://wikichen.is/writing/index.html
* Adding handle: conn: 0x7fa153804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fa153804000) send_pipe: 1, recv_pipe: 0
* About to connect() to wikichen.is port 443 (#0)
*   Trying 54.230.140.160...
* Connected to wikichen.is (54.230.140.160) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_RC4_128_MD5
* Server certificate: www.wikichen.is (6w984WNu7vM5OrdU)
* Server certificate: StartCom Class 1 Primary Intermediate Server CA
* Server certificate: StartCom Certification Authority
> GET /writing/index.html HTTP/1.1
> User-Agent: curl/7.30.0
> Host: wikichen.is
> Accept: */*
>
< HTTP/1.1 502 Bad Gateway
HTTP/1.1 502 Bad Gateway
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 472
Content-Length: 472
< Connection: keep-alive
Connection: keep-alive
* Server CloudFront is not blacklisted
< Server: CloudFront
Server: CloudFront
< Date: Sun, 09 Mar 2014 17:54:41 GMT
Date: Sun, 09 Mar 2014 17:54:41 GMT
< Age: 6
Age: 6
< X-Cache: Error from cloudfront
X-Cache: Error from cloudfront
< Via: 1.1 9096435f28f91f92bacdf76122de09ee.cloudfront.net (CloudFront)
Via: 1.1 9096435f28f91f92bacdf76122de09ee.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: iAUOQbP8O4A0pI9KGvVz0VgBT1TW-j0yVDa7vdSvIAuxnKOyQghtnw==
X-Amz-Cf-Id: iAUOQbP8O4A0pI9KGvVz0VgBT1TW-j0yVDa7vdSvIAuxnKOyQghtnw==

<
<!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>
* Connection #0 to host wikichen.is left intact
</BODY></HTML>%

Gustaría algunos consejos para iniciar la solución de problemas.

  • Me han confirmado si usted todavía está viendo cualquier interacción en el error en las solicitudes, entre cloudfront y el servidor de origen en las solicitudes posteriores, en el servidor web de origen de los registros? También, algo útil aquí? stackoverflow.com/questions/20664018
  • He habilitado HTTP y HTTPS en mi distribución, el ex funciona a la perfección, se trata de servir con SSL que tiene el problema. Profundizaremos en los registros para ver lo que puedo encontrar.
  • Ambos S3 y CloudFront va a escribir los registros y colóquelos en un cubo de especificar, cada pocos minutos. Si el S3 está recibiendo las solicitudes y devolver un error que cloudfront ofusca, o algo más, podría ser visible a partir de los registros. También es interesante que su mensaje de error en sí es en realidad una caché (!) con Cloudfront mostrando su Age: 6 (segundos)… es el origen de la configuración de un sencillo «Origen» Tipo = «S3 Origen»?
  • Gracias por toda su ayuda – se ha solucionado ahora. Respuesta a continuación.
InformationsquelleAutor wikichen | 2014-03-09

3 Comentarios

  1. 55

    Un amable representante por el nombre de [email protected] AWS AWS CloudFront foros de resolver esto por mí:

    He identificado su distribución CloudFront y el S3
    actúa como el origen de esta distribución.

    Puedo volver a crear y explicar el intermitente ‘502 Bad Gateway’
    la respuesta que está recibiendo.

    Esta respuesta es devuelto por CloudFront cuando intenta tener acceso a un
    URL utilizando el protocolo HTTPS, que actualmente no está en la caché por
    CloudFront. La razón de este error es CloudFront es intentar
    póngase en contacto con su origen mediante el protocolo HTTPS, y esto está fallando.

    La razón de este fracaso es que usted ha configurado su origen como un
    S3, pero usted está utilizando el «Origen Personalizado» tipo y dirigir a
    el S3 URL del sitio web de este cubo. Si intenta golpear a tu S3
    URL del sitio web mediante HTTPS, se dará cuenta de que esto no funciona. S3 sitio web
    hosting soporta solamente de la porción de contenido mediante el protocolo HTTP
    (http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html#WebsiteRestEndpointDiff).

    Ahora, el intermitente de la carga de la página el comportamiento que usted está viendo es debido a
    CloudFront volviendo las páginas que actualmente tiene en su caché. Usted
    debe ser capaz de volver a crear esta situación de la siguiente manera:

    1. Golpear una página de su sitio web mediante HTTPS. Usted debe obtener una «502 Bad Gateway» error de nuevo.
    2. Éxito de la misma página a través de HTTP. Usted debe ver la página.
    3. Visita la página de nuevo el uso de HTTPS. Ahora debe conseguir el resultado esperado, como CF ha servido el contenido de su memoria caché en lugar de
      el intento de comunicarse con su origen.

    Para resolver este problema, pruebe lo siguiente:

    1. Abrir el CloudFront Consola de Administración y abrir su distribución.
    2. Navegar a los Orígenes de la ficha, seleccione el origen y haga clic en «Editar»
    3. Modificar el «Origen de Protocolo de la» Política «HTTP Solo».
    4. Guardar los cambios y esperar unos 15 minutos para que el cambio surta efecto.
    5. Prueba

    Mi expectativa es esta voluntad la fuerza de CloudFront para póngase en contacto con su origen
    el uso de sólo HTTP. He probado esto en mi entorno con un S3
    Sitio web alojado cubo y me puede cargar correctamente el contenido a través de ambos
    HTTP y HTTPS.

    Aquí el enlace al hilo del foro original.

    • Sospecho que si se había configurado la distribución del origen como «S3» en lugar de «personalizado» origen, esto podría haber funcionado como-es, desde que uso el S3 resto de la interfaz, que soporta https, pero entonces no habría tenido todo el sitio web extremo de la funcionalidad y todavía no han trabajado, desde su cubo nombre tiene un punto en ella. Felicitaciones por el hallazgo y la publicación de su propia solución.
    • No se puede ver el origen de protocolo de la política en Cloudfront más, alguna idea ?
    • Usted necesita para establecer el Origen como el sitio Web de la Estación, no el S3.
  2. 0

    Yo tenía un problema similar a este y, como @Miguel-sqlbot sugerido, pasó de origen personalizado a S3. Que no, por sí mismo, resolver el problema.

    Además de cambiar el origen, Andrew de AWS support dijo que alias trabajo mejor que el Cname. Yo había estado usando Cname. Cuando me cambié a la de alias (uno para IPv4 y uno para IPv6) funcionó. Aquí está el Route 53 documentación para CloudFront que muestra cómo configurar el alias de CloudFront.

Dejar respuesta

Please enter your comment!
Please enter your name here