wake-up-neo.com

CloudFront-Fehler beim Servieren über HTTPS mit SNI

Amazon hat kürzlich eine neue Funktion in CloudFront eingeführt, die benutzerdefinierte SSL-Zertifikate kostenlos unterstützt, die SNI (Server Name Indication) verwenden. 

Ich habe meine Distribution mit einem kostenlosen Class 1-Zertifikat von StartSSL eingerichtet und alles funktionierte, als ich bemerkte, dass die Site kurz nach ihrer Bereitstellung ausfallen würde. Ausführen von SSL Checker gibt zurück, dass mein Zertifikat ordnungsgemäß funktioniert:

SSL check

Aber dann würde ich diese Fehlerseite aufrufen, wenn ich versuche, über HTTPS auf die Site zuzugreifen.

CF error

Hier ist eine ausführliche Ausgabe beim Zugriff mit ssl (erfolgreich beim Index): 

$ 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

Dann scheitert auf anderen Seiten:

$ 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>%

Ich würde gerne ein paar Hinweise darüber erhalten, wo Sie mit der Problembehandlung beginnen sollen.

22
wikichen

Ein freundlicher Vertreter mit dem Namen Alastair @ AWS aus den AWS CloudFront-Foren hat dies für mich gelöst: 

Ich habe Ihre CloudFront-Distribution und den S3-Bucket identifiziert als Ursprung für diese Verteilung fungieren. 

Ich kann das intermittierende '502 Bad Gateway' Neu erstellen und erklären. Antwort, die Sie erhalten. 

Diese Antwort wird von CloudFront zurückgegeben, wenn Sie versuchen, auf eine .__ zuzugreifen. URL, die das HTTPS-Protokoll verwendet, das derzeit nicht von .__ zwischengespeichert wird. CloudFront. Der Grund für diesen Fehler ist, dass CloudFront versucht, Wenden Sie sich über das HTTPS-Protokoll an Ihr Origin, und dies schlägt fehl. 

Der Grund für diesen Fehler ist, dass Sie Ihren Origin als .__ konfiguriert haben. S3-Bucket, aber Sie verwenden den Typ "Benutzerdefinierter Ursprung" und leiten zu Die S3-Website-URL für diesen Bucket. Wenn Sie versuchen, Ihren S3 .__ zu treffen. Website-URL mit HTTPS, Sie werden feststellen, dass dies nicht funktioniert. S3-Website Hosting unterstützt nur das Bereitstellen von Inhalten mithilfe des HTTP-Protokolls ( http://docs.aws.Amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html#WebsiteRestEndpointDiff ).

Das intermittierende Seitenladeverhalten, das Sie sehen, ist auf .__ zurückzuführen. CloudFront gibt die derzeit im Cache befindlichen Seiten zurück. Sie sollte in der Lage sein, dieses Szenario wie folgt neu zu erstellen:

  1. Schlagen Sie eine Seite auf Ihrer Website mit HTTPS an. Sie sollten die Fehlermeldung "502 Bad Gateway" erhalten. 
  2. Treffen Sie dieselbe Seite mit HTTP. Sie sollten die Seite sehen. 
  3. Schlagen Sie die Seite erneut mit HTTPS an. Sie sollten jetzt das erwartete Ergebnis erhalten, da CF den Inhalt aus seinem Cache statt aus .__ geliefert hat. Versuch, mit Ihrem Origin Kontakt aufzunehmen. 

Um dieses Problem zu beheben, versuchen Sie Folgendes:

  1. Öffnen Sie die CloudFront Management Console und öffnen Sie Ihre Verteilung. 
  2. Navigieren Sie zur Registerkarte Ursprung, wählen Sie Ihren Ursprung aus und klicken Sie auf "Bearbeiten".
  3. Ändern Sie die "Origin Protocol Policy" in "Nur HTTP". 
  4. Speichern Sie die Änderungen und warten Sie etwa 15 Minuten, bis die Änderungen wirksam werden. 
  5. Prüfung

Meine Erwartung ist, dass CloudFront dazu gezwungen wird, sich mit Ihrem Origin nur mit HTTP. Ich habe dies in meiner Umgebung mit einem S3 getestet Website gehostet Bucket und ich kann Inhalte über beide .__ erfolgreich laden. HTTP und HTTPS.

Hier ist der Link zum ursprünglichen Forumsthread .

53
wikichen

Ich hatte ein ähnliches Problem und wechselte, wie @ Michael-sqlbot vorschlug, von Custom Origin zu S3. Das hat das Problem an sich nicht gelöst.

Neben der Umstellung von Origin sagte Andrew von der AWS-Unterstützung, dass Aliase besser als CNAMEs funktionieren. Ich hatte CNAMEs benutzt. Wenn ich auf Aliase umgestiegen bin (einer für IPv4 und einer für IPv6), hat es funktioniert. Hier ist die Route 53-Dokumentation für CloudFront , die zeigt, wie Aliasnamen für CloudFront eingerichtet werden.

0

Ich hatte ein bisschen Probleme mit der Einrichtung eines eigenen SSL-Zertifikats, aber dieser Artikel war sehr hilfreich. Achten Sie einfach auf Details:

https://docs.aws.Amazon.com/Route53/latest/DeveloperGuide/tutorial-redirecting-dns-queries.html

0
boldnik