Nobody likes being told that they HAVE to do something. It’s just human nature to rebel against that, but sometimes the best you can do is bite your lip and go with it. Such is the case with the HTTPS mandate that was handed down by Google and the other browser maker’s last Summer.
Nowadays, any website that’s still being served via HTTP is labeled as “Not Secure,” an epithet that threatens traffic and conversions. That means that every website now needs an SSL/TLS certificate, which facilitates migration to HTTPS and helps to secure communication between your website and its visitors.
This guide will go over the things you need to consider when purchasing an SSL/TLS certificate. We’ll start with a brief overview of the technology before delving into the specifics you’ll need to sort through when deciding on the right certificate for you and your website.
SSL/TLS 101: An Overview
In order to communicate securely on the internet, the server that hosts the website and the client trying to connect with it need to be using encryption. Encryption is a mathematical process that renders data unreadable to anyone but an authorized party. It’s performed using encryption keys, and in order for a client and server to connect securely the both need to possess a copy of the same key.
That presents a problem though, how do you securely exchange those keys? If an attacker is able to compromise an encryption key it renders that encryption useless because the attacker can still see all the data being exchanged as if it were in plaintext.
SSL/TLS is the solution to the key exchange problem.
SSL/TLS accomplishes two things:
- It authenticates the server so that clients know what entity they’re connecting to
- It facilitates the exchange of a session key that can be used to communicate securely
That may seem a little abstract so let’s put it in motion.
Anytime a client attempts to connect with a website via HTTPS – which is the secure version of the Hypertext Transfer Protocol (HTTP) that the internet has used for decades – a series of interactions occurs behind the scenes between said client and the server hosting the site.
There are two types of encryption keys involved in SSL/TLS encryption. There are the symmetric session keys that we just mentioned. Those can both encrypt and decrypt and are used to communicate during the connection itself. The other keys are the public/private key pair. This form of encryption is called public key cryptography. The public key can encrypt, the private key decrypts.
At the outset, the client and server will pick a mutually-supported cipher suite. A cipher suite is the set of algorithms that governs the encryption that will be used during the connection.
Once a cipher suite has been agreed on, the server sends its SSL certificate and public key. Through a series of checks the client authenticates the server, verifying its identity and that it is the rightful owner of the associated Public key.
Following this verification, the client generates a session key (or the secret that can be used to derive one) and uses the server’s public key to encrypt it before sending it to the server. Using its Private key, the server decrypts the session key and the encrypted connection begins (this is the most common form of key exchange, as performed with RSA – Diffie-Hellman key exchange differs slightly).
If that still seems a bit complicated, let’s simplify it even more.
- To communicate securely both parties need to share symmetric session keys
- SSL/TLS facilitates the exchange of those session keys with public key cryptography
- After verifying server identity, a session key or secret is encrypted with the public key
- The server uses its private key to decrypt the session key and begin encrypted communication
Now let’s get into what you, as a website owner, need to consider when purchasing or acquiring an SSL/TLS certificate.
What to consider when purchasing an SSL/TLS certificate?
When you purchase an SSL/TLS certificate you’re making a decision on two primary questions:
- What surface do you need to cover?
- How much identity do you want to assert?
When you can answer these questions, picking a certificate becomes a matter of brand and cost, you’ll already know the product type you need.
Now, before we go any further let’s establish one very important fact: regardless of how you answer those two questions, all SSL/TLS certificates offer the same encryption strength.
Encryption strength is determined by a combination of the cipher suites supported and the computing power of the client and server on either end of the connection. The most expensive SSL/TLS certificate on the market and a completely free one are going to facilitate the same level of industry-standard encryption.
What varies with certificates are the level of identity and their functionality.
Let’s start with what surfaces you need to cover.
1- SSL/TLS Certificate Functionality
Modern websites have evolved far beyond what they were in the early days of the internet when you still put counters on the bottom of a page to track traffic. Nowadays organizations have complicated web infrastructures, both internally and externally. We’re talking about multiple domains, sub-domains, mail servers, etc.
Fortunately, SSL/TLS certificates have evolved alongside modern websites to help better secure them. There is a certificate type for every use case, but it’s incumbent upon you to know what your specific use case is going to be.
Let’s look at the four different SSL/TLS certificate types and their functionality:
- Single Domain – As the name implies, this SSL/TLS certificate is for a single domain (both the WWW and non-WWW versions).
- Multi-Domain – This type of SSL/TLS certificate is for organizations with multiple websites, they can secure up to 250 different domains simultaneously.
- Wildcard – Security for a single domain, plus all of its accompanying first-level sub-domains – as many as you have (unlimited).
- Multi-Domain Wildcard – An SSL/TLS certificate with full functionality, can encrypt up to 250 different domains and all accompanying sub-domains simultaneously.
A quick word about Wildcard certificates. Wildcards are exceptionally versatile, they can encrypt an unlimited number of sub-domains, and are even capable of securing new sub-domains that are added after issuance. When generating a Wildcard, an asterisk (sometimes referred to as a wildcard character) is used at the sub-domain level you wish to encrypt. This denotes that any sub-domain at that URL level of the verified domain is validly associated with the certificate’s public/private key pair.
2- SSL/TLS Certificate Validation Level
After you figure out what surfaces you need to cover, it’s time to determine how much identity you want to assert. There are three levels of validation, these refer to the amount of vetting the Certificate Authority that issues your SSL/TLS certificate will put you and your website through.
The most basic level of validation is called Domain Validation. It takes just minutes to complete this validation and issue the certificate, but it provides the least identity information – authenticating just the server. DV SSL/TLS certificates are the most commonly used, but owing to their lack of identity, websites that use them receive neutral browser treatment.
Organization Validation provides more organizational information, which gives your site’s visitors a better idea as to who they are dealing with, provided they know where to look. OV SSL/TLS certificates require a moderate amount of vetting, however, they do not assert enough identity to avoid neutral browser treatment. OV SSL certificates can secure dedicated IP addresses, too. They are commonly used in Enterprise environments and on internal networks.
The most identity an SSL/TLS certificate can assert comes at the Extended Validation level. EV SSL/TLS certificates require in-depth vetting by the CA, but they assert enough identifying information that web browsers will give websites that deploy them unique treatment – displaying their verified Organizational name in the browser’s address bar.
One quick thing to consider with regard to validation levels and functionality is that EV SSL/TLS certificates are never sold with Wildcard functionality. This is owed to the open-ended nature of Wildcard certificates, which we discussed in the last section.
Picking Certificate Authorities and Pricing
Now that you know WHAT you need, let’s talk about where to acquire it from. Not just anyone can issue valid SSL/TLS certificates, and by valid we mean trusted. You have to go through a trusted certificate authority or CA. CAs are bound by strict industry requirements and subject to regular audits and scrutiny. The reason for this stems from the way Public Key Infrastructure works. PKI is the trust model that undergirds SSL/TLS, it’s why a user’s browser can verify the authenticity of, and trust a given SSL/TLS certificate.
While delving into PKI and roots is out of scope for this article, it is important to know that only trusted CAs can issue trusted certificates. This is why you can’t just issue your own and self-sign it. Browsers would have no way to trust it without manually adjusting their settings.
But what CA should you pick?
That depends on what you’re looking for.
For many simple websites that don’t need to assert much identity, a free DV SSL/TLS certificate from Let’s Encrypt (or other free CAs) is a good choice. It doesn’t cost anything and it’s sufficient for what you need.
Anything north of that, or if you’re not especially technically savvy, you should go with a commercial Certificate Authority like DigiCert, Sectigo, Entrust Datacard, etc.
But here’s the thing: you don’t get the best pricing buying direct from the CAs.
You get the best combination of pricing and selection by purchasing through an SSL Service offering SSL/TLS certificates from multiple CAs. The reason for this is simple, these SSL services purchase certificates from the CAs in bulk at much lower pricing than retail customers get. That lets them sell the certificates at deeply discounted rates, passing the savings to consumers.
In some cases, you can save as much as 85% off manufacturer's suggested retail price by going through an SSL service instead of buying direct.
Keep in mind, dedicated SSL services SPECIALIZE in SSL/TLS, they’re going to offer better customer support, they can help you install it and they know how to optimize your implementations to provide your website the best possible security.
Contrast that with free CAs (and even some commercial ones) where you’ve got to work through a ticket system or sift through old forum posts for crowdsourced support and the value is clear.
Granted, for some tech-savvy website owners, the support issue isn’t a problem. And there’s certainly nothing wrong with going the free route if you know how to support everything yourself.
But for other site owners, you’re paying less for the certificate itself and more for the support apparatus that’s been built around it. You also don’t have access to higher validation levels (OV/EV) or advanced functionality (Multi-Domain, Wildcards) with free SSL/TLS. You’ve got to get those from commercial CAs or SSL services.
So, paid or free? It comes down to how technically proficient you or your organization are, in addition to whether you want functionality and validation beyond single domain DV.
SSL/TLS Buyer’s Guide FAQ
Q1. Is Extended Validation worth it?
For many websites, an EV SSL/TLS certificate is more of an investment than an expense. There is no other way to assert maximum identity and get your website preferential browser treatment. When visitors arrive at a website and see the organization’s name displayed in the address bar it has a profound psychological effect. While that effect is difficult to quantify on paper, surveys consistently find that people feel better about visiting sites with EV than visiting sites without it.
On the internet, every little bit counts, so if you’re an organization that wants to assert identity on the web, EV SSL/TLS certificates are the best available method to do so.
Q2. You keep writing SSL/TLS, what does that mean?
SSL stands for Secure Sockets Layer, and it was the original version of the encryption protocol that we use to secure our connections to this day. We got all the way to SSL 3.0 before vulnerabilities forced the industry back to the drawing board, where Transport Layer Security (TLS) was designed to be SSL’s successor.
Today we are on TLS 1.3, SSL 3.0 has been almost entirely deprecated and by 2020 TLS 1.0 and 1.1 will be deprecated, too. While today’s internet relies almost exclusively on the TLS protocol, it’s still colloquially known as SSL.
Q3. What are SSL/TLS protocol versions?
This relates back to our last question, SSL and TLS are the two protocols that facilitate HTTPS connections, and much like with any other piece of technology, those protocols needs to be periodically updated as new vulnerabilities and attacks are discovered. When you see SSL 3.0 or TLS 1.2, that’s referring to a specific version of the SSL/TLS protocols.
Currently, best practice is to support TLS 1.2 and TLS 1.3, as all previous versions have been found to be vulnerable to some exploit or another.
Q4. What should I know about Cipher Suites?
A cipher suite is a collection of algorithms that will be used during the SSL/TLS encryption process. They typically include some sort of public key algorithm, a message authentication algorithm and a symmetric (block/stream) encryption algorithm.
Before you can make any determination on what Cipher suites to support, you need to know what your servers are capable of, which may mean updating your OpenSSL (or alternative SSL software) library to its most modern iteration. A word of advice, using Elliptic Curve Cryptography is preferable to RSA.
Q5. Are warranties important?
It’s nice to have a large warranty with any product, and the SSL/TLS industry provides some of the most generous warranties out there. They pay out in the event that the CA that issued your certificate ever encounters a problem that costs your organization money. Admittedly, this isn’t all that common, which is kind of an endorsement for SSL/TLS certificates in general, but also something we’d be remiss not to point out.
About the author: Patrick Nohe
Patrick Nohe started his career as a beat reporter and columnist for the Miami Herald. He also serves as Content Manager for The SSL Store™.
