OpenSSL returns different SSL certificate to that shown by Chrome

Question

When querying Sparkfun's CDN url using OpenSSL with the following command:

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

The common name returned in the certificate is *.sparkfun.com, which fails to verify, but if you load the host in Chrome, the common name shown is *.cloudfront.net

What is going on here?

This is causing a problem because the environment I am in proxies SSL via Squid SSL_Bump, which generates a certificate signed by my locally trusted CA for the domain. This works for all domains but the above, as the CN does not match as the new cert is generated using OpenSSL.

EDIT - I have verified the same occurs with OpenSSL on a server in a remote data centre that has a direct connection to the internet with no proxies or filtering involved.

EDIT - The issue is due to SNI, as accepted, but to fill out the information as to why it causes a problem with Squid and SSL_Bump:

This project will not support forwarding of SSL Server Name Indication (SNI) information to the origin server and will make such support a little more difficult. However, SNI forwarding has its own serious challenges (beyond the scope of this document) that far outweigh the added forwarding difficulties.

Taken from: http://wiki.squid-cache.org/Features/BumpSslServerFirst

Answer 1

CloudFront uses SNI, a way of being able to use multiple certificates on a single IP. All modern browsers support this, as does openssl's s_client command, but s_client doesn't magically do this. You have to tell it to use it:

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

Answer 2

Chrome supports SNI, telling the server which certificate to send. The s_client command doesn't.

There's more details of CloudFront's usage of SNI here.

When you use SNI Custom SSL, some users may not be able to access your content because some older browsers do not support SNI and will not be able to establish a connection with CloudFront to load the HTTPS version of your content. For more information on SNI, including a list of supported browsers, please visit our FAQ page.

and:

SNI Custom SSL relies on the SNI extension of the Transport Layer Security protocol, which allows multiple domains to serve SSL traffic over the same IP address by including the hostname viewers are trying to connect to. As with Dedicated IP Custom SSL, CloudFront delivers content from each Amazon CloudFront edge location and with the same security as the Dedicated IP Custom SSL feature. SNI Custom SSL works with most modern browsers, including Chrome version 6 and later (running on Windows XP and later or OS X 10.5.7 and later), Safari version 3 and later (running on Windows Vista and later or Mac OS X 10.5.6. and later), Firefox 2.0 and later, and Internet Explorer 7 and later (running on Windows Vista and later). Older browsers that do not support SNI cannot establish a connection with CloudFront to load the HTTPS version of your content. SNI Custom SSL is available at no additional cost beyond standard CloudFront data transfer and request fees.