OpenSSL – Different SSL Certificate Returned Compared to Chrome

google-chromeopenssl

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

Best Answer

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

Related Solutions

SSL Certificate – How to Download SSL Certificate from a Website

In order to download the certificate, you need to use the client built into openssl like so:

echo -n | openssl s_client -connect $HOST:$PORTNUMBER -servername $SERVERNAME \
    | openssl x509 > /tmp/$SERVERNAME.cert

That will save the certificate to /tmp/$SERVERNAME.cert.

The -servername is used to select the correct certificate when multiple are presented, in the case of SNI.

You can use -showcerts if you want to download all the certificates in the chain. But if you just want to download the server certificate, there is no need to specify -showcerts. The x509 at the end will strip out the intermediate certs, you will need to use sed -n '/-----BEGIN/,/-----END/p' instead of the x509 at the end.

echo -n gives a response to the server, so that the connection is released

openssl x509 removes information about the certificate chain and connection details. This is the preferred format to import the certificate into other keystores.

Outlook Web Access – Reverse Proxy and Browser Compatibility

Some browser version numbers would be good, as well as some more information on what else is on that server.

Based on what you have provided, it sounds like there are other SSL certs on that server, and the non-firefox browsers are getting one of the others? From here I'll hazard a guess that the cert they're getting is from the default virtualhost? I'll also hazard a guess that you're testing from a Windows XP system.

Where I'm going with this is that you've got multiple SSL certificates all bound to the same port, and a different one should be presented based on what host name is being visited. This depends on Server Name Indication, which isn't supported by older browsers or by XP's encryption libraries.

Unfortunately, the workarounds for this (which you'll need, there's too many old browsers out there still) are non-trivial; buy a new certificate that'll cover everything on that port (a wildcard or Subject Alternate Name cert), or add an extra IP to the server for the other VirtualHost to listen on with just its own cert.

Related Topic