TLS certificates have never been more important: starting this month, Chrome will begin explicitly warning users if a site lacks a valid TLS certificate and is not served over HTTPS. Such a warning can be repelling and have significant impact on your business, whereas securing traffic helps you build trust with your users with minimal effort.

What is TLS?

Nevertheless, if you are just starting to dig in, the argument is often confusing and plenty of common misunderstandings.

Historically, HTTP (website) traffic was sent in plain text, allowing eavesdroppers the ability to inspect the traffic between client browsers and web servers, capturing login credentials, personal information and any industrial secrets passing through the channel.

Over time, websites began to adopt HTTPS, allowing the client browser and web server to establish a secure, encrypted communication channel after making an initial handshake on the client’s request.

In order to establish the integrity of the site, the client browser references trusted certificate authorities to verify the web server. Historically, these certificate authorities required site owners to purchase these certificates at potentially significant cost, and the resulting installation process could be time-consuming an error-prone.

More recently, the Let’s Encrypt project began offering free certificates through an easy-to-use programmatic interface that makes the initial generation and maintenance of these certificates much easier. Today, it’s entirely free for sites of any size to acquire certificates allowing HTTPS communication with all web visitors.

In this article we want to give you an high overview of TLS/SSL, the tools and the processes involved to secure a front-facing application served to the internet.

TLS vs SSL: is there any difference?

TLS and SSL are two cryptographic protocols between many. Both are used to secure web connections, giving the S that makes normal HTTP special: that is, HTTPS.

SSL has been the mainstream protocol for a while, and it has been superseded by TLS, which is now the standard protocol to use. Nevertheless the term SSL is still widely used and favoured in common language.

What is a TLS Certificate?

TLS certificate, or simply a certificate, is a digital certificate that protects and encrypts all data exchange between a client and a service. It’s important because:

  • It protects your user’s privacy by encrypting all data exchanged between their browser and your website, API and other public-facing properties.
  • It authenticates the identify of the server and its ownership.

Although we often speak about SSL certificates or TLS certificates it is important to understand that the encryption protocol and the certificate are two different things, one not dependent on the other. Exactly as in the case of SSL vs TLS, common language tends to associate the two.

So how do you go about enabling HTTPS on your internet facing application and avoid Google Chrome showing your site as insecure? You have to get a certificate from a Certificate Authority.

What is a Certificate Authority

A Certificate Authority (CA) is a company or organization, usually commercial, entitled to issue certificates. Operating systems, browsers, and any kind of devices run memberships programs establishing a wide set of criteria a CA has to fulfill to become a member.
After passing membership, the CA can issue certificates trusted by those devices by verifying the identity of the applicants: you have to prove your identity and your website ownership to the CA to get your certificate.

Some of the key information contained in a certificate:

  • The name of the certificate holder
  • The serial number and expiration date of the certificate
  • A copy of the certificate holders public key
  • The digital signature of the certification authority

How do certificates work

The entire encryption process inherent to certificates, and the symmetric cryptography of the TLS protocol, are subjects worthy of entire books. Here is a very high level overview of how the process works:

  • Browsers have a register of trusted CA and establish if a certificate can be trusted by what is called a chain of trust.
  • CA trust themselves each other: you can trust a certificate because is trusted by other CA’s and so on.
  • At the very top of this chain, a root certificate for every main CA is used to “sign” other certificates, that inherit the trustworthiness of the root certificate.

Root certificate and chain of trust

When your clients connect with their browsers to your server, a small dance called a Handshake starts. During the Handshake, your certificate is sent to the browser, and the browser verifies it can be trusted against the certificates it’s aware of. Moreover, the public keys of the server and browser are exchanged. Both the browser and the server have a keypair, consisting of a public and a private key. To keep it simple, bear in mind that the public key encrypts, and the private key decrypts. Here’s a simplistic view of how the Handshake looks like:

  • The certificate sent by your server contains the server’s public key. If the certificate is trusted the key can be trusted.
  • The browser then uses this key to encrypt its own public key and sends it back to the server.
  • Now the server is able to decrypt the message with its private key and get the public key of the browser keeping it secret.
  • The server can now use the public key of the browser to encrypt it’s response to the browser.
  • Your connection is now secure and communication between browser and server is encrypted!

There are many types of certificates available, the most common being single domain certificates and wildcard certificates. Wildcard certificates are especially convenient, allowing you to protect a domain and unlimited number of subdomains.

The truth is that the process of obtaining and installing certificates has been quite cumbersome and time consuming in the past. This was particularly true and challenging on complex architectures involving multiple servers and domains. That is, until the rise of Let’s Encrypt.

Let’s Encrypt and the ACME protocol

In recent times Let’s Encrypt has become the de facto standard CA. The label on the tin says that

Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit.

It is free, can be easily automated, uses the most secure best practices, and is backed by a strong community including all the major browsers and some of the biggest IT companies in the world. It’s non profit and uses an open protocol to automate the deployment of certificates: ACME.

What is the ACME Protocol?

One of the biggest advantages of Let’s Encrypt is the automation.

Certificates need to be requested, installed, and maintained: to grant the underlying informations are up to date, they expire and have to be renewed periodically.

The Automated Certificate Management Environment (ACME) is a protocol created by the ISRG (the non profit organization behind Let’s Encrypt) that implements automated interactions between CA and web servers, removing all the burden of getting and maintaining certificates.

To prove the ownership of the server requesting the certificate, ACME sends a pending authorization containing a challenge to be solved in order to complete the authorization.

A challenge is a task that should be actionable and completed only by someone who controls the server. Three main challenges are available in the ACME protocol:

  • HTTP-01 challenge, requiring the presence of a specified file in a specified location on a web server accessible on port 80
  • TLS-SNI-01 challenge, requiring a special temporary certificate on a web server accessible on port 443
  • DNS-01 challenge, requiring to set up a specified DNS record

The DNS-01 challenge is the one considered most secure, and the only challenge today allowing you to get wildcard certificates via Let’s Encrypt.

ACME v1 vs ACME v2

In its first version, the ACME protocol supported only certificates for single domains. In March 2018, ACME has been upgraded to ACMEv2, allowing automated deployment of wildcard certificates using the DNS-01 challenge. Currently, the v2 version of the ACME API is not backwards compatible with the v1 version.

How does the ACMEv2 DNS-01 challenge work

At the simplistic level, the DNS-01 challenge works like this:

  1. The client (the server that needs the certificate) talks to the Let’s Encrypt ACME server and obtains a token.
  2. The token needs to be placed in a specific TXT record in your DNS.
  3. The client then requests the ACME server to validate the token
  4. The ACME server validates the token and issues the certificate
  5. The client can retrieve and install the certificate.

How to automate Let’s Encrypt ACMEv2 certificates

In practice, automating certificate deployments can be done with multiple tools. Let’s review three of them:

Certbot

Certbot is a stand-alone client backed by the Electronic Frontier Foundation. It’s able to automatically fetch and install Let’s Encrypt certificates. It works with several web servers like Apache or Nginx, and offers an easy configuration prompt.

Caddy

Caddy is a great open source, multi-platform web server. It uses the most modern best practices out of the box, like HTTP/2 by default and Automatic HTTPS via Let’s encrypt certificates. It hence allows you to serve your websites and applications AND get the certificate you need.

Træfik

Træfik is a more advanced solution ideal for deploying complex cloud-native architectures. It’s an HTTP reverse proxy and load balancer that integrates with the most common infrastructure components like Docker, Kubernetes, etcd, Rancher, etc. It’s able to automatically expose the microservices composing your application to the internet, and integrates perfectly your current automation workflow. Like Caddy, Træfik has the ability to get and deploy Let’s Encrypt certificates.

Lego and Exoscale’s DNS service: automate TLS certificates for your application.

Both Caddy and Træfik are based upon the Lego library, an efficient Go library to interact with the ACME protocol, and which supports the Exoscale API. By using them, or any other Lego-based client or tool, you can easily deploy single domain or wildcard certificates for your application. Lego in fact supports the ACMEv2 protocol, and the entire DNS-01 challenge is transparently automated out of the box using our DNS service API.

A Quick checklist to make the switch from HTTP to HTTPS

If you have a public website or front-facing application served to the internet, and requiring high availability and good search results, here’s some things to keep in mind when switching from HTTP to HTTPS:

1. Migrate from HTTP to HTTPS during low-traffic days

HTTPS greatly affects Google ranking: implementing a proper HTTPS setup will not only hide browsers’ insecure warnings from your visitors, it will also help your visibility in search engine results. Migrating at low-traffic times minimizes disturbance for your visitors and allows Googlebot to use more of your server’s resources to explore your website in-depth.

Make sure you update the CSS, images and JavaScript files. If you currently use relative URLs on your website, you shouldn’t have to make any changes to your internal links.

3.Check that your CDN supports TLS to avoid issues.

If you have a CDN of course…

If you use canonical links on your website or application, make sure that they properly redirect all traffic coming from HTTP to the HTTPS version.

5.Use OCSP stapling

Avoid taking a performance hit due to certificate validation checks by using OCSP stapling. It’s a feature that allows the browser to download a copy of the certificate authority’s response when checking the certificate. This means that the next time, it will check the validity based on the copy on the server instead of checking with the certification authority.

6.Make sure the browser requests the HTTPS version

Ensure your web servers uses the HTTP Strict Transport Security Header (HSTS) feature to enforce the use of the HTTPS request. This is a quick way to make sure that browsers do not request the HTTP version.

7.Redirect URLs

Make sure you redirect traffic automatically redirect to the HTTPS version. Favour 301 redirects than any other type of redirect.

How to test if the TLS certificate is valid once installed?

You can use Qualys SSL to test if your certificate is working properly. It will give you a score and let you quickly assess the situation.