I have one server that goes by the hostname of "bert.secret-wg.org". It has other identities too; "www.trend-watcher.org" and "www.net-dns.org" are examples.
The Apache documentation claims that name-based virtual hosting and SSL can not work
Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol.
Fortunately there is a hack that works. There is an X509 extension called subjectAltName that can be used to create one certificate that can be used for the many identities that your server uses.
There are a couple of things that I stumbled upon that might be nice to know if you try to set this up yourself.
In order to be compatible with Firefox you will need to specify the hostname in your subjects common name (CN) but you will also need to specify your hostname in the set of subjectAltNames
Certificate Signing Request
In order to have your "CSR" carry all the subject altnames you need you will need to hack your openssl.conf file.
What follows are the relevant portions or the openssl.conf. First the [req] section that includes the "req_distinguished_name" sections
[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
here is the "req_attributes" section. For each subjectAltName you want to use you will have to add two lines to the conf file.
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = NL
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = North Holland
localityName = Locality Name (eg, city)
localityName_default = Amsterdam
0.organizationName = Organization Name (eg, company)
0.organizationName_default = The Secret Working Group
# we can do this but it is not needed normally 🙂
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Web Server
commonName = Common Name (eg, YOUR name)
commonName_default = bert.secret-wg.org
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
emailAddress_default = email@example.com
0.subjectAltName = Subject altname
0.subjectAltName_default = DNS:www.net-dns.org
1.subjectAltName = Subject altname
1.subjectAltName_default = DNS:www.secret-wg.org
2.subjectAltName = Subject altname
2.subjectAltName_default = DNS:www.trend-watcher.org
3.subjectAltName = Subject altname
3.subjectAltName_default = DNS:bert.secret-wg.org
Once you have this in place you run openssl:
openssl req -config special.conf -new -key private.key -out certificat_sign_request.crs
It is this beast that you want to get signed by your certificate authority. Which gets us to the next problem
CA does not copy SubjectAltName
There is a feature (bug) in openssl. Even if your "copy_extentions" directive in the openssl.conf file reads "copyall" the CA fails to copy the subjectAltNames. You will have to configure the subjectAltNames that need to appear in the signed certificate into your openssl.conf otherwise they will be stripped.
So in your CA’s openssl.conf you will have to put somewhere in the ‘[usr_cert]‘ section:
Off course you should not forget to remove this line once you signed the certificate.
In theory you can off course skip hacking the openssl configuration for the certificate signing request and just have the CA introduce the subjectAltNames, that is what is effectivly being done now. But remember, setting the subjectAltNames by the CA is a workaround that should not be needed in the future.
The apache configuration is trivial. For each virtual name you will have to setup a virtual host both on port 80 as well as on port 443.
# Wherever you see square brackets you should see angle brackets,
# plog just does not accept them …
(… the usual cruft …)
(…exactly the same the usual cruft …)
# use exactly the same SSL key and CERT for each of the virtual SSL servers
So now I can securely set up a connection without all the warning boxes. That is, as long as the proper CA root certificate has been loaded into my browser.