1. Background
1.1. A Chicken and Egg Issue
IIS identifies a site using the following three pieces of data
1. IP Address – Layer 3/4
2. Port – Layer 3/4
3. Host Header – Layer 7
Multiple HTTP (non-secure) sites can be configured via different combination of above on the same physical server. For example
Site
|
IP Address
|
Port
|
Host Header
|
Mysite1.example.com
|
192.168.0.1
|
80
| |
Mysite2.example.com
|
192.168.0.2
|
80
| |
Mysite3.example.com
|
192.168.0.2
|
81
|
The Host Header was not utilized in the previous example, at this point in order to host multiple sites, different IP/Port combination is required. In order to support this configuration, more IP addresses or non-default port will be required; this is where Host Header becomes handy.
Host Header allows sites to share the same IP and Port and based on the Host Header value, the web servers will be able to direct user to the proper site.
Site
|
IP Address
|
Port
|
Host Header
|
Mysite1.example.com
|
192.168.0.1
|
80
|
Mysite1.example.com
|
Mysite2.example.com
|
192.168.0.1
|
80
|
Mysite2.example.com
|
Mysite3.example.com
|
192.168.0.1
|
80
|
Mysite3.example.com
|
When HTTPS (SSL) is used, the required SSL certificate can be bind to each IP Address/Port combination of each site and will function properly, however when Host Header is used, it gets complicated. Consider the following example; with 3 sites identified via host header and each have their own SSL certification.
Site
|
IP Address
|
Port
|
Host Header
|
SSL Common Name
|
Mysite1.example.com
|
192.168.0.1
|
443
|
Mysite1.example.com
|
Mysite1.example.com
|
Mysite2.example.com
|
192.168.0.1
|
443
|
Mysite2.example.com
|
Mysite2.example.com
|
Mysite3.example.com
|
192.168.0.1
|
443
|
Mysite3.example.com
|
Mysite3.example.com
|
A HTTPS handshake looks like following.
1. Client à SSL Handshake (Layer 6): “Hello, I support X,Y,Z algorithm for encryption”
2. Server à SSL Handshake (Layer 6): “Okay, here’s my public certificate, please use algorithm Y”
3. Client à SSL Handshake (Layer 6): “Confirmed use algorithm Y”
4. Client à Encrypted Traffic (Layer 7): “HTTP Request” ßHost Header will be encapsulated in here.
5. Server à Encrypted Traffic (Layer 7): “HTTP Response”
Since SSL works on Layer 6 of OSI model (Step 1 to 3), at the initial SSL Handshake, there are no information to indicate which site client wants, since that information won’t be available till Step 4.
Assuming that client wants to access Mysite1.example.com, the web server would send the public certificate of Mysite1.example.com to the client. The client then encrypts the HTTP request with Host Header using the public certificate Mysite1.example.com.
The server decrypts the HTTP Request with Mysite1.example.com’s private key, extract the host header and response with site content from Mysite1.example.com.
However, when client wants to access Mysite2.example.com, the web server would still send the public certificate of Mysite1.example.com. After SSL handshake is completed, at Step 4, host header is extracted, but client is asking for Mysite2.example.com. Subsequence HTTP communication would fail due to certificate mismatch; the client encrypts data with Mysite1.example.com public cert and server is trying to decrypt it with Mysite2.example.com’s private key.
The end result is that only one out of the three sites would work under SSL. This is why HTTP server can only allow one site per IP address:Port combination when enabled with HTTPS; and yes, this issue applies to all web servers regardless of IIS/Apache.
1.2. The Solution
1.2.1. Wildcard Certificate and SAN Certificate
Consider the following scenarios with wildcards certificate and SAN certificates.
All sites identified via Host Header shares the same certificate. After initial SSL handshake, the web server is able to extract the host header and direct clients to the proper site.
Wildcard Certificate
Site
|
IP Address
|
Port
|
Host Header
|
SSL Common Name
|
Mysite1.example.com
|
192.168.0.1
|
443
|
Mysite1.example.com
|
*.example.com
|
Mysite2.example.com
|
192.168.0.1
|
443
|
Mysite2.example.com
| |
Mysite3.example.com
|
192.168.0.1
|
443
|
Mysite3.example.com
|
SAN Certificate
Site
|
IP Address
|
Port
|
Host Header
|
SSL Common Name
|
Mysite1.example.com
|
192.168.0.1
|
443
|
Mysite1.example.com
|
Mysite.example.com
SAN:
Mysite1.example.com
Mysite2.example.com
Mysite3.example.com
|
Mysite2.example.com
|
192.168.0.1
|
443
|
Mysite2.example.com
| |
Mysite3.example.com
|
192.168.0.1
|
443
|
Mysite3.example.com
|
2. Installation and Configuration
2.1. Pre-requisite
Wildcard Certificate: Please confirm with project to verify which sites will be sharing the same Wildcard Certificate.
SAN Certificate: Please confirm with project to verify which sites will be sharing the same certificate and make sure their subject alternate names are filled out in the request form or listed in the certificate issued.
*** If you are renewing certificate, you can check the SSL bindings in IIS to make note of the sites that shared the wildcard/SAN certificate. ***
2.2. Install Wildcard/SAN Certificate
1. Launch Internet Information Service (inetmgr.exe) on the target web server and select the site that requires the certificate (eg, BHC) then select Bindings… to the right.
2. Highlight the HTTP (443) binding and click Edit… .
3. Selected the newly imported certificate from the drop down. *** be advised that at this point the host header name will be reset, please continue and select Yes for all prompts ***
4. Repeat the same steps for all required sites.
2.3. Update Metabase (IIS6 Only)
1. Open Windows Explorer and navigate to C:\Windows\System32\Inetsrv\config. Create a backup copy of the file MetaBase.xml, or you can back it up via IIS Manager.
2. Open the MetaBase.xml in Notepad. Search for the keyword SecureBindings.
3. Update the host header information by adding :<FQDN> after 443.
4. Repeat above steps for each site that needs to be update.
5. Execute iisreset to restart IIS.
2.4. Update ApplicationHost.Config File (IIS7 and Above Only)
1. Open Windows Explorer and navigate to C:\Windows\System32\Inetsrv\config. Create a backup copy of the file applicationHost.config.
2. Open the applicationHost.config in Notepad. Search for the keyword protocol=”https”.
3. Locate the binding property of each site that needs to be updated.
4. Update the host header information by adding :<FQDN> after 443.
5. Repeat above steps for each site that needs to be update.
6. Execute iisreset to restart IIS.