It is not difficult to create an SSL/TLS certificate and configure an Apache HTTP Server to use it. But I found that there are some things you need to know that does not necessarily make much sense. Here are some lessons learned and a couple of tips.

Intermediate and Root certificates

A browser contains a trust store that contains a list of the Certificate Authorities (CA) it trusts.
When you access a site via https the web server will send a certificate to the browser and the browser checks if the certificate has been issued by a CA it trusts. You will get a security warning if it is not.

The CA certificates are stored in the browsers trust store are called root certificates.

If a root certificate got compromised it would be a big problem for the CA and their customers. Therefore CAs normally uses intermediate certificates as an extra layer of security. The intermediate certificate has a reference to the Root certificate and is used to issue certificates to their customers.

So there is a trust chain from the certificate to the intermediate certificate to the root certificate.

When the web server sends the certificate to the browser it also sends the intermediate certificate. Below is an example where the server has sent a wild card certificate and an intermediate certificate to a browser and the browser has matched the intermediate to a root certificate.

If you do not configure the web server with the intermediate certificate most browsers will automatically download it form the CA.

Here is an example.

This site still works fine and the end-users will not notice anything, but it is of cause not a good idea. If your site expose Web services the service consumer might fail because it does not automatically download the missing certificates.

You do not need to configure the root certificate on the Apache Server. For a long time I always stored both the intermediate and the root certificate. This will normally also work but it is not necessary. I have had a situation where a subcontractor had problems consuming a web service because of this.

You can test your SSL configuration via:
https://www.ssllabs.com/ssltest

It will among other things tell you if your certificate chain is configured OK.

Here the root certificate is stored in the chain. A root certificate is also called a trust anchor.

Here the root certificate is stored in the chain and the root certificate is stored before the intermediate certificate.

Here everything is OK.

You can validate a certificate and the full chain via OpenSSL, but you will need a file with both the intermediate and the root certificate.

openssl verify -CAfile intermediate.and.root theheat.dk.cer
theheat.dk.cer: OK

Fingerprinting certificates with openssl

You sometimes get a certificate without the intermediate certificate. It can sometimes be a bit difficult to find the right intermediate certificate. Some CA’s have
… work in progress 🙂

www

I don’t think you should use www anymore but some customers still want it. www is often a cause of problems when you use SSL. When you access a site that uses SSL one of the first things that happens is a check to see if the site can be matched to the certificate.
If you access https://www.theheat.dk the check will see if it can match www.theheat.dk to the certificate. If it can, everything is OK, if not you will get a security warning.

This check happens before you can do any redirects etc. on the host, so the match has to work.

A certificate is issued to a Common Name (CN), for example www.theheat.dk.

A certificate have only one CN. So if all access your site is via the CN in the certificate everybody is happy. But sometimes you want to be able to access the site both with and without www.

If the CN is www.theheat.dk and you access the site via theheat.dk you will get the security warning and if the CN is theheat.dk and you use www.theheat.dk you will also get the warning.

There are two solutions to this problem. You can use two certificates one for each CN or you can use a certificate feature called Subject Alternative Names (SAN).

If you have many domains buying two certificates for all of them can be an expensive solution. But not all CAs support SAN, so if you are stuck with one that doesn’t you might have to. A have a customer who did not want to pay for extra certificates so they chose to do nothing. But that might not be the best solution 🙂

Paypal is an example of a site that uses two certificates instead of using SAN. When you access paypal.com one certificate is used, and then you are redirected to www.paypal.com that uses another.

If you test paypal.com via https://www.ssllabs.com/ssltest you can see the details.

Subject Alternative Names

A certificate can have a SAN field where the CA can insert aliases that will be accepted just like a CN.

In this example both vestjyskbank.dk and www.vestjyskbank.dk will work.

Wild card certificates

Wild card certificates has the same issues as regular certificated. If you have a certificated with CN *.theheat.dk it will work fine with www.theheat.dk and any other sub-site, but not necessary with theheat.dk. Again you will either need two certificates or a certificate from a CA that supports SAN.

Here is example of wild card certificate with SAN.

*.efteruddannelse.dk and efteruddannelse.dk is all you need in the SAN. I don’t know why they have added www.efteruddannelse.dk here.

While we are on the subject of wild card certificates be aware that they only work for one “level” of sub-sites. A *.theheat.dk certificate will work fine for oracle.theheat.dk but not for test.oracle.theheat.dk.

Choosing the right CA

I don’t know why some CA’s does not want to provide SAN support or if there are any security implications of using SAN certificates. But it is important to choose a CA that matches your requirements.
There are many CAs today and not all of them can be trusted so you should be careful when selecting one.

www and DNS

If you want to use www you need to add a cname record to your DNS configuration:

host -t cname www.theheat.dk
www.theheat.dk is an alias for theheat.dk.
host -t cname cgi.dk
cgi.dk has no CNAME record

OpenSSL

I normally use OpenSSL to create the CSR file that is sent to the CA.
Instead of interactively inputting the single parameters to OpenSSL I like to script it all:

# Generate private key
openssl genrsa -des3 -out private.key -passout pass:EverybodyCanReadMe 2048

# Remove pass phrase from private key
openssl rsa -in private.key -out private.key -passin pass:EverybodyCanReadMe

# Create CSR file
openssl req -new -subj '/C=DK/L=Aarhus West/O=Lorenzen Consulting/OU=IT/CN=theheat.dk' -key private.key -out theheat.dk.csr

# Show the request
openssl req -in theheat.dk.csr -noout –text