It is common practice nowadays to have multiple websites hosted on one server with the same IP address. In such cases, both the client and the server need to support the Server Name Indication (SNI) technology to request and receive the matching certificate issued for the domain. SNI relies on the client sending the ServerName header during the SSL handshake, which means it is essential for the client to support SNI. While most modern applications are configured to work with SNI, supporting older/legacy clients will require additional configuration.

This article will cover supporting non-SNI compatible clients on Windows Server.

Note: The list of browsers that support SNI can be found here.

SNI support was added to Microsoft IIS starting from IIS 8.0. Require Server Name Indication is the option in Web Site Binding that allows binding multiple certificates to different websites with the same IP address:

For such SNI bindings the ServerName header will be expected by the server. If a non-SNI capable client attempts HTTPS connection, the server will not receive the ServerName header and will not send the certificate. This will result in an SSL handshake error, and hence, HTTPS connection will not be established.

Connection with SNI

Below you can see an example of an SSL connection with the ServerName header. The server checks the header and sends the correct certificate:

Connection without SNI

Here is an example of an SSL connection to the same server without the ServerName header. Note that the server does not send a certificate:

Solution: A manual certificate binding for 0.0.0.0:443 can be created, which will be used as a fallback certificate for HTTPS connections when no ServerName header was sent by the client. It is possible to configure only one fallback certificate per port.

The following PowerShell command is used to create this binding:

netsh http add sslcert ipport=0.0.0.0:443 certhash=thumbprint appid=’{5d89a20c-beab-4389-9447-324788eb944a}’

Note: You will need to be logged in as Administrator to run the command.

Determining Certificate Thumbprint

There are several ways to check the certificate thumbprint:

1. Check the certificates installed on the server in PowerShell

   You can check certificates installed on the server with the following command: dir Cert:\LocalMachine\My

   Example:

   

2. Check existing bindings in PowerShell

Existing bindings can be reviewed with the following PowerShell command: netsh http show sslcert

Example:



3. Check certificate properties in MMC

You can check certificate properties using the Certificates snap-in in MMC. The thumbprint can be found by scrolling down in the Details tab:



4. Decode the certificate at decoder.link

You can check the thumbprint by decoding the certificate here: https://decoder.link/
The output will contain the SHA-1 fingerprint (thumbprint):

Running the command in PowerShell

In the end, the command will look similar to this one:

netsh http add sslcert ipport=0.0.0.0:443 certhash=c09643b93bd9b06430346f8a9ba4feb5f3ebc59b appid=’{5d89a20c-beab-4389-9447-324788eb944a}’

Once entered, the server will confirm the binding is added:

You can verify the binding is added by reviewing the existing bindings: netsh http show sslcert

From now on, the certificate will be used when no ServerName was specified by the client:

A few points in conclusion

1. If only one website is hosted on the IP address, it is not necessary to configure a fallback certificate. Instead, the Require Server Name Indication option can be switched off when creating the binding.
2. For IIS versions prior to 8.0 bindings can be created only for IP addresses (one binding per IP address).
3. If multiple websites need to be configured to support non-SNI capable clients, please consider using a Multi-Domain certificate for fallback.