WinXP + any version of IE does not support TLS SNI... even though it does support TLSv1.0, it doesn't support the SNI extension. Supported in Vista and 7, though.
Chrome, Firefox, and Opera (on any platform) all support TLSv1.0, with or without SNI.
s_client doesn't support SNI, so this is expected behavior. The client (s_client) doesn't know how to tell the server what hostname it's requesting during the handshake... so the server returns the default one. After the handshake completes, normal HTTP semantics kick in and the client/server have no problems... but by then it's too late, and the client has already negotiated based on the wrong cert.
I see you commented on a fix already, but here's some background...
This is due to TLS SNI, which allows different certs to be returned based on the hostname requested. SNI is supported by all major browsers on all major platforms, with 1 significant exception: WinXP+IE does not support SNI (WinXP+Firefox/Opera/Chrome are all fine for many versions, WinVista/7+IE are both fine). I think certain (older) Android platforms have a problem with this too.
SNI is really awesome because the web hosting company doesn't have to allocate separate IP addresses for multiple sites to have proper SSL support. It makes HTTPS hosting simpler and cheaper. The only significant downside is issues like this, where a user's browser doesn't support it... hence over time, issues like this should shrink.
If you're still on WinXP+IE, you're likely to start running into more and more problems in the next couple years (and not just due to SNI).