Introduction to SSL

SSL and digital certificates are an essential building block of today’s information systems of all stripes.  Without digital certificates we wouldn’t have e-commerce, online shopping, mobile devices, secure logins to our online accounts, SaaS applications, public cloud, or virtually any of the IT systems that businesses depend on today.  Whether or not they’re visible to you, you depend on digital certificates for the communication, entertainment, and services you rely on every day.

Certificates are quite technically sophisticated, involving trust models, cryptography, industry standards, authentication requirements, and much more.  So sometimes they can be hard for someone without a PhD in computer science to make sense of.

This page will give you the fundamentals you need to understand (without getting into too much of the technical bits and bytes) what SSL is and how it affects you.

What Is SSL?

SSL, or Secure Sockets Layer, is the common name for the security protocol used between systems across the open internet.  The word can refer to the connections secured using this protocol or to the actual certificates that are issued and employed as the backbone of this system.

Note: Technically we don’t use SSL and haven’t for a long time.  Rather, the industry now bases its practices on TLS, or Transport Layer Security, which is a more recent and more secure cousin to the original SSL protocol.  However, the word SSL is still universally used to indicate this family of certificates, standards, and functionality.  We follow this convention and use the word SSL in all our content and communications here at GeoCerts.

The SSL protocol exists to enable trusted communications between computers across a network.  The most notable example of such a network is the open internet, but SSL is considered a best practice for infrastructure existing entirely inside a firewall as well.  SSL enables trusted communications by instilling machine-to-machine communications with two main qualities:

• Known authenticated identity
• Encrypted data flow

When we say known authenticated identity, what we mean is that the SSL protocol enables the machine that is receiving information (which we’ll call the client) to confirm the identity of the machine  that is providing that information (which we'll call the server).  For many use cases the machines on both sides of the transaction, the client and the server, will have their identities confirmed by SSL this way.

Encrypted data flow refers to the ability to encrypt the data moving both ways in the SSL-secured connection.  Encryption of data is a necessary part of maintaining private communications across the open internet, where otherwise it’s possible to spy on the content sent between machines.

What is a certificate?

SSL communications are enabled by certificates.  A certificate is a file that is installed on a server.  The certificate is specific to the URL or IP address for that server, and its presence on the machine enables the trust mechanisms and encryption that come with an SSL session.

We call it a certificate because it certifies the identity of the server to which is it assigned.  The certificate contains information about the identity of the owner of a URL or IP address that can be detected and used by the client machine to confirm that identity.

Certificates are protected by hashing algorithms to ensure they are genuine and tamper proof.  That means nobody can take an issued certificate and change it to claim to be another identity, and nobody can create a forgery of a certificate on a trusted public root.  Any certificate that doesn’t contain the same information it had when when the Certificate Authority minted it will be easily detected as broken by systems interacting with it, and it will be distrusted.

How does SSL authenticate identity?

The primary purpose of SSL certificates is to validate the identity of a server on a network.  To accomplish that, each certificate contains information about the entity to which it has been issued.  The precise information contained is a function of the validation level of the certificate.  SSL comes in three validation levels.

Domain Validation (DV):  Domain Validation is the lightest level of authentication available in an SSL certificate.  In the case of a DV certificate, the only thing that has been authenticated about the identity of the certificate holder is that this holder is genuinely in control of the domain name for which the certificate has been issued.

The main advantage of DV certificates is they can be issued in a matter of minutes.  DV certificates are recommended for use cases that require encryption or the presence of a certificate but that aren’t targets for phishing or fraud and where it isn’t important to inspire confidence in a web site visitor.

Organization Validation (OV):  Organization Validation is the middle level of authentication for SSL certificates.  An OV certificate makes a claim about the identity of the organization to whom the certificate has been issued and where this organization is located.  OV authentication is mostly left to the discretion of the individual Certificate Authority. Though they offer information about the organization’s identity, because authentication processes aren’t held and audited at a universally high level, popular browsers do not display the company name inside the address bar.

Extended Validation (EV):  Extended Validation is the highest level of SSL authentication.  The identity of an EV certificate holder is authenticated according to a standardized set of protocols believed to be highly trustworthy and proven through extended real-world use.  Because they have a high degree of trust for the information contained in these certificates, all popular browsers display the green trust indicator (the “green address bar”), including the name of the organization in the address bar to the left of the URL.  Most browsers give ready access to additional information such as the city in which the organization is located and the Certificate Authority that issued this certificate.

EV certificates are recommended for any application for which it is important to maximize transactions or build consumer confidence, any application involving high value information like Personally Identifiable Information (PII) or credit card numbers, or any application where compliance requirements include EV.  EV is the de facto standard for online businesses such as banks, stores, brokerages, tax sites, health care, and social media accounts.

How does SSL enable encryption?

It is widely understood that SSL certificates are required to enable encrypted online sessions, but most people don’t realize that the certificates themselves do not actually do the encryption.  Rather, the encryption and decryption are performed respectively by the machine sending the information and the machine receiving it. However, the way the connection protocols are set up, these client and server machines won’t use encrypted transmissions at all unless an SSL certificate is in place.

The reason that an SSL certificate is needed to enable encryption is that without knowledge of the other party’s identity, the encryption itself is no protection against information theft.  To understand this the reason for this protocol, consider an analogy.

Let’s suppose you have to transport an extremely valuable item across town, a painting worth millions of dollars.  When your painting is moving around on the streets, you want to ensure it doesn’t get stolen. Maybe you hire an armored car to pick up the painting, transport it to an address you have specified, and give it to the recipient there.  If the armored car crew does its job correctly your painting arrives safely without incident.

In this analogy the armored car is like encryption.  Encryption is an impenetrable defense so that nobody can get your information while it’s wandering in the uncontrolled zone of the internet.  But in the analogy you also specified a specific place where the painting needed to be delivered. The armored truck didn’t just go out and hand the painting to anyone who asked for it.  Rather, it only delivered the painting to the appropriate business located in the appropriate place. Authentication is like the delivery address in this analogy. Authentication ensures that the party receiving your valuable information is indeed the party you expect it to be.

The reason that SSL certificates (with their promise of authenticated identity) are required for encryption to take place is that otherwise it’s like sending out the armored car without instructions for where to deliver your million dollar painting.   All that protection doesn’t really matter if the valuables are handed to the wrong person. To enforce this same pair of protections, standard IT infrastructure components will not engage in encrypted sessions unless a trusted SSL certificate is in place.

How do browsers communicate online trust?

When users visit web sites, it’s important that they have the facts they need to make judgements about what kind of information it is safe to share on these sites.  Browser manufacturers recognize this need and have incorporated a set of safety indicators into the interfaces of their software.

The most basic of these is what we call the padlock.  In the current versions of all popular browsers the padlock occurs up in the address bar, where the URL of the visited site displays.

The padlock indicates simply that an encrypted SSL session is in place right now.  This indicator tells a knowledgeable user that any information sent to or received from this site will be encrypted and cannot be spied upon by malicious software lurking on the internet.  However, the presence of the padlock by itself tells the user nothing about the authentic identity of the visited site.

To communicate a site’s identity, browsers employ the green address bar.  The green address bar occurs only when an Extended Validation SSL certificate is in place.  Because the authentication of EV certificates is trusted, browsers will include the name of the company and usually additional information such as the company’s location and the Certification Authority (CA) who issued the certificate (e.g., GeoTrust).

Green address bars always include a lock icon, as every SSL session enables encryption.

Finally, browsers contain negative trust signals to warn of unsafe pages.  Starting April 2018 Google Chrome actually contains a Not Secure signal for any page that does NOT use an SSL certificate.

Just as positive trust indicators communicate to visitors that a site is safe and lead to increased involvement, longer site visits, and higher transaction rates, negative trust indicators have the opposite effect.

How many domains can an SSL certificate secure?

While each specific domain must be protected by an SSL certificate for encryption and browser trust indicators to activate, it is possible to obtain certificates that will take care of more than one domain.  With regards to their domain coverage, SSL certificates fall into three types.

Basic SSL certificates each apply to a single specific domain name or subdomain.  A basic certificate could secure domain.com or login.domain.com but not both.  Neither could a basic certificate secure both domain.com and example.com. To secure multiple domains or subdomains with a basic SSL certificate, you need a number of certificates equal to the number of domains and subdomains being secured.

It is standard practice for CAs issuing certificates for www addresses to include the basic address in the same certificate.  That means a basic certificate for www.domain.com would also work for domain.com. All basic certificates sold by GeoCerts work this way.

Basic certificates are available at Domain Validation, Organization Validation, and Extended Validation authentication levels.

Because each certificate is entirely separate, using only basic certificates is considered the most secure SSL certificate strategy, and it is common practice for highly sensitive systems and information.  However, using only basic certificates can require more administration, and for complex environments certificate management software is considered a must with basic certificates.

Wildcard SSL certificates can secure any number of subdomains under a main, base domain name.  For example a wildcard certificate for domain.com would successfully secure:

• www.domain.com
• login.domain.com
• cart.domain.com
• ftp.domain.com

Or any other subdomain of domain.com.  In this scenario the wildcard would also protect the base domain name on its own, so domain.com would also be secured.

A wildcard can also be applied to a single subdomain, at which point it would be a wildcard for sub-subdomains of that domain name.  So a wildcard certificate for shop.domain.com would apply to:

• a.shop.domain.com
• b.shop.domain.com

And so on.

A single wildcard certificate cannot apply to more than one domain.  So in the first example, a wildcard assigned to domain.com could not secure any subdomain of example.com.  Likewise the wildcard in the shop.domain.com example above would not work for checkout.domain.com.

Wildcards can be considerably more convenient to obtain and manage for environments with multiple subdomains than individual basic certificates.  Wildcards also give you the ability to create new subdomains after the certificate is issued and still use the certificate to secure them.

Wildcard certificates are available at DV and OV authentication levels.  However, established standards do not allow issuance of Extended Validation wildcard certificates, so for public facing websites that require user trust (such as an ecommerce site with www., shop., and checkout. subdomains), we recommend considering an EV multi-domain certificate.

Multi-domain or SAN certificates make it possible for a single certificate to secure up to 100 specific domain names. Unlike in the wildcard example above, a multi-domain certificate can secure any set of domain names using the same certificate.  For example, a single multi-domain certificate could secure:

• www.domain.com
• ftp.domain.net
• shop.domain.com
• a.shop.domain.mobi
• www.example.com
• login.example.com

Multi-domain certificates are available at DV, OV, and EV authentication levels.  Each additional domain secured in a multi-domain certificate is called a SAN or Subject Alternative Name.  Certificates with Subject Alternative Names are sometimes referred to as SAN certificates instead of multi-domain certificates, but both terms communicate the same thing.

Multi-domain certificates can be more convenient than basic certificates for complex environments.  Since multiple domains are secured by a single certificate, they are not recommended for highly sensitive environments requiring the highest security.  Because multi-domain certificates are available in Extended Validation form, they are a good choice for user-facing business sites containing multiple subdomains such as online retail sites.

Why do certificates expire?

Each certificate has a certain expiration date, and from that date forward systems will no longer trust the certificate.  This function forces certificates to be current within a certain time period. Certificate expiration adds to online trust by preventing the employed cryptographic techniques from falling behind criminals’ knowledge of how to defeat them.  It also limits the potential for a mismatch between a certificate’s identity and its actual user in the event of ownership changes such as company sale, divestiture, bankruptcy, and the like.

The potential duration of a certificate varies depending on what it’s used for and what regulations or standards cover its use.  SSL certificates at present are limited to 27 months duration, which allows public CAs to issue two-year certificates up to 90 days prior to the expiration of any certificates they are replacing.

What’s next for SSL?

The SSL/TLS standard has been steadily evolving since the first SSL certificate was issued in 1995.  In that span of time certificate offerings have expanded to include DV (ultra-fast issuance), EV (highest trust), wildcard, multi-domain/SAN, and multi-year.  They now come with trust seals, added web security bundles, and a whole host of certificate management, discovery, and renewal features.

All these expansions came about because online applications, IT infrastructure, and device usage changed.  So certificates adjusted to meet the new needs. What will digital certificates look like in five years or ten years?  Nobody knows. But we do have a high degree of confidence that the trusted identity of a device, site, or business will continue to be as important as ever, and that certificates will continue to be the identity backbone that makes online connections possible.