SSL and HTTPS are two of the most common security technologies on the internet today, but at the same time their use can be complex and challenging to get right. Over the next few weeks, we’ll be publishing a series of articles aimed at identifying some of the decisions that need to be made when buying, installing, and using SSL certificates. In this first installment, I’ll discuss some of the issues to consider when buying and requesting a certificate.
Our first recommendation is that you acquire an SSL certificate that is trusted by browsers rather than using a self-signed certificate. Self-signed certificates are typically generated by the server operator and provide no assurance whatsoever – they simply encrypt the connection between the Web browser and the server. Because anyone can generate one of these certificates for any site, we strongly recommend against their use. They also cause browsers to display nasty warning messages when someone visits your website – a really bad user experience.
Extended Validation (EV) certificates are the gold standard because the organization information they contain is rigorously validated with multiple checks that give a high degree of confidence that the information contained in the certificate is accurate. These certificates are great for any website that qualifies, but are especially important for ecommerce sites or any time credit card information is being collected. Due to the higher standards to which these certificates adhere, browsers grant them special treatment–typically by displaying the organization’s name in green in the navigation bar where the SSL padlock is displayed.
Another choice to make when purchasing a certificate is the number of domains that the certificate covers. In this case there are three categories:
- Single domain
- Multiple domain
- Wildcard
Single domain certificates are by far the most common, covering a single website such as https://www.example.com. Some certificates will automatically cover https://example.com (the name without the “www” prefix), and this is a feature that you should look for if users can access your site by typing the domain name without the “www” prefix – this certificate will protect those users.
Multiple domain certificates are sometimes referred to as unified communications certificates (UCC), dating back to their early use with Microsoft Exchange Server. These certificates are good to use when multiple related sites such as https://www.example.com, https://www.example.org, and https://www.example.net all run on the same server.
Finally, wildcard certificates support cases where multiple subdomains run on the same server and are used by the same business. A good example of this would be a commerce site with https://www.example.com, https://shop.example.com, and https://blog.example.com URLs. You might want buy a certificate with all three names in it, or just one wildcard with “*.example.com” in it. The latter might be more expensive, but allows for future expansion.
EV wildcard certificates are not allowed due to the inherent risk of a certificate that can secure any subdomain, even ones that the legitimate owner of the website may not know about. For instance, if someone were able to gain access to a bank’s SSL certificate or their web server, the attacker could set up a secure website at https://wwww.yourtrustedbank.com (notice the four w’s instead of the normal three) that would be difficult to detect.
The last thing I want to cover involves the process of requesting the certificate. You will often have the opportunity to choose the key size of the certificate when generating the certificate signing request (CSR). We currently recommend that you use a 2048-bit RSA key size. Certificate Authorities are discontinuing the long-running standard 1024-bit RSA key length because systems capable of breaking these keys may soon become commonplace. On the other hand, going to an even longer key size such as 4096-bit will have a somewhat negative impact on your site’s performance.
Many CAs are now offering SHA2 as an option for their certificates. While we would like to recommend this for both security and performance, some browsers (including Internet Explorer on Windows XP prior to Service Pack 3) don’t yet support it.
UPDATE: In the four years that have passed since this article was published, 1024-bit keys and the SHA-1 algorithm have been proven weak and banned. While secure alternatives such as ECC exist, the most common configuration today is a 2048-bit RSA key signed by the CA using a SHA-2 algorithm.
In the next article, we’ll dive into server configuration and explain the options you need to consider when installing an SSL certificate.
Wayne Thayer, Go Daddy
