When working with IIS 8 on Windows Server 2012 R2, you can leverage Server Name Indication (SNI) to bind multiple SSL certificates to a single IP address and port combination. This solves the classic limitation where traditional SSL binding would require separate IPs for different hostnames.


1. First, verify SNI support is enabled in IIS:
appcmd list config /section:system.applicationHost/sites

2. Use PowerShell to create the bindings (replace placeholders with your domains and cert thumbprints):
Import-Module WebAdministration
New-WebBinding -Name "Default Web Site" -Protocol "https" -Port 443 -HostHeader "domain1.com" -SslFlags 1
New-ItemProperty "IIS:\SslBindings\0.0.0.0!443!domain1.com" -Name "CertificateHash" -Value (Get-Item "Cert:\LocalMachine\MY\THUMBPRINT1").Thumbprint

New-WebBinding -Name "Default Web Site" -Protocol "https" -Port 443 -HostHeader "domain2.com" -SslFlags 1
New-ItemProperty "IIS:\SslBindings\0.0.0.0!443!domain2.com" -Name "CertificateHash" -Value (Get-Item "Cert:\LocalMachine\MY\THUMBPRINT2").Thumbprint

After configuration, test using OpenSSL:
openssl s_client -connect yourserver:443 -servername domain1.com -showcerts
openssl s_client -connect yourserver:443 -servername domain2.com -showcerts

The output should show different certificates being presented for each hostname.
If encountering problems:
# Check binding configuration
Get-WebBinding -Name "Default Web Site" -Port 443 | Format-List *
# Verify certificate store permissions
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /grant "NETWORK SERVICE":R



When working with IIS 8 on Windows Server 2012 R2, administrators often need to host multiple HTTPS websites with different domain names on the same IP address and port (443). The fundamental limitation is that IIS traditionally requires a separate IP address for each SSL certificate when using hostname-based binding - this is due to how the SSL/TLS handshake works at the protocol level.
The technical solution is Server Name Indication (SNI), an extension to TLS that allows the client to indicate which hostname it's trying to connect to during the initial handshake. Here's how to implement it in IIS 8:
# PowerShell command to enable SNI binding
New-WebBinding -Name "Site1" -Protocol "https" -Port 443 -IPAddress "*" -HostHeader "domain1.com" -SslFlags 1

New-WebBinding -Name "Site2" -Protocol "https" -Port 443 -IPAddress "*" -HostHeader "domain2.com" -SslFlags 1

Follow these steps carefully:

Ensure all client browsers support SNI (most modern browsers do)
Install all required certificates in the server's certificate store
Create separate bindings for each domain using different certificates

After configuration, verify using OpenSSL:
openssl s_client -connect yourserver:443 -servername domain1.com -showcerts
openssl s_client -connect yourserver:443 -servername domain2.com -showcerts


Legacy clients (IE on WinXP, Android 2.x) don't support SNI
Application Request Routing (ARR) can be an alternative for complex scenarios
Always test certificate chains from external networks