When hosting multiple HTTPS websites on a single IP address in IIS 8, Server Name Indication (SNI) is the modern solution. However, older browsers (like IE on Windows XP) and some mobile devices don't support SNI. Without a default SSL site, these clients will receive certificate warnings or connection errors.

Here's how to set up a default SSL site that will handle non-SNI capable clients:

1. Create a new website in IIS Manager or use an existing one
2. Bind it to port 443 (HTTPS) without specifying a host name
3. Assign your wildcard certificate to this binding

Here's how the binding should look in applicationHost.config:

<site name="Default SSL" id="99">
    <bindings>
        <binding protocol="https" bindingInformation="*:443:" />
    </bindings>
    <application path="/" />
</site>

If you need to use different certificates for different sites:

# PowerShell command to assign certificate to default site
Import-Module WebAdministration
New-WebBinding -Name "Default SSL" -Protocol "https" -Port 443
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*yourdomain.com*"}
New-Item -Path IIS:\SslBindings\0.0.0.0!443 -Value $cert

• The default SSL site should return a generic response or redirect to your main website
• Monitor traffic to this site as it may indicate legacy clients needing upgrade
• Consider implementing a custom error page explaining browser requirements

Use OpenSSL to verify the default certificate is served to non-SNI clients:

openssl s_client -connect yourserver.com:443 -servername dummy.example.com

Without the -servername parameter, it should show your default certificate.

When configuring multiple SSL-enabled websites on IIS 8 with a single IP address, Server Name Indication (SNI) becomes crucial for modern browsers. However, legacy clients (Windows XP, Android 2.x, etc.) don't support SNI, causing connection failures when "Require Server Name Indication" is enabled.

IIS uses the default SSL site as a fallback when:

• Client doesn't send SNI information
• No hostname match found in SSL bindings

Here's how to properly set up the default SSL site:

# PowerShell: Designate default SSL site
Import-Module WebAdministration
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter "system.applicationHost/sites" -name "siteDefaults" -value @{logFile.enabled="true"}

# Set binding (replace with your certificate hash)
New-WebBinding -Name "Default Web Site" -Protocol "https" -Port 443 -SslFlags 1 -CertificateThumbprint "YOUR_CERT_THUMBPRINT"

For a wildcard certificate (*.example.com) serving multiple sites:

1. Create a dedicated "Default SSL" website
2. Assign the wildcard certificate
3. Disable all HTTP features (only HTTPS binding)
4. Set a generic holding page (e.g., "Please upgrade your browser")

Use OpenSSL to simulate non-SNI clients:

openssl s_client -connect server:443 -servername dummy.example.com
openssl s_client -connect server:443 # No SNI extension

For enterprise environments:

• IP-based segregation (dedicated IPs for legacy systems)
• Reverse proxy configuration
• Client detection and redirection

Remember that:

• Default sites may expose certificate warnings for mismatched domains
• Consider implementing HSTS with care
• Regularly monitor legacy traffic metrics