Configuring multiple websites with SSL bindings in IIS 7.5 presents unique challenges due to HTTP.sys limitations in the Windows Server 2008 R2 stack. The primary technical constraints we're facing:

1. Single SSL binding per IP:port combination
2. Host header precedence rules in HTTP.sys
3. Certificate binding behavior differences between HTTP and HTTPS

The correct binding approach requires understanding these technical specifications:

Default Web Site Bindings:
- http *:80:
- https *:443: (wildcard cert)
- http go.example.com:80
- http www71.example.com:80

Beta Site Bindings:
- http beta.example.com:80
- https *:443: (same wildcard cert)

Here's the proper sequence for configuration:

1. Create site bindings via command line (more reliable than GUI):

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" /+bindings.[protocol='https',bindingInformation='*:443:']
%windir%\system32\inetsrv\appcmd.exe set site "Beta" /+bindings.[protocol='https',bindingInformation='*:443:']

2. Configure SNI via netsh (critical for proper host resolution):

netsh http add sslcert ipport=0.0.0.0:443 certhash= appid={} certstorename=MY

3. Set host header precedence in applicationHost.config:

<system.webServer>
    <protocolSupport>
        <add name="http" type="System.Web.Hosting.ISAPIWorkerRequest, System.Web"/>
    </protocolSupport>
</system.webServer>

The proper method for wildcard certificate sharing:

1. Export certificate from Default Web Site:
$cert = Get-ChildItem -Path cert:\LocalMachine\My | Where-Object {$_.Subject -like "*.example.com"}
$cert | Export-PfxCertificate -FilePath C:\temp\wildcard.pfx -Password (ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText)

2. Import to second site using PowerShell:
Import-PfxCertificate -FilePath C:\temp\wildcard.pfx -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText)

Use these commands to validate proper configuration:

# Check active bindings:
netsh http show sslcert

# Verify host header processing:
curl -Iv https://beta.example.com --resolve beta.example.com:443:<server-ip>
curl -Iv https://go.example.com --resolve go.example.com:443:<server-ip>

If experiencing 404 errors or incorrect site resolution:

1. Clear HTTP.sys configuration:
netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash= appid={}

2. Check binding order in applicationHost.config:
<bindings>
    <binding protocol="http" bindingInformation="*:80:beta.example.com" />
    <binding protocol="https" bindingInformation="*:443:" />
</bindings>

Many administrators struggle with IIS 7.5's SSL binding limitations when hosting multiple websites with different host headers. The core issue stems from how IIS handles SSL at the socket layer before processing host headers.

Unlike HTTP bindings where you can specify host headers, SSL bindings in IIS 7.5 can't natively use host headers because SSL/TLS handshake occurs before HTTP headers are processed. This creates conflicts when:

• Using wildcard certificates (*.example.com)
• Hosting multiple HTTPS sites on the same IP
• Needing both default and named bindings

Here's how to properly configure two websites (Default and Beta) with a wildcard certificate:

# PowerShell commands to verify bindings
Get-WebBinding -Name "Default Web Site" | Format-Table -Property protocol,bindingInformation
Get-WebBinding -Name "Beta" | Format-Table -Property protocol,bindingInformation

1. Configure Default Web Site:

• HTTP: *:80: (blank host header)
• HTTPS: *:443: (blank host header)
• Additional HTTP bindings: *:80:go.example.com, *:80:www71.example.com

2. Configure Beta Site:

# Using appcmd.exe to add HTTPS binding
%windir%\system32\inetsrv\appcmd.exe set site /site.name:"Beta" /+bindings.[protocol='https',bindingInformation='*:443:']

For both sites to use the same wildcard certificate:

# Assign certificate to Default Web Site
netsh http add sslcert ipport=0.0.0.0:443 certhash=THUMBPRINT appid={APP-GUID}

# Assign same certificate to Beta site (same command)
# IIS will use SNI (Server Name Indication) if available

Issue: beta.example.com shows go.example.com content

Fix: Ensure host headers are properly configured in HTTP bindings:

# Verify host headers
Get-WebConfigurationProperty -Filter "/system.applicationHost/sites/site[@name='Beta']/bindings" -Name collection

Issue: Beta site won't start with HTTPS binding

Fix: Check for binding conflicts and certificate permissions:

net stop http /y
net start w3svc

For more complex scenarios, consider:

• Using different IP addresses for each site
• Implementing URL rewrite rules as fallback
• Upgrading to newer IIS versions with better SNI support

# URL Rewrite example for host header redirection
<rule name="Redirect to HTTPS" enabled="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTP_HOST}" pattern="^beta\.example\.com$" />
    <add input="{HTTPS}" pattern="^OFF$" />
  </conditions>
  <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" />
</rule>