One of our customers runs a system that has a shopping cart system and they like it when a customer upgrades their site to include full store functionality. This of course means an SSL certificate. And traditionally, this would mean an additional IP address that would need to added to the server to support the new certificate.
Entering wider spread usage is what is becoming known as the UCC (Unified Communications Certificate), which is just a fancy name for a regular X509 v3 certificate that utilizes the Subject Alternate Name extension. This extension allows the certificate creator to embed multiple alternate names that are cryptographically tied to the primary key that defines the certificate.
What this means in practical terms is that you could purchase a certificate whose primary name is www.mydomain.com and with the same certificate and IP address, support multiple variations of that domain name, such as secure.mydomain.com or www.mydomain.net, www.mydomain.org, etc… This is different than a wildcard certificate that is tied to a specific domain name and can be used on any third level host name as desired: *.mydomain.com.
Since many entities that have a web presence tend to pick up the .net/.biz/.org variations on their .com domain name, this type of certificate means that those additional names can be secured with the same certificate/IP address. This means simpler configuration and not having to burn an IP address for every single name variation.
I’ve tested GoDaddy’s version of this certificate that gives you a 5 name cert for $60/year on plain jane Apache under 10.4 client and it works without issue. I have two different vhosts with different ServerName directives and the SSL config under both simply use the same SSL
Example. Assume I have a cert that I have based on mydomain.com as the primary name and has the following names embedded in as Subject Alternate Name extensions:
- www.mydomain.com
- store.mydomain.com
- www.mydomain.net
- mydomain.net
- admin.mydomain.net
Also assume that I have two different facets of my web application. The public facing side that is served by the .com and the admin/extranet that is served under the .net variation. My Apache config would look like so:
Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
ServerName www.mydomain.com
ServerAdmin support@mydomain.com
DocumentRoot “/www/mydomain-com/”
<IfModule mod_ssl.c>
SSLEngine On
SSLCertificateFile “/etc/httpd/ssl/mydomain-com.crt”
SSLCertificateKeyFile “/etc/httpd/ssl/mydomain-com.key”
SSLCertificateChainFile “/etc/httpd/ssl/gd_intermediate_bundle.crt”
</IfModule>
ServerAlias mydomain.com store.mydomain.com
</VirtualHost>
<VirtualHost *:443>
ServerName www.mydomain.net
ServerAdmin support@mydomain.net
DocumentRoot “/www/mydomain-net/”
<IfModule mod_ssl.c>
SSLEngine On
SSLCertificateFile “/etc/httpd/ssl/mydomain-com.crt”
SSLCertificateKeyFile “/etc/httpd/ssl/mydomain-com.key”
SSLCertificateChainFile “/etc/httpd/ssl/gd_intermediate_bundle.crt”
</IfModule>
ServerAlias mydomain.net admin.mydomain.net
</VirtualHost>
notice the certificate files are the same for both vhosts and there is no distinguishing between IP addresses on the VirtualHost directive. Nice, clean, simple and it Just Works.
I’ve tested the certificate in the following browsers and none of them complain at all:
IE 6, FF2, Camino 1.5, Safari 2/3, Opera 8.5
X.509 v3 has been around at least since 2002 so it should be well supported.
Now, OS X Server should work exactly the same way as the underlying Apache system pieces are the same. The only issue comes into play with the way that ServerMgr handles storing certificates, their keys and passphrases and how Apache integrates all of these items.
Using the Server Admin app, you will not be able to use one of these certificates to secure two different Hosts that you enter as the host name in Apache is used by the “getsslpassphrase” binary to locate the certificate, private key, and password for the host in question to start SSL.
Since the primary name of the certificate is NOT the name of this secondary vhost, the loading process will fail. Any usage of this type of certificate will require you to manually create whatever non-primary VirtualHosts that would be setup to take advantage of these additional names secure by the “UCC†cert.
In order to get these certificates to load you will need to remove the passphrase from the key file so that Apache doesn’t call the getpassphrase and then fail.
the basic command for doing this is:
openssl rsa -in mydomain.key -out mydomain.key.open
For those who are use to working with OS X Server and doing something a bit out of the ordinary, this should not be surprising.
More SSL Certificate vendors are starting to offer this type of certificate, but I like the extra feature that the folks at DigiCert include with ALL their certificates: unlimited usage on any number of servers.
The DigiCert products are more expensive than the ones at GoDaddy, but theirs are single root certificates and they also go through additional layers of validation more than the simple “can you get an email at the domain” verification that GoDaddy utilizes.