Why does android get the wrong ssl certificate? (two domains, one server)

Question

I have two domains: foo.net and bar.com. They both have SSL certificates, and they work well in all desktop and mobile browsers. They are hosted on the same server configured with nginx.

However, when I make a request to a domain from within a native android app, it somehow gets the certificate from the wrong domain! This results in an IO Exception:

request = new HttpPost("https://foo.net/api/v1/baz");
request.setHeader("Authorization", "user:pass");
response = httpClient.execute(request);

...

javax.net.ssl.SSLException: hostname in certificate didn't match: <foo.net> != <bar.com> OR <bar.com> OR <www.bar.com>

What would cause android/java to try using the certificate from bar.com when every other measure seems to indicate that the server is correctly configured? Nothing appears in the nginx access or error log. There is no mention of bar.com anywhere in my android project.

Edit: I'm not sure why, but it appears that the server is using the certificate for bar.com for the server IP https://198.245.xx.xxx

Tradesman

Answer 1

The most likely cause for this problem is that the server uses Server Name Indication to choose which certificate to send. If the client doesn't support SNI, the server cannot choose which certificate to send during the SSL/TLS handshake (before any HTTP traffic is sent). SNI is required when you want to use multiple certificates on the same IP address and port, but not all clients support it (notoriously, IE on any version of Windows XP, and a number of mobile browsers).

You're also visibly using the Apache HTTP Client library (not HttpsURLConnection, for which there can be SNI support with some Android versions. Support for SNI in the Apache HTTP Client library is quite recent, and certainly hasn't made it into the Android stack.

You may find the workaround described in this article useful (although it seems only to work for Android 4.2+).

Another two options would be:

• to use a distinct IP address for each host (so as not to need SNI), if you're in control of server, or
• to use another HTTP Client library (e.g. HttpsURLConnection).

Tutelary

Answer 2

A solution for Apache, more like a trick: the SSL certificates are loaded based on the vhost name from /etc/apache2/sites-enabled. So, to trick that check make sure the problematic certificate is loaded first (remember that the vhosts are loaded by name).

Bail

Didn't have much hope left as I cannot carry out the changes suggested by the answer above in the limited time I have. Your suggestion was the last bullet that saved the day, and it did. I'll buy you a drink someday! – Elkins

Answer 3

It looks like the certificate of foo.net is misconfigured, and is using the same hostname as bar.com

Try to run an online certificate validation tool, like https://www.digicert.com/help/ on foo.net, just to be sure.

I think that you need to regenerate the certificate of foo.net with the right hostname, or reconfigure ngix to make sure that nginx serve the right certificate for the right host.

Tallith

The digicert help tool shows green across the board for both domains. "Congratulations! This certificate is correctly installed." – Tradesman