Surviving in the Age of NPCs

If Reality is a Simulation, Then

Although Netscape originally invented SSL in the mid-90's, it did not become compulsory for every website to install an SSL/TLS certificate until the Summer of 2018 when Google began marking unencrypted sites "Not Secure". While Google - with its search engine, Chrome browser and Android OS - can redefine the Internet unilaterally, it was not alone on this mandate. Apple, Microsoft, Mozilla and the other major stakeholders in the tech industry have all made a concerted decision to mandate SSL/TLS certificates and HTTPS.

The reason for that is simple: without SSL/TLS and the ability to connect securely via HTTPS, all communication between websites and their visitors would be exchanged in plaintext and easily readable by a third party. The only downside to this recent push for universal encryption is that it has forced an influx of new customers into an unfamiliar market, one that does very little to make itself less confusing to the average website or business owner.

Presented in this paper is a comprehensive, top-level guide to all things SSL/TLS. I'll lay the foundation by covering some basic concepts like encryption, HTTPS and the nature of Internet connections. Hopefully, by the end, you'll feel confdent about selecting, purchasing and implementing a TLS certificate.

Foundational Elements

Let's begin by discussing the concept that resides at the heart of all of this: encryption.

Encryption, in its most straightforward iteration, it little more than the scrambling of data - using a pre-defined cipher or key - so that it is rendered unreadable by anyone except another party with the same private key.

Throughout history, private key encryption has been the most common model used. In private key encryption, both parties must possess or at least exchange a private key that can be used to both encrypt and decrypt information. Early on, most of the ciphers underpinning these cryptosystems were primitive, relying on simple substitutions or replacing common words with characters. But over time, ciphers became more influenced by mathematics and grew in complexity. For example, in the mid-1600's in France, King Louis XIV's cryptographer created a cipher that was so well-designed that it wasn't broken until 250 years later, and only then partially. To this day there are hundreds of years' worth of records in the French archives that may never be deciphered.

But whereas historically encryption has been a means for being covert or clandestine, the advent of the Internet has taken the concept more mainstream. The Internet is ubiquitous, and it handles a range of critical functions. Every day billions of people use it to access and send sensitive information, manage their finances, transact with businesses - you name it.

The problem is that the early Internet wasn't wholly designed to scale to what it has become. Early on, in the days when academia and the US government were first developing networking protocols, the Internet was only seen as a mechanism for the free exchange of information between the government and academic institutions. At that point, commercial activity was illegal online - eCommerce wasn't a word that had even been invented yet, and a web site was more of a geographical notion. So, when HTTP (the HyperText Transfer Protocol) was first introducted in 1992, the fact that the connections it formed exchanged data in plaintext wasn't a disqualifying problem.

Things are very different today. The information being exchanged online isn't just acdemic research or freely-available information, in many cases it's personally identifiable information and sensitive data that can cost people money or even, in some regions, their lives. This called for a more secure approach, and the answer was encryption.

The Issue of Exchanging Keys

One problem that has historically plagued even the best cryptosystems continues to persist to this day. What we discussed earlier, and what has traditionally been the standard for encryption, is private key encryption. This is also called symmetric encryption, or two-way encryption - with private keys handling both the encryption and decryption functions needed to communicate. For private key encryption to work the private key must be transferred between parties, or both parties need to possess their own copy. Either way, private key security was critical to the integrity of cryptosystems and, as you can no doubt summise, key exchange is a problem as old as encryption itself.

Then, in the 1970's a new form of encryption was conceptualized and brought to life: public key encryption.

Whereas private key encryption is a two-way function, symmetric, with the private key capable of both encrypting and decrypting data, public key encryption is asymmetric; one way. Rather than a single private key, there is a public-private key pair. The public key handles encryption and is, as the name implies, publicly available, while the private key, which handles decryption, is kept secret by its owner. Using the public key, one can encrypt a piece of data and send it to they key's owner, where only they will be able to decrypt it.

Great, but how is that useful?

Well, one-way encryption isn't ideal for encrypting Internet connections; it's difficult to communicate when one party can only encrypt, and the other can only decrypt. No, to encrypt an Internet connection, you would need to use symmetric, private key encryption.

But how do you exchange keys? Especially online?

Public key encryption. So, distilled down to its very essence, this is what SSL/TLS is all about: secure key exchange.

This is where we'll tie all these concepts together. If you want your communication with a website to be private, then you need to connect to it securely. If you want to connect securely with that website, then you need to exchange symmetric private keys so you can use them to communicate. SSL/TLS (and PKI in general) is just a fancy mechanism for creating and exchanging that session key. Using SSL/TLS, you can authenticate the server or organisation you're about to connect with and ensure that you securely exchange the private keys you'll use to encrypt your communication with the intended party. Unfortunately, SSL/TLS and PKI have a lot of terminology and moving parts that can easily confuse people, but those belie the fact that when you strip away all the mathematics and technical jargon, this is just an elegant modern technological solution to the same age-old problem of key exchange.

Key Terminology

Before we go any further, let's go over a couple of other key terms. I already introduced HTTP, which has been the backbone of the Internet for decades. Bus as we've discussed, the Internet evolved into something much different than it was when HTTP was first published in 1991. A more secure protocol was needed. Thus, HTTPS.

HTTPS, which is sometimes referred to as HTTP over TLS, uses encryption to render the data being ecxchanged during a connection unreadable to anyone but the intended party. This is especially important when you consider the nature of a modern Internet connection, where connections are routed through dozens of devices on their way to their final destination. If any one point in the connection chain has a packet sniffer or some listener installed then your data can be stolen during transmission and, in some cases, the connection itself can be manipulated. This is called a man-in-the-middle attack. There is a lot more surface area to cover with modern connections than the vast majority of people realise, which is why having the data encrypted during transmission is critical. You have no idea who could be listening, or how trivially easy it is to do so.

An HTTP connection is made via port 80. For our purposes, you can think of ports as constructs that indicate a network service or protocol. A standard website being served via HTTP uses port 80. HTTPS typically uses port 443. When a website installs a certificate, it can redirect its HTTP pages to HTTPS ones, and users' browsers will attempt to connect securely via port 443, pending authentication.

Unfortunately, the terms SSL/TLS, HTTPS, PKI and encryption all get thrown around a lot, sometimes even used interchangeably, so to clear up any lingering confusion, here's a quick guide:

SSL/TLS works in conjunction to enable HTTPS connections, and PKI refers to the entire thing when you "zoom out". If you're still unclear on any of this, don't worry.

Building a Public Key Infrastructure

Now that I've laid a solid foundation let's zoom out and look at the architecture employed by the trust model at the heart of SSL/TLS.

When you arrive at a website, the first thing your browser does is verifies the authenticity of the SSL/TLS certificate that the site presents it with. I'll get to what happens after that authentication takes place in a couple of sections, but we're going to start by discussing the trust model that makes all this possible, and the best way to do this is to pose a question:

How does my computer know whether to trust a given SSL/TLS certificate?

In order to answer that, we'll need to discuss PKI and the various elements that mnake it work. I'll start with Certificate Authorities and Root programs.

Certificate Authorities

A Certificate Authority is an organisation that complies with a set of predetermined standards in return for the ability to issue trusted digital certificates. There are dozens of CA's, both free and commercial, that can issue trusted certificates. They all must abide by a set of standards that has been debated and legislated through the CA/Browser Forum, which acts as the regulatory body for the TLS industry. These standards outline things like:

These guidelines have been set forth by the browsers, in conjunction with the CA's. The browsers play a unique role in the TLS ecosystem as nobody can get anywhere on the Internet without their Web browser. As such, it's the browser that will be receiving and validating the digital TLS certificate and then exchanging keys with the server.

So, given their paramount role, they bear considerable influence. In addition to this, it's important to keep in mind that browsers have been designed to be as skeptical as possible. To trust nothing. This is the best way to keep their users safe. So, if a browser is going to trust a digital certificate - which can potentially be misused to the detrement of the user - it needs certain assurances that whoever issued this certificate did their due dilligence.

This is the role and responsibility of the Certificate Authorities, and the browser vendors don't abide mistakes, either. There is a literal graveyard of former CA's that have run afoul of the browsers and been put out to pasture.

When a Certificate Authority has demonstrated its compliance with the CAB Forum baseline requirement and has passed all the requisite audits and reviews, it can petition the various root programs to have its Root certificates added.

Root Programs

A Root program - the major ones are run by Apple, Microsoft, Google and Mozilla - is the apparatus that oversees and facilitates root stores (sometimes called trust stores), which are collections of Root CA certificates that reside on a user's system. Once again, these roots are incredibly valuable and incredibly dangerous - they can issue trusted digital certificates, after all - so security is of the utmost concern.

As such, CA's almost never issue directly from the Root CA certificates themselves. Instead, they spin up intermediate root certificates and use those to issue end user of leaf certificates. They can also hand those roots off to sub-CA's, which are Certificate Authorities that don't have their dedicated roots but can still issue cross-signed certificates off their intermediates.

So, let's put this all together. When a website wants to have a TLS certificate issued, it generates something called a Certificate Signing Request (CSR) on the server it's hosted on. Contained in this request are all the details the website wants to be included on the certificate. As you'll see soon, the amount of information can vary from complete business details to a simple server identity, but once the CSR is completed, it's sent along to the Certificate Authority for issaunce.

Before issuing the certificate, the CA will have to do its CA/Browser Forum-mandated due dilligence and validate that the information contained in the CSR is accurate. Once that has been verified, it signs the certificate with its private key and sends it back to the website owner for installation.

Certificate Chaining

After the TLS certificate has been installed, any time someone visits the website the server hosting it will present the user's browser with the certificate. The browser is going to look at the digital signature on the certificate, the one that was made by the trusted certificate authority, which vouches for the fact that all information contained in the certificate is accurate.

This is where the term certificate chaining comes into play.

The browser is going to read the digital signature and move up a link on the chain - next, it will check the digital signature on the intermediate certificate whose private key was used to sign the leaf certificate. It's going to continue following signatures until either the certificate chain ends at ones of thge trusted roots in its root store, or until the chain terminates without reaching a root, in which case a browser error will appear, and the connection will fail. This is why you can't issue and self-sign your certificates.

The browsers will only trust SSL/TLS certificates that they can chain back to their root source (meaning that they were issued by a trusted entity). Certificate Authorities are required to abide by specific standards to maintain their trustworthiness, and even then the browsers are loath to trust them.

Browsers have no such assurances about self-signed certificates, which is why they should only be deployed on internal networks, behind firewalls, and in test environments.

SSL/TLS Certificate Types and Functionality

Before we look at SSL/TLS in motion, let's talk about certificates and the various iterations that are available. TLS certificates are what facilitate the TLS protocol and help dictate the terms of the encrypted HTTPS connections that a website makes. Earlier I mentioned that installing a TLS certificate allows you to configure your website to make HTTPS connections via port 443. It also acts as a sort of name badge for the site or server you're interacting with. Going back to the idea that at its heart, SSL/TLS and PKI are all exquisite forms of secure key exchange, the SSL/TLS certificate helps notify the browser of who it's sending the session key to - who the party at the other end of the connection is. And when you break down the various iterations of SSL/TLS certificates, that's a pertinent thing to keep in mind. Certificates vary regarding functionality and validation level. Or to put it another way, they vary based on:

Answering those two questions wll give you a pretty clear indication of what type of certificate you need.

How Many Identities to Assert

There are three different levels of validation available with SSL/TLS certificates, and they vary based on how much identity information your website wants to assert.

Domain Validation SSL certificates are by far the most popular, owing to their price and the speed with which they can be issued. A DV SSL/TLS certificate requires a simple domain control check, that can be accomplished several different ways, but as soon as it is the certificate can be issued/ You can also get 30-day and 90-day versions of these for free, which has undoubtedly added to their market share.

The downside is that DV SSL certificates assert minimal identity. And given that almost half of all phishing websites now have a DV SSL certificate installed on them, they don't necessarily buy you much in the way of trust.

Organisation Validation SSL certificates are the original type of SSL/TLS certificate. They're also the only kind of SSL certificate that can secure an IP address following a 2016 decision by the CAB Forum to invalidate all intranet SSL certificates. Organisational Validation requires a light business vetting and can typically be issued within a day or two - sometimes faster. OV SSL certificates assert some organisational information, but an Internet user would need to click the padlock icon and look for it. These days you see a lot of OV SSL certificates deployed on large enterprise and corporate networks, for connections made behind firewalls for instance.

Because neither DV or OV SSL certificates assert sufficient identity to satisfy most browsers they receive neutral treatment.

Extended Validation SSL certificates are by far the most controversial, as some in the tech community feel more needs to be done to strengthen the validation they depend on. But, EV SSL asserts maximum identity. To complete extended validation, the Certificate Authority puts the organisation through a rigorous vetting process that can take upwards of a week in some cases, but the benefit is undeniable: because it asserts sufficient identity a website with an EV SSL certificate receives unique browser treatment, including having its name showcased in the browser address bar. There is no other way to accomplish this, and you can't fake one - the EV address bar is one of the most potent visual indicators we have today.

What Endpoints to Assert Identity On

The other way that SSL/TLS certificates vary is regarding functionality. Websites have evolved quite a bit since the early days on the Internet, with various sites deploying sites in different ways. Some have multiple domains for different company verticals; others use sub-domains for multiple functions and web applications. Some use both. No matter what the context is, there is an SSL/TLS certificate that can help to secure it.

Single Domain

The primary website and the standard SSL certificate are just a signle domain. Most modern SSL/TLS certificates will secure both the WWW and non-WWW versions of that domain, but it is limited to a single domain.

Multi-Domain

Multi-Domain certificates, or Unified Communication Certificates in the case of Microsoft Exchange and Office Communications servers, also exist to give organisations the ability to encrypt multiple domains with a single certificate. This can be an attractive option as it saves money and it makes managing the certificates a lot simpler.

Multi-Domain and UCC certificates use SAN, the Subject Access Alternative Name field in the CSR, the add additional domains to the certificate. Most CA's allow up to 250 different SAN's on a single certificate, and most Multi-Domain certificates come with 2-4 complimentary SAN's with the rest available for purchase as needed.

Wildcard SSL Certificates

Wildcard SSL certificates are an extremely useful certificate type because they can encrypt an unlimited number of sub-domains at the same level as the URL. For instance, if you have a website that uses sub-domains like:

You can encrypt them all with the same Wildcard certificate by using an asterisk in the FQDN field of your CSR: *.website.com. Now any sub-domain, even ones you haven't added yet, can be secured with that certificate.