SSL certificates are bound to the internal IP address of the web server, not the external IP addresses.
Let's say you have foo.example.com bound to Public IP A and bar.example.com on Public IP B, but your web server only has the IP address 192.168.0.1
Whether the request comes in on IP A or IP B, it is still going to end up at 192.168.0.1. Which means that IIS has no choice but to use the certificate that is assigned to foo.example.com.
To work around this issue, you will need to have multiple IP addresses assigned to your web server. This is easy to do. Speak to your sysadmin to have some IP's removed from the DHCP range (or ask him/her which ones you can use), then go to your properties for the network card (Control Panel > Network Connections), and go to the properties for TCP/IP.
You will need to have a static IP enabled in the first place (being a server I hope this is done anyway), and then click Advanced, and under the box for "IP addresses" click "Add" - and enter the new IP addresses you've been assigned by your sysadmin (Let's say 192.168.0.2).
Then, at your router, you need to ensure that requests from IP A on port 443 go to 192.168.0.1 and that all other requests on port 443 go to 192.168.0.2.
Then, in your IIS configuration, you need to bind the SSL Cert from foo.example.com to 192.168.0.1, and bind the rest to 192.168.0.2 (or leave as All Unassigned, as you have).
If this doesn't work, or you already have this configured, update your question and leave a comment to let us know.
Update: I just saw your comments, thanks for the update. You will need to ensure foo.example.com and bar.example.com are on two different public IP addresses. The reason being that because the packets are encrypted, there's no way you can use hostname based routing to send the request to the right IP address (I believe this is the case. If anyone knows different, let me know). The only part of the request that's visible to the routers is the destination IP. This is why you can only have one SSL per IP address. So you will need to have public IP's for this to work, and in your DNS an A record for bar.example.com that is different to foo.example.com.
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.
Best Answer
I would suggest
testssl.shfor a fairly comprehensive sanity check of your TLS/SSL setup.You can direct it to a specific IP rather than resolving the name, like so:
In addition to this, for instance if you want to do functional tests with a web browser or other software that may not have similar functionality, simply override name resolution using
/etc/hostswhile doing the tests.