Unified SSL for multiple domains

Question

I have one site in IIS with an empty host header and 50 + unqiue domains that all point to this site. Is there any public or wildcard SSL access that I can set on the site to work with every domain? I know that wildcard certificates exist, but I think they are limited to one TLD.

I was hoping to install several certificates on one site, since each domain already has a certificate purchased, but this will not happen.

I looked at IIS 7 SSL for several sites with one IP , which points to http://www.sslshopper.com/article-ssl-host-headers-in-iis-7.html , which says that I need a single certificate communication systems http://www.sslshopper.com/unified-communications-uc-ssl-certificates.html

Any ideas? Will a unified certificate work?

IIS 7.5

Answer 1

Substitution SSL certificates for a single domain. For your situation, you need to have a certificate that worked for each domain that, err, would not be so secure, you could, for example, spoof hotmail.com

However, the X509 has an attribute called Subject Alternative Name (SAN). This allows you to use a fixed list of domains for which a certificate can be used, but the list is fixed at the time of release. Your link says that it uses this method, but I'm confused why they say that they are mainly intended for a UC server, they work just fine like regular old HTTPS certificates. I am using it right now in the development window.

If you think they are Verisign specialized, they also do, like Entrust

Answer 2

You can configure multidomain SSL with UBUNTU and REDHAT by following the document Multidomain SSL

Answer 3

In principle, each server (which means that any server-side program is responding to a client request) can send only one certificate . It will also send a certificate chain to the root certificate.

Using simple SSL / TLS, a handshake is performed before the client can indicate which domain he wants the page for (this is done in the HTTP header), so you have no chance to offer the right certificate.

A common solution is that the server has several IP addresses (one for each domain or at least one for each SSL certificate) and, therefore, can recognize by the IP address which certificate should be used. (I don't know how IIS handles this, though.)

The assignment of new IP addresses becomes more problematic with the increasing deficit of IPv4 addresses for these and other reasons. RFC 6066 (and its predecessors) defines the TSL name extension of the server (extension-ID 0), which allows the client to include the name of the requested server in the ClientHello message (which starts handshake), allowing the server to select the correct certificate for.

A serious certification agency will not give you a wildcard certificate for *.com or the like, since with such a certificate you can claim to be almost anyone. A certificate may contain several domain names, but I have no idea if there is an upper limit in the number of such (both for IIS and for ordinary clients).