Server Certificate Bindings and its restrictions in IIS 6.0 & IIS 7.x
For any client request, IIS uniquely identifies the website based upon the unique combination of IP+PORT+HOSTNAME, here I would be discussing about the confusion which roam around while binding the certificate.
Note: IIS 7.x UI does not allow you to provide Hostname, but in IIS 6.0 you can specify the Host Header while trying to bind the SSL Certificate.
SCENARIO 1: Ports are different but IP and certificate is similar. Negotiate Client Certificate : Disabled
Web Site Name |
IP Address |
Port |
Host Name |
Working?? |
Site1.Confusion.com |
192.0.0.1 |
443 |
www.confusion.com |
Yes |
Site2.Confusion.com |
192.0.0.1 |
444 |
www.confusion.com |
Yes |
Site3.Confusion.com |
192.0.0.1 |
445 |
www.confusion.com |
Yes |
Below are the SSLBindings from the IIS server
C:\>netsh http show sslcert SSL Certificate bindings: ------------------------- IP:port : 192.0.0.1:443 Certificate Hash : beeaab550e1b7658c5a09780443f1db28246d08c Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914} Certificate Store Name : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled IP:port : 192.0.0.1:444 Certificate Hash : beeaab550e1b758c5a09780443f1db28246d08c Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914} Certificate Store Name : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled |
I can access website using https://<HostName>:<PortNumber> , as shown below
https://www.confusion.com:443 or https://www.confusion.com:445
SCENARIO 2: Ports and IP’s are same but Certificate is different.
Web Site Name |
IP Address |
Port |
Host Name |
Working?? |
Site1.Confusion.com |
192.0.0.1 |
443 |
www.confusion.com |
Yes |
Site2.Confusion.com |
192.0.0.1 |
444 |
www.confusion.com |
Yes |
Site3.Confusion.com |
192.0.0.1 |
443 |
www.IamFine.com |
No |
Starting the website will throw a error pop-up as shown below:
Explanation:
https://blogs.iis.net/thomad/archive/2008/01/25/ssl-certificates-on-sites-with-host-headers.aspx
Snippet from the above blog:
| It's a chicken and egg problem: The host name is encrypted in the SSL blob that the client sends. Because the host name is part of the binding IIS needs the host name to lookup the right certificate. Without the host name IIS can't lookup the right site because the binding is incomplete. Without the certificate IIS can't decrypt the SSL blob that contains the host name. Game over - we are turning in circles. What IIS does under the covers is to ignore the host name. IIS binds the certificate to IP:Port and warns you when you try to bind a certificate to the same IP:Port combo with different host names. |
Conclusion:
IIS uniquely identifies the HTTPS website based on IP+Port as the hostname is not available to it. So what do we do about it? There is definitely a solution. We can use Wildcard/SAN certificates to go around this problem.
Solution: Wild Card Certificate/SAN Certificate
We can bind Wildcard/SAN Certificate to multiple website with same IP and Port as the certificate hash remains the same across all the bindings.
We need to change the SSL Bindings for that specific website in order to get it working. Again as the following condition must be true IP+PORT+HOSTNAME.
Please refer the following blog on how to edit the Secure bindings for the website:
The above is applicable to SAN certificates too.
Comments
- Anonymous
May 22, 2012
Nice article !!! - Anonymous
January 27, 2015
Very clear instructions. Thnkx Anil.