Server 2012 R2 has introduced SNI to IIS. Essentially, this is host headers for secure sites, and I welcome the additional feature. However, I recently encountered a problem with the default certificate that is issued by IIS, which caused some problems with the Lync 2013 client for iOS, as this doesn’t seem to support SNI.
What should happen
If present in a TLS connection request to IIS, the host header (SNI) should be examined and the appropriate certificate served to the client.
If a host header isnÔÇÖt provided, e.g. when using XP or the Lync client on iOS, a default certificate should be served by IIS, if one is present.
A default certificate is configured in IIS by creating a binding for HTTPS with no SNI entry. If the binding has an IP address specified, which I had added in order to bind it to the external NIC, this binding is used for all connections, irrespective of any other SNI bindings. This causes all sites to be served the certificate for the default binding. This is a problem.
In the default binding, remove the IP address and select All unassigned. This causes IIS to correctly issue the certificates for each specified SNI binding, and the default certificate to all other clients.