Beim Abfragen der CDN-URL von Sparkfun mithilfe von OpenSSL mit dem folgenden Befehl:
openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443
Der im Zertifikat zurückgegebene allgemeine Name ist *.sparkfun.com, was die Überprüfung nicht erfolgreich durchführt. Wenn Sie den Host jedoch in Chrome laden, wird als allgemeiner Name der folgende angezeigt:*.cloudfront.net
Was geht hier vor sich?
Dies verursacht ein Problem, da die Umgebung, in der ich mich befinde, SSL über Squid SSL_Bump proxies, wodurch ein von meiner lokal vertrauenswürdigen Zertifizierungsstelle signiertes Zertifikat für die Domäne generiert wird. Dies funktioniert für alle Domänen außer den oben genannten, da der CN nicht übereinstimmt, da das neue Zertifikat mit OpenSSL generiert wird.
BEARBEITEN– Ich habe überprüft, dass dasselbe mit OpenSSL auf einem Server in einem entfernten Rechenzentrum passiert, der über eine direkte Verbindung zum Internet ohne Proxys oder Filter verfügt.
BEARBEITEN- Wie angenommen, liegt das Problem an SNI. Um jedoch zu erläutern, warum es ein Problem mit Squid und SSL_Bump verursacht, müssen Sie Folgendes angeben:
Dieses Projekt unterstützt nicht die Weiterleitung von SSL Server Name Indication (SNI)-Informationen an den Ursprungsserver und erschwert diese Unterstützung ein wenig. Die SNI-Weiterleitung bringt jedoch ihre eigenen ernsthaften Herausforderungen mit sich (die über den Rahmen dieses Dokuments hinausgehen), die die zusätzlichen Weiterleitungsschwierigkeiten bei weitem überwiegen.
Genommen von:http://wiki.squid-cache.org/Features/BumpSslServerFirst
Antwort1
CloudFront verwendet SNI, eine Möglichkeit, mehrere Zertifikate auf einer einzigen IP zu verwenden. Alle modernen Browser unterstützen dies, ebenso wie der s_client-Befehl von openssl, aber s_client tut dies nicht auf magische Weise. Sie müssen es anweisen, es zu verwenden:
openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts
Antwort2
Chrome unterstütztSNIund teilt dem Server mit, welches Zertifikat gesendet werden soll. Der s_clientBefehl tut dies nicht.
Weitere Einzelheiten zur Verwendung von SNI durch CloudFront finden Sie hier.Hier.
Wenn Sie SNI Custom SSL verwenden, können einige Benutzer möglicherweise nicht auf Ihre Inhalte zugreifen, da einige ältere Browser SNI nicht unterstützen und keine Verbindung mit CloudFront herstellen können, um die HTTPS-Version Ihrer Inhalte zu laden. Weitere Informationen zu SNI, einschließlich einer Liste der unterstützten Browser, finden Sie auf unsererFAQSeite.
Und:
SNI Custom SSL basiert auf der SNI-Erweiterung des Transport Layer Security-Protokolls, die es mehreren Domänen ermöglicht, SSL-Datenverkehr über dieselbe IP-Adresse bereitzustellen, indem der Hostname angegeben wird, mit dem die Betrachter eine Verbindung herstellen möchten. Wie bei Dedicated IP Custom SSL liefert CloudFront Inhalte von jedem Amazon CloudFront-Edge-Standort und mit derselben Sicherheit wie die Dedicated IP Custom SSL-Funktion. SNI Custom SSL funktioniert mit den meisten modernen Browsern, einschließlich Chrome ab Version 6 (läuft unter Windows XP und höher oder OS X 10.5.7 und höher), Safari ab Version 3 (läuft unter Windows Vista und höher oder Mac OS X 10.5.6 und höher), Firefox 2.0 und höher sowie Internet Explorer 7 und höher (läuft unter Windows Vista und höher). Ältere Browser, die SNI nicht unterstützen, können keine Verbindung mit CloudFront herstellen, um die HTTPS-Version Ihres Inhalts zu laden. SNI Custom SSL ist ohne zusätzliche Kosten über die Standardgebühren für Datenübertragung und -anforderungen von CloudFront hinaus verfügbar.