So, you are ready to purchase SSL certificates, did you know that not all SSL certificates are created equally? Let me start by taking a step back and asking an easier question, do you want your site to be available with and without a leading ‘www.’? Many people may not even consider the latter question relevant, but I assure you it is. Some people have a preference in that they always want the URL to either include the leading ‘www.’ or remove it while others do not care and want them both to work. In either case, a SSL problem may exist depending on the issuer of the SSL certificate.
For example, here is a simple Apache virtual host entry:
NameVirtualHost *:80 <VirtualHost *:80> ServerName a.com DocumentRoot /var/apache2/htdocs/a.com </VirtualHost>
Now, assume you want the domain to always resolve with the leading ‘www.’ for the a.com domain. Utilizing mod_rewrite this could be achieved with the following modified virtual host entry:
NameVirtualHost *:80
<VirtualHost *:80>
ServerName a.com
DocumentRoot /var/apache2/htdocs/a.com
RewriteEngine On
Options +FOllowSymlinks
RewriteCond %{HTTP_HOST} !^www.a.com [NC]
RewriteRule ^(.*) http://www.a.com$1 [L,R=301]
</VirtualHost>
Alternatively, if you want the domain to work with or without the leading ‘www.’ you could use the following virtual host entry:
NameVirtualHost *:80 <VirtualHost *:80> ServerName a.com ServerAlias www.a.com DocumentRoot /var/apache2/htdocs/a.com </VirtualHost>
Now, what would the virtual host entries for the two above scenarios look like for a.com over SSL? Many people might people think the entries would look the same except with the ‘*’s replaced by unique, static IP addresses. While this is true, if you try it with a real SSL certificate you may be surprised by the result. With some SSL certificates the site will work fine with or without the leading ‘www.’ while on others only the Fully Qualified Domain Name (FQDN) specified during the SSL certificate creation will work properly. The reason for this is because of how SSL works, the type of SSL certificate used, and the issuer of the SSL certificate.
SSL certificates come in many varieties including individual, which is used to secure a single FQDN; group or multiple, which is used to secure several FQDNs using a single certificate (the number is specified by the issuer); and wildcard, which is used to secure all subdomains of a FQDN. As it turns out, SSL certificates are different from issuer to issuer. As an example, GoDaddy individual SSL certificates secure the FQDN of a site with or without the leading ‘www.’ while VeriSign only secures the FQDN used to create the certificate. In addition, GoDaddy Multiple Domain Certificates secure only the primary domain with and without the leading ‘www.’ with all the other domains secured only by the FQDN entered into the certificate. Finally, VeriSign Wildcard SSL certificates secure every subdomain of the FQDN except with the leading ‘www.’. More information about GoDaddy SSL certificates is available here: http://help.godaddy.com/topic/234/article/850. Unfortunately, VeriSign does not make it known in what configuration the SSL certificates will work. For more information, about VeriSign SSL certificates you should contact VeriSign directly.
You may be wondering why it matters what the SSL certificate secures if you only want the FQDN to either work with or without the leading ‘www.’, but not both. The reason is because the SSL transaction happens before the HTTP transaction. This means if you have a.com with a VeriSign SSL certificate and want a.com to only be available with the leading ‘www.’ then if a user goes to https://a.com they will receive an error about an invalid SSL certificate and have to accept the invalid SSL certificate before being redirected to https://www.a.com. In addition, if you want a.com to be resolvable with or without the leading ‘www.’ and you have a single, individual VeriSign SSL certificate then you will experience the same problem for the FQDN that was not used to create the certificate. In the case of VeriSign, the only way to resolve this issue is to purchase two individual SSL certificates or move to a much more expensive and less secure option being wildcard certificates. So next time you are in the market for SSL certificates make sure you know what you are buying before you buy it.
I hope this three part series has been helpful to understand how (Apache) web servers work with SSL and what to look for in SSL certificates. Expect to see more tips and tricks about how to configure (Apache) web servers in the future.
© 2010, Steve Flanders. All rights reserved.
