Editor's Note: This post was updated to reflect changes to how sites with extended validation certificates are displayed in browsers.
The CA Security Council (CASC), an advocacy group committed to the advancement of online security that we joined in 2013, recently published a handy infographic – What Kind of SSL/TLS Certificate Do I Need? (check it out below this post). While the infographic provides a great high level overview of the main options for certificates and provides some examples for each, we tend to get a lot of questions on this, so I thought some further explanation would be helpful.
Below I’ll take you through the steps to take in selecting an SSL Certificate, as suggested by the CASC, with some additional context to help frame your decisions.
Step 1 - Is Your Domain Registered?
First things first, you need to register your domain before you can obtain a publicly trusted SSL Certificate (meaning the kind you need for public websites, more on this below). This is because Certificate Authorities (CAs), the organizations that issue certificates, need to verify domain ownership.
Registering your domain is an essential step for setting up a public site, so the odds are, if you’re looking to secure a public website at least, you’ve already got this step taken care of and can move on to Step 2.
What If Your Domain Isn't Registered?
If your domain isn’t registered, you’re likely talking about an internal server name. An internal name is a domain or IP address that is part of a private network, for example:
- Any server name with a non-public domain name suffix (e.g. mydomain.local, mydomain.internal)
- NetBIOS names or short hostnames, anything without a public domain
- Any IPv4 address in the RFC 1918 range (e.g. 10.0.0.0, 172.16.0.0, 192.168.0.0)
- Any IPv6 address in the RFC 4193 range
As of November, 2015, CAs are prohibited from issuing publicly trusted SSL Certificates containing internal server names or reserved IPs. In short, this is because these names are not unique and are used internally, so there is no way for a CA to verify that the company owns it (e.g. many companies may have an internal mail system at the address: https://mail/). For more explanation on the dangers of internal names in public SSL Certificates, check out our white paper.
SSL for Internal Server Names
So what can you do if you want to secure communications between your internal servers that use internal server names? Well, you can’t use a publicly trusted SSL Certificate, so one option is to use self-signed certificates, or set-up an in-house CA (e.g. Microsoft CA) and issue certificates from there. While these are certainly viable options, running your own CA requires extensive internal expertise and can be quite resource-intensive.
Some CAs (cough GlobalSign cough) also offer certificates designed exactly for this use case. Issued from a non-public root, these certificates don’t need to comply with the same regulations put upon public certificates, so they can include things like internal server names and reserved IPs. This way you can secure your internal servers without the hassle of running your own CA or doing self-signed certificates.
Step 2 – What Trust Level Do You Require?
All SSL Certificates offer session security and encrypt any information submitted through the website, but they differ in terms of how much identity information is included in the certificate and how they display in browsers. There are three main trust levels for SSL Certificates, from highest to lowest – Extended Validation (EV), Organization Validated (OV) and Domain Validated (DV).
When deciding between trust levels, the main question to ask yourself is, “How much trust do you want to convey to your visitors?” You should also consider how important your brand identity is to your web presence. Do you want your brand clearly presented in the browser’s address bar or just included in the certificate itself? Or is tying your brand identity to your domain not that important to you?
Extended Validation (EV) Certificates
EV Certificates include the most company data and companies must meet the highest, most stringent requirements of any type of SSL Certificate before receiving a certificate. They also lend the most credibility to your website by bringing your business’s verified identity front and center – clearly displaying your company’s name with a locked padlock.
Example site secured with EV Certificate in Chrome
Organization Validated (OV) Certificates
OV Certificates also include business authentication, meaning information about your company is included, but, unlike EV Certificates, this information is not as prominently displayed. In order to see your company’s identity information, visitors need to view the certificate details.
Example OV Certificate details in Chrome. You can see the company information included in the Subject.
Domain Validated (DV) Certificates
DV Certificates are the most basic type of SSL Certificate, including the least amount of identity information in the certificate and only proving the website owner could demonstrate administrative control over the domain. While DV Certificates offer session encryption (so they’re certainly better than nothing), they don’t include any company information. This means, for example, there’s nothing included in a DV SSL Certificate issued to www.companyabc.com to verify that it is actually run by Company ABC.
Because of this, we don’t recommend DV Certificates for business use. Given the rise of imposter and phishing websites, we recommend website operators use SSL Certificates that include company identity information (i.e. OV or EV) so site visitors can view the identity of the domain owner.
Step 3 – How Many Domains Do You Need to Protect with This Certificate?
Just One – Use a Standard Certificate
If you only need to secure one domain (e.g. .example.com), then you should purchase a single domain, or standard certificate. You have your choice of trust level – DV, OV, or EV.
If, however, you need to secure multiple domains (e.g. for regional sites - .com, .co.uk, .de), or multiple sub-domains (e.g. for customer areas – login-secure.example.com), you should consider purchasing a Wildcard or Multi-domain Certificate. Using one certificate to cover multiple fully qualified domain names (FQDNs) is more cost-effective than purchasing multiple individual certificates and simplifies management, especially when it comes time for certificate renewal.
Multiple Domains
If you want to secure multiple domains (e.g. example.com, example.net, example.co.uk) with one certificate, then you should purchase a Multi-domain Certificate. Multi-domain Certificates allow you to secure multiple domain names using only one certificate. The domains are listed as Subject Alternative Names (SANs) within the certificate, which is why you’ll often hear people referring to these as SAN certificates.
Multiple Sub-Domains
If you want to secure multiple sub-domains (e.g. login.example.com, payment.example.com) with one certificate, you can use either a Wildcard or a Multi-domain. Which one is best for you depends on the number of sub-domains you need to secure and the trust level you want.
If you have a lot of sub-domains, or anticipate adding more in the future, you should consider a Wildcard Certificate because you can secure an unlimited number of sites directly under the domain. Wildcard Certificates have a common name of the format *.example.com, so it will secure the examples listed above with a single certificate. Wildcard Certificates are supported by the DV and OV products, but industry requirements do not permit EV Wildcard Certificates.
If you have only a few sub-domains, or if your sites contain different number of nodes in the domain name (e.g. store.exaple.com, store.us.example.com, store.eurpoe.example.com), you should consider a Multi-Domain Certificate using sub-domains because they are generally more cost-effective than Wildcards and are more flexible in supporting various levels of domains. Subdomain certificates are supported by DV, OV and EV.
Here's the full infographic from the CASC.
