SSL Scalability with IIS 8 (Windows 8 Server)
One of the biggest problems with IIS on the previous versions of IIS was in regards to scalability. This restriction was at the OS level at the kernel mode. There is nothing much that we could do to address this in IIS. One cannot bind more than one Certificate to a combination of <IP:Port>. The workarounds were:
-
Use a Wild Card Certificate
-
Use a SAN Certificate
-
Use a different combination of IP:Port
None of this was an ideal workaround. You could read more about this restriction here:
http://blogs.msdn.com/b/anilpras/archive/2012/05/23/server-certificate-bindings-and-its-restrictions-in-iis-6-0-amp-iis-7-x.aspx
This has been finally addressed in Windows 8 and here are the solutions.
-
Server Name Indication or SNI
-
Central Certificate Store or CCS
For SNI: http://learn.iis.net/page.aspx/1096/iis-80-server-name-indication-sni-ssl-scalability/
Also refer the Wiki article: http://en.wikipedia.org/wiki/Server_Name_Indication
The result of this change is that now you would see 2 additional entries under the following registry key as shown below:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
Let’s discuss these keys a little bit:
1.
SslBindingsInfo:
This legacy registry key was also present in earlier version of Windows prior to Windows 8. The bindings were of the type IP:Port. Only one certificate could be associated with an entry (or that key) and hence the limitation. We could add multiple SSL bindings by creating multiple combination of IP:Port and then associating each with a SSL Server Certificate.
|
SSL Certificate bindings:
————————–
IP:port : 192.168.1.1:443
Certificate Hash : 2114e944c1e63dcdcd033e5d3fdb832ba423a52e
… |
The problem was that it was not feasible to have multiple ports open on the server. The ideal choice was always going to be the default SSL 443. So this suggests that we need to have more IP Addresses on the server. In the real world, this is not an acceptable solution and hence we had to use SAN or Wild Card certificates.
2.
SslSniBindingsInfo:
This is new in Windows 8 and is not available in previous Windows Versions. The bindings are of the type Hostname:Port. As the previous one, only one certificate could be bound to Hostname:Port key.
|
SSL Certificate bindings:
————————–
Hostname:port : www.mycontoso.com:443
Certificate Hash : 0e62ac0f4deb8d6d78ac93a3088157e624ee540b
… |
In this case we don’t have to use additional IP Addresses. We can use the hostname present in the certificate and then continue using the default SSL Port 443. Since Hostnames are always unique, 2 bindings could never have the same certificate.
3.
SslCcsBindingsInfo:
This is new in Windows 8 and was not available in earlier versions of Windows. True SSL Scalability was achieved with this. This reads the certificates from a File Share. There is only one binding for a specific port and you could have multiple Site listening on this binding. The Server certificate is loaded based on hostname section available from the Client Hello at run time. If you try to list out the SSL bindings then this is how it would look:
|
SSL Certificate bindings:
————————–
Central Certificate Store : www.mycontoso.com:443
Certificate Hash : 0e62ac0f4deb8d6d78ac93a3088157e624ee540b
… |
This allows you to configure multiple sites on a single binding, as the certificates are loaded at run time. The management of certificates is also easier as we can have multiple certificates read from a central file location. If a certificate expires we can just update the certificate on that particular file share.
I will blog in more detail on how this works with scenarios to help this understand better. There is more to the Central Certificate Store and I will blog multiple posts with more detailed explanation.
You can read more on IIS 8 here:
http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx
http://learn.iis.net/page.aspx/1087/what39s-new-in-iis-80-for-windows-8/
http://technet.microsoft.com/en-us/library/hh831725.aspx
Until then. Adios! 