OpenSSL返回与Chrome显示的SSL证书不同的SSL证书

使用OpenSSL通过以下命令查询Sparkfun的CDN URL时：

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

证书中返回的通用名称为*.sparkfun.com，无法验证，但是如果您在Chrome中加载主机，则显示的通用名称为*.cloudfront.net

这里发生了什么？

这引起了一个问题，因为我的环境是通过Squid SSL_Bump代理SSL，该环境生成了由我的本地信任CA为该域签名的证书。这适用于除上述以外的所有域，因为CN不匹配，因为使用OpenSSL生成了新证书。

编辑 -我已经验证了在远程数据中心的服务器上的OpenSSL也会发生同样的情况，该服务器可以直接连接到Internet，而无需代理或筛选。

编辑 -问题是由于SNI被接受，但要填写有关为何导致Squid和SSL_Bump问题的信息：

该项目将不支持将SSL服务器名称指示（SNI）信息转发到原始服务器，并且使这种支持更加困难。但是，SNI转发有其自身的严峻挑战（超出了本文档的范围），远远超过了增加的转发难度。

摘自：http : //wiki.squid-cache.org/Features/BumpSslServerFirst

CloudFront使用SNI，这是一种能够在单个IP上使用多个证书的方式。所有现代的浏览器都支持此功能，openssl的s_client命令也支持此功能，但是s_client并非神奇地做到这一点。您必须告诉它使用它：

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

Chrome支持SNI，告诉服务器发送哪个证书。该s_client命令没有。

有SNI的CloudFront的的使用的更多细节在这里。

当您使用SNI自定义SSL时，某些用户可能无法访问您的内容，因为某些较旧的浏览器不支持SNI，并且将无法与CloudFront建立连接以加载内容的HTTPS版本。有关SNI的更多信息，包括受支持的浏览器列表，请访问我们的常见问题解答页面。

和：

SNI自定义SSL依赖于传输层安全协议的SNI扩展，该协议允许多个域通过包含查看器尝试连接的主机名来通过同一IP地址提供SSL流量。与专用IP自定义SSL一样，CloudFront从每个Amazon CloudFront边缘位置交付内容，并且具有与专用IP自定义SSL功能相同的安全性。SNI Custom SSL可与大多数现代浏览器一起使用，包括Chrome版本6和更高版本（在Windows XP和更高版本或OS X 10.5.7和更高版本上运行），Safari版本3和更高版本（在Windows Vista和更高版本或Mac OS X 10.5上运行）。 6.和更高版本），Firefox 2.0和更高版本以及Internet Explorer 7和更高版本（在Windows Vista和更高版本上运行）。不支持SNI的旧版浏览器无法与CloudFront建立连接以加载内容的HTTPS版本。