When configuring SSL sites in IIS7, you'll encounter a puzzling limitation: the host name field remains disabled in binding configurations for HTTPS (port 443) sites. This behavior differs from IIS6 where host headers could be specified regardless of protocol.

The technical reason stems from the SSL handshake process:

Client Hello → Server Hello → Certificate Exchange → Key Exchange → Encrypted Communication

Host headers are part of the HTTP request which occurs after SSL encryption. Since IIS needs the certificate before decrypting the request, it can't use host headers to select the appropriate certificate.

Here are three proven approaches:

1. Using SNI (Server Name Indication)

For modern browsers and Windows Server 2012+:

netsh http add sslcert hostnameport=abc.123.example.com:443 
    certhash=THUMBPRINT appid={GENERATE-GUID}

Note: Requires client support (IE7+, modern browsers)

2. Dedicated IP Approach

The traditional solution:

1. Assign a dedicated IP to the server
2. Create binding using:

   appcmd set site /site.name:"YourSite" /+bindings.[protocol='https',bindingInformation='1.2.3.4:443:abc.123.example.com']

3. URL Rewrite Workaround

For shared hosting environments:

<rule name="SSL Host Header Redirect" stopProcessing="true">
    <match url="(.*)" />
    <conditions>
        <add input="{SERVER_PORT_SECURE}" pattern="^1$" />
        <add input="{HTTP_HOST}" pattern="^abc\.123\.example\.com$" negate="true" />
    </conditions>
    <action type="Redirect" url="https://abc.123.example.com/{R:1}" />
</rule>

While wildcard certs (*.example.com) work with these methods, remember:

• They must be installed in the Local Machine certificate store
• The complete FQDN must still be specified in bindings
• Certificate Subject Alternative Names (SANs) may be needed for certain scenarios

When troubleshooting:

1. Check certificate store permissions: icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /grant "NETWORK SERVICE":R
2. Verify binding conflicts: netsh http show sslcert
3. Test HTTP.sys configuration: netsh http add sslcert hostnameport=hostname:443 certhash=thumbprint

---

When configuring SSL bindings in IIS7, many administrators encounter a frustrating limitation: the host name field remains disabled (grayed out) when creating HTTPS bindings on port 443. This occurs regardless of whether you're using wildcard certificates or specific domain certificates.

Unlike HTTP bindings where host headers are clearly visible in the request, HTTPS connections encrypt the host header information during the SSL handshake. IIS7 implements stricter security by default, preventing host header specification at the binding level for HTTPS.

// Sample PowerShell to check existing bindings
Import-Module WebAdministration
Get-WebBinding -Name "Default Web Site" | Format-Table -Property Protocol, BindingInformation

Here are three proven methods to configure host headers with SSL in IIS7:

Method 1: Using AppCmd

The most reliable approach is using the command-line tool AppCmd:

%windir%\system32\inetsrv\appcmd set site /site.name:"YourSiteName" /+bindings.[protocol='https',bindingInformation='*:443:abc.123.example.com']

Method 2: PowerShell Alternative

For automation scenarios, PowerShell provides more flexibility:

New-WebBinding -Name "YourSiteName" -Protocol "https" -Port 443 -HostHeader "abc.123.example.com" -SslFlags 1

Method 3: Manual Configuration File Edit

Directly edit applicationHost.config (backup first!):

<site name="YourSiteName" id="2">
  <application path="/" applicationPool="YourAppPool">
    <virtualDirectory path="/" physicalPath="C:\your\path" />
  </application>
  <bindings>
    <binding protocol="https" bindingInformation="*:443:abc.123.example.com" />
  </bindings>
</site>

After making changes, verify the configuration:

1. Run iisreset /noforce
2. Check binding in IIS Manager
3. Test with OpenSSL: openssl s_client -connect abc.123.example.com:443 -servername abc.123.example.com

• SNI (Server Name Indication) must be supported by client browsers
• Wildcard certificates (*.example.com) won't solve the host header limitation
• For multiple SSL sites, each requires a unique IP or SNI support

Remember that while IIS6 allowed host header specification for HTTPS bindings, this was actually a misconfiguration that could lead to security issues. IIS7's stricter implementation is technically more correct, though less convenient.