Skip to content
ServerPilot

How SSL works

Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are protocols used for securing the communication between web browsers and servers. The term “SSL” is commonly used to refer to both SSL and TLS even though the original SSL protocols were phased out and replaced with TLS.

Purpose of SSL

The purpose of SSL is to establish a secure communication channel between a client, such as your web browser, and a server. This secure communication channel ensures two things:

  1. Your web browser can trust it is communicating with the web server it thinks it is.
  2. All communication between your web browser and the server is encrypted, so nobody else can read the communication.

SSL certificates

When your browser initiates communication with a server over SSL, the first step is for your browser to make sure it’s talking to the correct server. This step is critically important as it would defeat the entire purpose of SSL if your browser was having a private conversation with the wrong server or even an attacker.

Solving this problem of establishing trust is the purpose of SSL certificates. SSL certificates provide a way for your browser to know that a server really is who it says it is.

When your browser begins talking to a server over SSL, the first thing the server does is send your browser an SSL certificate that is cryptographically signed (cannot be forged) by an organization your browser already trusts. This certificate essentially says, “Until July 2017, you can trust this server is both example.com and www.example.com.”

So, who are these organizations your browser already trusts? The answer is your browser or operating system comes with a built-in set of root certificates: SSL certificates belonging to well-known certificate authorities (CAs) your browser will always trust.

Putting this all together, when your browser receives an SSL certificate from a server, it does the following checks before considering the certificate valid:

  • Is the certificate signed by one of the root certificates the browser trusts?
  • Is the certificate trusted for the domain name that the browser is requesting?
  • Is the certificate not expired?

If the certificate looks good to the browser, the browser is now ready to establish an encrypted connection with the server. Using public-key cryptography and the server’s public key listed in the SSL certificate, your browser can now create a secure connection with the server over an untrusted network.

Certificate Authorities (CAs)

As mentioned earlier, your browser uses a chain of trust to know whether to trust an SSL certificate presented by a server. Your browser or operating system comes with a set of certificates that are the root of this chain of trust. The companies these root certificates belong to have a huge amount of responsibility: they need to make sure anyone who asks them to sign an SSL certificate for a particular domain name is really the owner of that domain.

These companies that own the root certificates your browser trusts are called certificate authorities (CAs). To get an SSL certificate for your domain signed by one of these CAs, you need to prove to the CA that you are the owner of your domain. There are a few ways to prove you own a domain, and some CAs now even offer APIs that can be used to automate the steps involved with proving ownership and obtaining certificates.

Ensuring you own a domain name before issuing an SSL certificate is a responsibility the CAs must take very seriously. If a CA doesn’t do proper checking, it can put everyone online at risk since a malicious party could obtain SSL certificates for any domain and these certificates would be trusted by all browsers. If a CA doesn’t do proper verification or has other security problems, browsers and operating systems may remove their root certificate, which can essentially put the CA out of business.

CAA records

Certificate Authority Authorization (CAA) DNS records allow you to restrict which Certificate Authorities can issue SSL certificates for your domains.

As ServerPilot’s AutoSSL feature issues certificates through the Let’s Encrypt Certificate Authority, you can optionally choose to create an issue CAA record with authority granted to letsencrypt.org so that only Let’s Encrypt will be able to issue SSL certificates for your domain.

If you create a CAA record and later forget you created it when trying to issue a certificate from a different Certificate Authority, you won’t be able to issue your new SSL certificate. In general, you should only create a CAA record if you’re experienced with DNS and understand how CAA records work.