Wildcard SSL Certificates & SAAS

Question

From what I have read, using a wildcard SSL/TLS certificate is not advisable, how do you do certificate issuing & management in your SAAS application(linux) where each client has a user selected subdomain?

Answer 1

There is nothing wrong with "wildcard certificates". A wildcard certificate is equivalent to a certificate containing a lot of possible server names. If this maps well to your problem (e.g. you have a server with a lot of frontends who advertise distinct names, but all these names are in the same domain and you control that domain), then wildcard certificates are certainly a possibility. The main issues with wildcard certificates are:

• A wildcard certificate is usable with several server names, and you usually need to use several names because you have several machines. Since the wildcard certificate corresponds to one private key, that private key will have to be installed on all these machines. Private keys which are duplicated and which travel around are somewhat less private, because they are more exposed.

• Commercial CA use a business model that relies on selling many certificates. A wildcard certificate allows a customer to buy one certificate instead of many. Thus, commercial CA tend to make wildcard certificates much more expensive, to compensate for the corresponding loss of business.

---

In your situation, as I understand it, you have a hosting server, who runs a SSL server for several sites; the sites have names which follow the pattern name.example.com where name is a customer-specific name, and example.com is a domain under your control. Since, in HTTPS, the SSL dialogue occurs first (before any HTTP occurs), the server does not (usually) know the intended server name (the name from the URL which the client uses), the server must somehow send a certificate which "works well" with all possible names from the client. This leads to three possible solutions:

1. Use a wildcard certificate with *.example.com. This will work well.
2. Use a certificate with many names in the Subject Alt Name extension. You can put hundreds of names in there. This also works, but you have to obtain a new certificate every time you want to add a new name (a certificate is signed by the CA, you cannot change anything in it without invalidating the signature).
3. Make the server "guess" the intended server name, so that it may send the "right" certificate (the server would then have many certificates, one for each site name). This uses the Server Name Indication extension: a slot in the early SSL handshake messages so that the client may tell to the server, before the server actually sends its certificate, which site name the client is expecting. SNI works well except that some old browsers or OS do not send it, so using this extension means that you will not support such clients. The main unsupported client is Internet Explorer on Windows XP (IE on newer Windows systems is fine). If you think you can afford to reject clients who still use Windows XP and IE, then SNI is a workable solution for you.

The wildcard certificate still seems the simplest and most robust method.

Answer 2

Using wildcard certificate isn't really an issue if you understand the implications.

However, if you do not want (or cannot) use a wildcard cert, then in your case you have little choice but issue a new, separate certificate for each subdomain.

In theory, you could also use SAN certificate but unless you know in advance the complete list of domains you're going to have to secure, it's going to be a solution that grows even more poorly than having a new certificate for each sub-domain.

Now, if you're not willing to use a wildcard certificate, why exactly are you unwilling to have a new cert issued for each new customer ?

Edit: you are concerned about losing the whole system in case your key is compromised. however, there is little practical reason why splitting the encryption using multiple keys will improve security: the only party that will be required to have access the to the private key are the server SSL endpoints so, assuming you have little control about what happen on the end server (and you fear that customer action will cause their own server to be compromized, perhaps because you let them run their own code, then the solution is to deploy a reverse proxy in front of your servers that will handle the public crypto and hold your key secure (you can even setup an internal SSL connections between the proxy and the servers if you want to encrypt communication inside your network).

Such a system will be simpler to manage and secure than having each server use their own certificate (plus, it'll be cheaper and can be implemented with off the shelf solutions).