I have a Web Service (asmx) API that was written in .NET 3.5 by another developer that I manage. We recently moved from Server 2008R2 to Server 2012R2 and I decided to use SNI instead of having an IP for each certificate.
Well it turns out that one of our API users was no longer able to connect to our API after the switch to SNI. I found out that they use Server 2003 which I figured was the reason for it no longer working. I went ahead and assigned the site a public ip which fixed the problem. Of course they are blaming it entirely on the .NET framework.
Their proof was this link:
https://connect.microsoft.com/VisualStudio/feedback/details/729925/net-4-4-5-sslstream-no-supports-the-tls-server-name-indication-sni
I have a test project setup that connects to our API and runs various tests and it works fine after the conversion.
Can anyone shed some light on this? Does the SoapHttpClientProtocol use sslstream?
.NET Framework itself might not be able to solve the issue if it depends on Schannel. Schannel only starts to support SNI since Windows Vista/Windows Server 2008 (or from another source Windows 8/Windows Server 2012)
Well, according to first link, SslStream indeed depends on Schannel. I just finished a test case on both Windows 7/.NET 4 and Windows 8.1/.NET 4.5.1 and I can see for a client side application utilizes SslStream SNI works as expected. So I don't think the Microsoft Connect link you pasted is a valid one at all. SNI might fail on Windows XP and Windows Server 2003, but should work for Windows Vista and above.
I did not check the source code of SoapHttpClientProtocol but I don't think Microsoft uses anything other than SslStream or Schannel.
So in your case, I suggest you roll back your changes at server side and don't use SNI yet. Another solution is to ask all your users to use Windows Vista and above as OS. Note that Windows XP is dead, and Windows Server 2003 is dying (will be dead next year, so pretty soon).
