Friday, April 3, 2009

Creating SSL Certificates with Multiple Host Names

Creating an SSL Certificate with Multiple Hostnames

There's another article on creating wildcard certificates in apache (and here on IIS), but we've not discussed the possibility of having a single certificate answer to several hostnames (DNS cnames, and http host headers). This uses an SSL feature called SubjectAlternativeName (or SAN, for short). Not only is this possible, but it's reasonably easy. We'll talk about generating the certificates using openssl on linux, but openssl is available for Windows, also, and the procedure is the same. Note that Windows' selfssl utility doesn't provide the ability to generate a certificate request file with SANs, so if you want to use this on Windows, you'll need to use openssl or another ssl utility.

Generate the Certificate Request File

For a generic SSL certificate request (CSR), openssl doesn't require much fiddling. Since we're going to add a SAN or two to our CSR, we'll need to add a few things to the openssl.cnf file.

Edit openssl.cnf

Edit your openssl.cnf file (by default, in RHEL v5, at /etc/pki/tls/openssl.cnf).
vim /etc/pki/tls/openssl.cnf
You should see, about a th
ird of the way down, a section that begins with [ req ]. This is the section that tells openssl what to do with certificate requests (CSRs). Within that section should be a line that begins with req_extensions. We'll want that to read as follows:
req_extensions = v3_req
This tells openssl to includ
e the v3_req section in CSRs. Now we'll go own down to the v3_req section and make sure that it includes the following:
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names 
[alt_names]
DNS.1 = kb.example.com 
DNS.2 = helpdesk.example.com 
DNS.3 = systems.example.com
You'll notice that in our example above, we've added three SANs.
Note that whatever we put here will appear on all CSRs generated from this point on: if at a later date you want to generate a CSR with different SANs, you'll need to edit this file and change the DNS.x entries.

Generate a private key

You'll need to make sure your server has a private key created. It usually does (in/etc/pki/tls/private, normally called localhost.key), but it not, you'll need to create one:
openssl genrsa -out /etc/pki/tls/private/domainname.key 1024
Where domanname is the FQDN of the server you're using. That's not necessary, BTW, but it makes things a lot clearer later on. Do not enter a passphrase for this private key! Doing so will require a password to be entered each time apache starts, which, on the whole, is a terrible thing. Make sure that your ssl.conf file (/etc/httpd/conf.d/ssl.conf or whichever is the active httpd
conf file) contains the line:
SSLCertificateKeyFile /etc/pki/tls/private/domainname.key
Otherwise, Apache won't have the information necessary to decrypt the SSL traffic.

Create the CSR file

Now we're ready to create the CSR.
openssl req -new -out /tmp/domainname.csr -key /etc/pki/tls/private/domainname.key
Where /tmp/domainname.csr includes the FQDN of the server, and domainname.key is the private key referred to above. You'll be prompted for information about your organization, and it'll ask if you want to include a passphrase (you don't). It'll then finish with nothing much in the way of feedback. But you can see that /tmp/domainname.csr has been created. It's nice to check our work, so we can take a look at what the csr contains with the following command:
openssl req -text -noout -in /tmp/domainname.csr
You should see some output like below. Note the Subject Alternative Name section:
[root@domainname /]# openssl req -text -noout -in /tmp/domainname.csr
Certificate Request:
Data: Version: 0 (0x0)
Subject: C=US, ST=Texas, L=Fort Worth, O=My Company, OU=My Department, CN=server.example.com/emailAddress=notreal@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit) Modulus (1024 bit): blahblahblah Exponent: 65537 (0x10001)
Attributes:
Requested Extensions: X509v3
Basic Constraints: CA:FALSE X509v3
Key Usage: Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Alternative Name:
DNS:kb.example.com, 
DNS:helpdesk.example.com, 
DNS:systems.example.com 
Signature Algorithm: sha1WithRSAEncryption blahblahblah
So now we've got a shiny new CSR. But, of course, we have to sign it.

Sign the CSR and create a new certificate

Openssl has certificate authority signing functionality, but frankly, I found it wanting a bit more than I was willing to give it (serial number files, etc.). Not that it's difficult: there's a great step-by-step guide to using openssl to sign CSRs at http://www.flatmtn.com/article/setti...e-certificates. Instead, I found it easier to download and install SimpleAuthority. It's a free utility for signing CSRs, and it can be downloaded at http://simpleauthority.com/download.html. It works on Windows, Mac, and linux, though you should note that the linux version requires using the SUN Java package (intructions for setting up here) as well as the unlimited encryption strength cryptology encryption files (see the bottom of the Sun download page, under "other downloads"). When you run simpleauthority the first time, it'll prompt you to create a new user and to create a new CA. There are two things that are especially important in this step:
  1. Make sure you remember the password you create; you'll need it each time you sign a CSR.
  2. Make the CA last for 10 years; we don't need these expiring.
Having created the CA, you need to sign the CSR: From the tools menu, select Import -> Certificate Signing Request. SimpleAuthority will prompt for the .csr filename we created in the previous steps. Select that file and click on Open. When you open the csr, you'll be promptd with the following: The requested dname is "...". SimpleAuthority normally only includes CN, OU (x1), O and C fields in the Subject dname. Do you want to include the extra fields in the certificate? The answer is yes. When you click on Yes, you'll see another dialog box asking for the type of certificate to create. Select SSL Server and increase the certificate validity to 3650 days. There's no reason not to make it 10 years. Make sure you've checked the "include extension requests" box; this tells SimpleAuthority to use the SAN fields from the CSR. When you click on OK, your new certificate will be created. you'll see it listed in the main screen. To export this to a file (and copy back to the server), click on the server name in the left-hand panel and then right-click on the certificate listed at the bottom-right. Select export certificate. When you choose to export the cert, you'll be prompted for the file type. Select PEM format and click on export. Choose a filename, and your pem file will be created.

Install your new certificate

Apache

In apache, all that's required is to edit your ssl.conf file and make sure the SSLCertificateFile points to your new .pem file. It's recommended that you place it in /etc/pki/tls/certs. Then restart apache:
service httpd restart

IIS

In IIS , you've got to convert this file to a .pfx format:
openssl pkcs12 -export -in domainname.pem -inkey /etc/pki/tls/private/domainname.key -out /tmp/domainname.pfx -name "domainname"
The above command will convert the pem file to pfx format, which you can import into IIS: Right click on the web site and select properties. Click on the directory security tab and then on the server certificate button. A wizard will pop up; click next, and then you can select to import a pfx certificate. That should be it.

Note the CA Certificate!

There's a rub in doing this: your CA, as a matter of course, won't be trusted by anyone. This normally isn't a problem, as it's true of self-signed certificates, as well. However, many applications (PrinceXML, for example) that retrieve documents from your web site will fail if they don't trust your CA. You'll want to make sure that you export your CA certificate (Tools -> Export -> CA Certificate) and add it to the trusted CA list for your applications.

6 comments:

  1. This is a good guide, we've just installed our wildcard ssl on IIS but i wish i would have seen this first, would have saved me a lot of time!

    ReplyDelete
  2. I assume you meant -inkey domainname.key and not domainname.pem

    ReplyDelete
  3. NetMage, you're right; thanks for the heads-up! It's been corrected, now. -Lane

    ReplyDelete
  4. This is great and its exactly what I've been looking out for! I picked up a SAN SSL certificate from SSL247.com and followed this to the letter and couldn't be happier. Thanks for very much for this!

    ReplyDelete
  5. We really want to appreciate your effort for this blog which is based on Multiple host names for SSL certificate securities. We found your blog has entire information about SSL certificate security on multiple host names. We really want to add your blog within our SSL eduction platform. I hope that your tutorial blog will help our SSL education users. Thank you so much for your efforts.

    ReplyDelete

Thanks for leaving a comment!