Securing your self-hosted website with Let’s Encrypt, part 2: HTTPS and certificate authorities

In part 1, we looked at how HTTP and HTTPS are and how they work together to protect users and servers from crackers and other parties interested in tampering and spying the data transmitted over HTTP. We also concluded that moving to HTTPS is the natural evolution, given the abundance and ease of attacks against unencrypted connections. Remember also: HTTPS will guarantee privacy and integrity, but it will not hide the fact that a connection is taking place between a server and another machine. Ports and IP addresses are still exposed.

In this part we will look at how HTTPS works in practice, what role certificate authorities play and where Let’s Encrypt can make things easier.

HTTPS in practice

When a browser connects to an HTTPS server for the first time, an elaborate dance called the “SSL HandShake” is performed. Roughly:

  • Protocol and cipher negotiation
    • Browser and server need to agree on what protocol and cipher to use for the transmission
    • The browser sends the server a list of the protocols and ciphers it can use
    • The server sends the browser a list of the protocols and ciphers it can use, plus its digital certificate
  • Certificate validation:
    • the browser looks at the certificate and determines if it’s a valid certificate that it can trust
      • is it issued by a certificate authority we know about? (browsers have a list of trusted authorities, the root authorities, built in)
      • if it’s not, who issued this? Check if they are a valid certificate authority
      • repeat this until we find if there’s a root authority we trust–this is called following the chain of trust
    • if the certificate is invalid for any reason (expired, not trusted, etc) the browser shows an error message and refuses to continue unless the user explicitly requests so
    • alternatively, if all goes well, then the server and the browser go to the next step
  • And finally… transmission!
    • The server initiates an HTTPS session using the parameters that were determined during the protocol and cipher negotiation, and the key data in the certificate
    • Now all data sent between the browser and the server is encrypted. Only the browser and the server have the ‘secrets’ to decrypt it.
    • If someone intercepts these packets, they will be unable to figure out the content, other than they have been sent between these two machines

An example of when things go wrong could be this, in which I was using a test certificate that was not validated by a root authority:

Image of

Firefox showed me this mega error message instead of the website I expected to find. If I click on “Add exception” the browser can show me the certificate for my perusal. We can see that it has been issued by “happy hacker fake CA” which is a totally fake certificate authority. Normally at this point I just refuse to connect, unless it’s a certificate *I* created (for testing or with a private server, for example).

Screenshot of invalid certificate

TIP: If you want to see this in action and see how different browsers show error messages, you can use badssl.com – it’s a collection of servers badly misconfigured in various ways “meant for manual testing of security UI in web clients”.

Getting a digital certificate, the traditional way

The traditional way of obtaining a digital certificate is a long and tedious process. It involves a sequence of steps more or less like this:

  • generate a file in your command line – this is the key you want to use in your server. This can be done for example with the openssl binary.
  • sign up in the certificate authority system
  • upload file, fill in forms
  • wait for some physical post or something (to validate you are who you say you are)
  • maybe add some special code in your web
  • prove you are you back in their website (perhaps using data from the post, or with some sort of “official” ID)
  • quite probably pay 💸
  • finally get a digital certificate associated to the key you uploaded
  • install the updated signed keys in your server
  • repeat all, or part of this in ~a year

This is very long and tedious and I guess it explains why many organisations and individuals haven’t bothered with using HTTPS yet—such amount of hassle is not worth the benefits it might offer. Plus, the certificate fee is also a very significant factor.

Some certificate authorities started offering free certificates as well. Still, their process is  long and cumbersome. You can read my colleague Anne’s experience with migrating his websites to https with a free certificate offered by a traditional CA.

Getting a digital certificate, the Let’s Encrypt way

In contrast, the process for obtaining a certificate using Let’s Encrypt, the ‘modern certificate authority’, is way shorter:

  • Install their client in your server
  • Get new digital certificate for domain using their client (from your command line)
  • Start using keys from the certificate with your server
  • Automatic renewal is also possible with their client
  • ✅ done

This can take you like… 10 minutes? ✨Life is amazing with Let’s Encrypt

But what is Let’s Encrypt?

As I hinted, Let’s Encrypt is a new certificate authority that describes itself as ‘free, automated and open’. Everything about it is open source, or in the spirit of open source, from the clients, to the protocol it uses to connect the client to its servers (ACME) in order to generate and renew certificates, to the server code, to the transparency on its operations.

The Let’s Encrypt initiative is steered by the ISRG (Internet Security Research Group), whose mission is to “reduce financial, technological, and education barriers to secure communication over the Internet”, and is sponsored by Mozilla and others such as the EFF (Electronic Frontier Foundation), an organisation dedicated to fight for users’ privacy and other rights in the digital world (you might have read things such as Why Metadata matters from them).

And also, and very importantly, it’s trusted because its root certificate has been signed by another root certificate authority. So certificates generated by Let’s Encrypt are also trusted by major browsers.

We’ll learn how to use Let’s Encrypt in the next part (for easier referencing).