Multiple SSL certificates to access one ASP.NET application in IIS

Question

Hi,

I have an ASP.NET application that's currently accessible via a single domain name, with an SSL certificate. We'd like to be able to access the same application via a second domain name. The non-SSL part is easy, just set up a second host header value for the website in IIS. We know we'll need a second SSL certificate for the second domain, and of course a second IP address to run the two certificates in parallel - neither of those is a problem.

The problem is that IIS doesn't seem to let you set up ONE website that has TWO SSL certificates - it seems you can bind the one website to two SSL entries provided each has its own IP, but only using the same certificate.

We'd rather not have a second website entry in IIS because that would mean a complete second copy of the ASP.NET application running - i.e. double the memory usage. The two domains are basically country-specific variations, so we can't use a wildcard certificate with subdomains off a common domain name.

Is there any way to do this? Can IIS be configured to serve up two SSL certificates off one website entry (based on the IP address, of course)? Or is the best way to achieve this to set up a second website in IIS which reverse proxies onto the 'real' website?

Answer 1

Instead of using a wildcard certificate you could put the alternate names in the Subject Alternate Name (SAN) attribute of the SSL certificate. You will configure IIS to use the same certificate for both bindings.

Hope this helps, -brian

Answer 2

Stab in the dark, but if you were running 2 IIS websites, could running them under a single AppPool reduce the memory cost?

Answer 3

Your problem is unsolvable due to the way the SSL protocol and virtual hosts work. You have to use only a single certificate per IP, regardless of the number of name based virtual hosts served by it.

As Brian has already suggested, you can place several alternative virtual host names on that single certificate (using the subjectAltName x.509 extension - see http://tools.ietf.org/html/rfc3280#section-4.2.1.7), but it will still be just a single certificate. Visitors to one of your virtual hosts will be able to determine all the other virtual hosts simply by analyzing the certificate extension.

The limitation is due to how HTTPS protocol is organized - it's simply HTTP stacked on top of SSL.

So when a client connects to the server, it first has to establish a SSL session - this is the stage during which the server presents the certificate.

At this stage, the server does not know what virtual host the client will ask for because the client will do it later, only after having established the SSL session.

Only after the SSL session has been established, the client initiates the HTTP dialogue by sending the HTTP client headers, which include the "Host:" header indicating the web site's host address the client is asking for. This is long after the server certificate has been sent to the client.

Answer 4

You could run a reverse proxy (use nginx for example) in front of your application. The reverse proxy would take care of the two certificates for you.

The reverse proxy would listen on https :// fqdn1/ and https :// fqdn2/ with respective certificates and would proxy for http :// localhost/application/ or whatever.

HTH

Bram