HTTP And HTTPS Bindings In IIS

What Are Bindings?

Bindings are a collection of elements that define how your website will be accessed.

For example:

Is your website going to be accessed through HTTP, HTTPS, both?

Which domain name are you going to use?

Which port are you going to use?

These are the basic settings:

• Type: HTTP | HTTPS (There are other protocols as well)
• IP Address: IP Address assigned.
• Port: Assigned port.
• Host name: domain name.

These four options form a unique identifier for the website. Meaning two exact bindings cannot coexist at the same time. This applies to your whole IIS sites.

Think about it, if you assign your website a binding such as “http 192.168.56.1 80 test.com” No other website can have that same binding. You will need to change at least one of those settings, so it differs from the one we set in at least one option.

If, for the same website, I tried to add the same binding, it will give me a warning that this cannot be done as there already is a binding that has the same values.

And if you try to add the same binding but, on another website, it will give you a message saying that you can do this. However if you accept this duplicate, this site will be immediately stopped.

Two same bindings cannot coexist at the same time, so it stops this website.

In summary, the combination of: “type”, “IP address”, “Port”, and “Host name” are the unique identifier for the website. Therefore, it is not possible to have a duplicate binding.

Where Are These Bindings Stored?

These bindings are stored at “C:\Windows\System32\inetsrv\Config\applicationHost.config”.

Snippet example:

<site name="Default Web Site" id="1">
                <application path="/">
                    <virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />
                </application>
                <bindings>
                    <binding protocol="http" bindingInformation="*:80:" />
                   
                    <binding protocol="http" bindingInformation="192.168.56.1:80:test.com" />
                </bindings>
                
            </site>

First binding is listening protocol HTTP, all IP Addresses, port 80 and no host name (localhost).

Second binding is listening on protocol HTTP, IP 192.168.56.1, port 80 and “test.com” as domain name.

How Is This Configured?

The Window Process Activation Service (WAS) reads the configuration in “applicationHost.config” file. Then, it passes this information to the World Wide Web Publishing Service (WWW Service), which is the listener adapter. Now, the WWW Service goes ahead and configures the HTTP listener (HTTP.sys) with information such as “I am listening on <binding protocol=”http” bindingInformation=”*:80:” /> and <binding protocol=”http” bindingInformation=”192.168.56.1:80:test.com” />

HTTPS Binding

HTTPS is just HTTP protocol over SSL/TLS.

At the most basic level, TLS provided a secure tunnel across the internet.

HTTPS binding follows the same principle as a HTTP binding. Meaning there cannot be two bindings with the same configuration. However, we now add one more variable to our equation: the SSL/TLS certificate.

Now, select the “type”, “IP address”, “port”, “host name”, and the certificate.

Note that the SSL certificate dropdown will only show the certificates that are at “Local Computer >Personal > Certificates” and in “.pfx” format.

Let us create an HTTPS binding

For the same website, let us add another HTTPS binding for a specific host name and that uses another certificate:

So, we have one HTTPS binding that it is using “IIS Express Development Certificate” and another HTTPS binding that it is using “awesomedefaultwebsite.space” certificate, both sharing same IP.

However, this is not the case!

Go back to your first HTTPS binding and noticed how the certificate got changed to the certificate of the second binding:

One same IP Address can only have one certificate!

If you add an HTTPS binding to another website (same IP address as before) but different certificate, it will give you a warning saying that in doing so, it will reassign the certificate to other HTTPS binding.

Meaning there can only exist one certificate attached to a IP Address.

What Is Happening Here?

An IP Address can only have one certificate. It is not possible to have two different certificates attached to one IP Address.

Let us remove all HTTPS bindings but the following:

Open CMD and type the following:

netsh http show sslcert

    IP:port: 192.168.56.1:443
    Certificate Hash: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXb88655
    Application ID: {4dc3e181-e14b-4a21-b022-59fc669b0914}
    Certificate Store Name: My

Notice that the certificate attached to IP “192.168.56.1:443” is the one ending in “b88655”, which is the IIS Express Certificate:

But Why Is Only Possible To Have One Certificate Per IP Address?

Think about it. The website needs to determine which certificate to use in order to decrypt traffic. Information at the network layer is not yet encrypted. At this level, we have access to the IP Address. So, by knowing the IP Address, IIS knows which certificate to use in order to decrypt traffic.

Therefore, it is not possible to have multiple certificates to one IP Address.

There is no problem at all if you attach multiple certificates to different IP Addresses, but it is not possible to attach multiple certificates to the same IP Address.

How Can We Have Multiples Certificates In One IP Address?

If this must be done, you have two options:

A) Use one certificate for all your sites

For all your sites under the same IP Address, use either a wildcard certificate or add all your domain names into the SAN property of the certificate.

So, with one certificate, you will cover all your sites.

B) Use Server Name Indication (SNI)

SNI extends the TLS protocol, allowing to specify the host name in the TLS handshake.

Without SNI, the host name lives at the application data layer. Information here cannot be accessed because it is encrypted, and we do not know which certificate to use yet. That is why the certificate needed to be attached to an IP Address.

By using SNI, the certificate will be attached not to the IP but to the host name itself.

If you run again the “netsh http show sslcert” command, notice how now the certificate is attached to the host name rather than the IP.

Hostname:port: awesomedefaultwebsite.space:443
    Certificate Hash: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXb87331
    Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
    Certificate Store Name : My
   

In this manner, you can host multiple certificates under one IP Address because the certificate gets attach to the host name and SNI allows to specify host name during TLS handshake.

Note that some browsers/applications may not support SNI, although most modern browsers do.

Key Takeaways

• Bindings are a collection of elements that define how your website will be accessed.
• Two same bindings cannot coexist.
• Bindings are stored at “C:\Windows\System32\inetsrv\Config\applicationHost.config”.
• IIS will only read SSL/TLS certificates at “Local Computer >Personal > Certificates” and in “.pfx” format.
• “netsh http show sslcert” command let us see the ssl bindings.
• If you have to host multiples certificate under one website you have two options: a) have them share one certificate; b) attach the certificate to the host name, rather than the IP Address (SNI).
• Server Name Indication (SNI) extends the TLS protocol, allowing to specify the host name in the TLS handshake.