OpenSSL gibt ein anderes SSL-Zertifikat zurück als das von Chrome angezeigte

Wenn Sie die CDN-URL von Sparkfun mit OpenSSL mit dem folgenden Befehl abfragen:

openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443

Der im Zertifikat zurückgegebene allgemeine Name lautet *.sparkfun.com, was nicht überprüft werden kann. Wenn Sie den Host jedoch in Chrome laden, wird der allgemeine Name angezeigt*.cloudfront.net

Was geht hier vor sich?

Dies verursacht ein Problem, da ich mich in der Umgebung über Squid SSL_Bump in Proxy-SSL befinde, wodurch ein Zertifikat generiert wird, das von meiner lokal vertrauenswürdigen Zertifizierungsstelle für die Domäne signiert wurde. 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 festgestellt, dass dies auch bei OpenSSL auf einem Server in einem Remote-Rechenzentrum der Fall ist, der über eine direkte Verbindung zum Internet verfügt, ohne dass Proxies oder Filter erforderlich sind.

BEARBEITEN - Das Problem liegt an SNI, wie akzeptiert, aber um die Informationen zu ergänzen, warum es ein Problem mit Squid und SSL_Bump verursacht:

Dieses Projekt unterstützt die Weiterleitung von Informationen zur SSL-Servernamenanzeige (SNI) an den Ursprungsserver nicht und erschwert diese Unterstützung ein wenig. Die SNI-Weiterleitung hat jedoch ihre eigenen schwerwiegenden Herausforderungen (über den Umfang dieses Dokuments hinaus), die die zusätzlichen Weiterleitungsschwierigkeiten bei weitem überwiegen.

Entnommen aus: http://wiki.squid-cache.org/Features/BumpSslServerFirst

CloudFront verwendet SNI, eine Möglichkeit, mehrere Zertifikate auf einer einzigen IP zu verwenden. Dies wird von allen modernen Browsern unterstützt, ebenso wie der Befehl s_client von openssl, aber s_client tut dies nicht auf magische Weise. Sie müssen es sagen, um es zu verwenden:

openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net  -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts

Chrome unterstützt SNI und teilt dem Server mit, welches Zertifikat gesendet werden soll. Der s_clientBefehl tut es nicht.

Weitere Informationen zur Verwendung von SNI durch CloudFront finden Sie 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 unserer FAQ- Seite.

und:

Benutzerdefiniertes SNI-SSL basiert auf der SNI-Erweiterung des Transport Layer Security-Protokolls, mit der mehrere Domänen SSL-Datenverkehr über dieselbe IP-Adresse bereitstellen können, indem die Hostnamen-Viewer eingeschlossen werden, mit denen eine Verbindung hergestellt werden soll. Wie bei Dedicated IP Custom SSL stellt CloudFront Inhalte von jedem Amazon CloudFront-Edge-Standort und mit der gleichen Sicherheit wie die Dedicated IP Custom SSL-Funktion bereit. SNI Custom SSL funktioniert mit den meisten modernen Browsern, einschließlich Chrome Version 6 und höher (unter Windows XP und höher oder OS X 10.5.7 und höher), Safari Version 3 und höher (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 (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.