Multiple Names on One Certificate
While it is not possible without TLS extensions to serve different certificates for a single IP (See com and www.foo.org can share a certificate. This approach would not be appropriate except in certain circumstances. You wouldn’t want to have two different customers using the same certificate but a single customer may wish to use one certificate for all of their domains. Both Internet Explorer and Firefox honor certificates of this type. From what I read some Java SSL libraries do not handle this type of certificate properly but Java was the only exception. on how to setup apache on Debian for TLS extensions.) it is possible to have a single certificate that works with any number of hostnames. I’m not talking about a wildcard certificate but a certificate that allows completely different hostnames to be valid for a single certificate. For example www.foo.
x509 certificates, those that are served in SSL communications, offer a feature known as Subject Altnerative Names. A subject Alternative Name is an attribute that lists an alternate name for the subject of the certificate (that’s oddly fitting isn’t it?). In a web context that subject is the hostname. However it’s not just hostnames that can be an alternative subject. Email is an option as is IP addresses.
The first step is to create a CSR (certificate signing request) that contains the subject alternative names that you desire for your certificate. I will show how to do that using openssl. You will likely need to modify the default openssl.cnf file. In Debian this is located in /etc/ssl/openssl.cnf. Note that you may prefer to make modifications to a local copy and tell openssl to use your locally modified copy using the -config option. For simplicity I will omit -config localopenssl.cnf from my examples.
Config File Settings
You need to tell openssl to create a CSR that includes x509 V3 extensions and you also need to tell openssl to include a list of subject alternative names in your CSR. In my openssl.cnf I have the following:
In the [req] section
[req] req_extensions = v3_req
In the v3_req section:
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# Some CAs do not yet support subjectAltName in CSRs.
# Instead the additional names are form entries on web
# pages where one requests the certificate...
subjectAltName = @alt_names [alt_names] DNS.1 = www.foo.com DNS.2 = www.foo.org
Generating the CSR
Then the CSR is generated using:
$ openssl req -new -out $CSR_FILENAME -key $KEY_FILETo check to see if you got everything correct use:
$ openssl req -text -noout -in $CSR_FILENAME
You should see something similar to this:Attributes:
Requested Extensions: X509v3
Basic Constraints: CA:FALSE
X509v3
Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3
Subject Alternative Name: DNS:www.foo.com, DNS:www.foo.org
1 comment:
We glad to write here on blog post which is complete and clean guidance for multiple domain UCC SSL CSR generation. Being Platinum Certificate Authority and Cheap SSL Certificate provider, we would like to add your blog post at SSL Installation Education blog where other users can see your blog and we assure that it will surely help to other users.
- Thanks
Post a Comment