Default certificate for SNI (Server Name Indication) - ssl-certificate

Question

Short description
For Windows Server 2012: Is there a way to define a default-certificate in case the client does not support SNI?
Long description
We are currently configuring a Windows Server 2012 that - for technical reasons - does only have a single IP. This server is used for two tasks:
SSTP-Host (vpn.example.com)
Host for a single TLS-Website (www.example.com)
Thus there are two certificates defined for the same IP-address and port. When a call is made to port 443, almost every client submits the SNI parameter "server_name". The server does then use this parameter in order to choose the correct certificate for the connection.
BUT:
Windows XP with Internet Explorer does not support SNI and the parameter "server_name" is missing. Thus the server has to make a guess, which certificate to return. In our case, it defaults to the vpn-certificate and the browser displays a certificate-error (since the certificate's hostname "vpn.example.com" does not match the hostname in the url "www.example.com").
Is there a way to advise the server to use the www-certificate instead as a default?
This would be a perfect solution in our case:
All www-requests would get the www-certificate, even if they do not support SNI.
All SSTP-requests would get the vpn-certificate, since they do all support SNI.
Can this be done?

Answer 1

I know you have already answered the question yourself but it puzzled me that there was no simple way of doing it.
I am not sure if you have time to try it but I think this method would save the settings even during restarts.
In your case, if you edit the https 443 binding for vpn.example.com and tick the box Require Server Name Indication and enter the hostname of course and click Ok.
Then on the other website www.example.com do the same, but remove the tick in "Require Server Name Indication".
When I ran the netsh http show sslcert it showed the two certificate I had in place swapped, one on ip:port and the other hostname:port
IP:port : 0.0.0.0:443
Certificate Hash : 41f099397ad4437f7af7bf1c3157a18bd2576ebc
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : WebHosting
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Hostname:port : secure.localhost:443
Certificate Hash : 106073025a888e17e94a7843de844d270714e806
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : WebHosting
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
and after
IP:port : 0.0.0.0:443
Certificate Hash : 106073025a888e17e94a7843de844d270714e806
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : WebHosting
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Hostname:port : localhost:443
Certificate Hash : 41f099397ad4437f7af7bf1c3157a18bd2576ebc
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : WebHosting
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Hopefully this will save you some time and anyone else for that matter!

Answer 2

I did some more research. The bottom line: It can be done, but only on the command line and probably not permanently.
Netsh can show the http-bindings.
netsh http show sslcert
There you can see that IIS registers a SNI-Binding: www.example.com:443
But the RAS-Service registers for the full port 443: 0.0.0.0:443 with the certificate vpn.example.com.
The latter one is also the default-certificate in case the client does not support SNI.
Now I used netsh to move the RAS-Binding to vpn.example.com:443 and to create a new binding on 0.0.0.0:443 for www.example.com.
Now the server behaves exactly the way I want. I even used Wireshark to ensure that my RAS-clients do indeed support SNI.
But this setting will probably not be permanent. As soon as either the IIS or RAS-Service reset the settings, they will be lost.
Of course you could use some kind of service to check these settings every couple of seconds. But I did not find anything that works out of the box and did not want to implement this. Thus I will wait for Microsoft to enable SNI for RAS via the gui and use a single certificate until then.