使用以下命令使用OpenSSL查询Sparkfun的CDNurl时：
openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443
在证书中返回的通用名称是*.sparkfun.com ，它无法validation，但是如果您在Chrome中加载主机，则显示的通用名称是*.cloudfront.net
这里发生了什么？
这是一个问题，因为我通过Squid SSL_Bump代理SSL的环境，它生成一个由我本地信任的CA签署的域名的证书。 这适用于所有领域，但上述，因为CN不匹配，因为新的证书是使用OpenSSL生成的。
编辑 – 我已经validation了与远程数据中心的服务器上的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命令没有。
这里有更多CloudFront使用SNI的细节。
当您使用SNI自定义SSL时，某些用户可能无法访问您的内容，因为一些较旧的浏览器不支持SNI，并且无法与CloudFrontbuild立连接来加载您的内容的HTTPS版本。 有关SNI的更多信息，包括支持的浏览器列表，请访问我们的常见问题页面。
和：
SNI自定义SSL依赖于传输层安全协议的SNI扩展，该协议允许多个域通过包含正在尝试连接的主机名在相同的IP地址上提供SSLstream量。 与专用IP自定义SSL一样，CloudFront可以从每个Amazon CloudFront边缘位置提供内容，并具有与专用IP自定义SSLfunction相同的安全性。 SNI自定义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的旧版浏览器无法与CloudFrontbuild立连接以加载您的内容的HTTPS版本。 除了标准的CloudFront数据传输和请求费之外，SNI自定义SSL可以免费获得。