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?
Best Answer
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 https://www.rfc-editor.org/rfc/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.