Wild Card SSL Certificates

Note: These days you should consider at least subjectAltName (or maybe Server Name Indication). I recommend reading the blog post Self-Signed Certificates: How to get Cross Browser Compatibility with Wildcard Domains .

Why Wild Card Certificates

When initiating an SSL connection the server has to provide a certificate (the public part of an asymmetric key) to the client which will be used to initiate the (symmetrically) encrypted session. This certificate contains the host name of the server and the client can then check whether it got the appropriate certificate.

In many cases, like in https connections, the certificate has to be provided before the client had a chance to specify which virtual host it wants to query. At that time only the server's IP address can differentiate between queries. The standard approach is then to use a separate IP address for each virtual host for which a secure connection is needed.

Another way out of this dilemma is to use wild card certificates. While a certificate for www.heebs.ch will not do for webmail.heebs.ch, a certificate for *.heebs.ch will be valid for both. We can even go further and use just * for the host part of the certificate. This allows us to provide virtual hosts including https connections for any virtual host name from the same IP address (even dynamic ones).

Is This Safe?

Given that you hardly ever see wild card certificates and that the host name was chosen to be a part of the certificate you may ask yourself whether it is safe to use wild card certificates. It turns out that in many cases it is perfectly safe.

First of all, a certificate served two purposes. One is to provide a public/private key pair to initiate an encrypted connection. For this purpose alone even a throw-away key pair generated on the spot would suffice. The encryption is as safe as the algorithms used and not dependent on the host name part of the certificate. The other purpose is to prove some identification of the server involved. With a wild card certificate you will not get any additional indication of the autheticity of a site beyond the signature of the certificate and the DNS response you get.

If you run a web shop where you expect customers from all over the place, you would want a properly signed certificate from one of the well-known authorities and there you will not get a wild card certificate signed. After all, they provide and charge money for the service of identifying the owner of a particular certificate and the don't want to write the equivalent of a blank cheque. You will then also need a separate IP address for each virtual server.

However, in many cases you run just a bunch of web servers where most of the visitors will use the unencrypted http channel and only a handful of web editors/admins will need an encrypted connection for their through-the-web editing. You can then tell this small group to install the CA cert (see below) used to sign the wild card certificate and to be extra careful that they are connecting to the right URL when they are typing in their passwords, which they should do anyway. You also need to be extra careful that you guard your private key for the certificate as it would make a man-in-the-middle or a phishing attack that much easier in case it got stolen.

Further notes:

How to Create a Wild Card Certificate

There is nothing special about the actual process of creating a wild card certificate. You can find instructions on the net. Here, I write down my own how-to just to save me the trouble to look it up elsewhere. Of course, we have to create our own Certificate Authority (CA) as no official certification organization will sign a wild card certificate. As a result we will have two key pairs (with a private and a public key for each), one for our certificate authority and one for the certificate request. The later will be the one with the wild card.

The following description is based on a Debian 3.0 (woody) Linux system. Other distributions should be similar, but you could also use a chroot environment with Debian/woody on any Linux system.

We are using OpenSSL to create the key pairs. Let's install the package and create a directory to hold the two key pairs.

# apt-get install openssl
# mkdir CA
# cd CA

The easiest would be to use the script at /usr/lib/ssl/misc/CA.pl provided by openssl but we like to specify our own options. In the same vein we first edit the /etc/ssl/openssl.cnf config file. Especially the variables ending in _default are good candidates if you want to leave out one of the item. E.g., specifying a "State" makes sense for the USA, but it looks strange for other countries (like Switzerland). The problem with a non-empty default value is that we cannot choose not to use it. So probably it is best to leave these defaults empty. I.e., comment out countryName_default, stateOrProvinceName_default, and 0.organizationName_default.

First we create the certificate authority. In this example we choose a 10 year life time for the CA validity. The default would be 30 days.

# mkdir -p demoCA/{certs,crl,newcerts,private}
# echo 01 > demoCA/serial
# touch demoCA/index.txt
# openssl req -new -x509 -keyout demoCA/private/cakey.pem -out demoCA/cacert.pem -days 3652
You will be asked about a pass phrase and some identifying information.
Just answer sensibly.  Nothing of this will be relevant to the functioning
of the CA, but it will give the users some information about your CA.  If
something does not apply, leave it empty.

Now we have two files, demoCA/private/cakey.pem and demoCA/cacert.pem. The former is the private key used to sign other certificate requests (this is where the pass phrase comes in). The latter is the public key, i.e. the part of the CA we distribute to our friends and have them install in their browsers or mail readers if they so desire.

Now let's continue with the creation of the actual certificate request.

# openssl req -new -keyout ./wildcard.req -out ./wildcard.req -days 3652
Again just choose reasonable values or leave them empty.  However, when asked
for the "Common Name" or CN you should enter an asterisk for the wildcard
certificate instead of the more usual DNS name of the service.

Now we have a file wildcard.req containing both the private and the public key for our certificate request, i.e., a key not yet signed by a certificate authority. So the next step is to sign the request by our CA created above.

# openssl ca -policy policy_anything -out wildcard.crt -infiles wildcard.req
You need to provide the pass phrase for the CA.

In most cases we need to make the private key without a pass phrase available to a service like a web or imap server so they can start automatically without user intervention. So let's extract the private key without the pass phrase.

# openssl rsa < wildcard.req > wildcard.key
You need to provide the pass phrase for the request.

The files wildcard.crt and wildcard.key are the ones we need for apache, imap, and other services if we want to provide SSL/TLS encryption for them.

Further Reading

update: 2011-04-12, original version: 2005-12-17

Elmar Heeb, 2011/04/12 17:49:38.076173 GMT+2