Notes on HTTPS

You know you need an SSL Certificate or something of that kind. You know... the little HTTPS thing that reassures users that communications between you and them are encrypted and that the pages they are seeing are actually sent from a legit website? But WTF is it and how does it work? Why is it even important?


People like secure internet connections. Why? Web servers transmit some pretty sophisticated tools to users over internet connections. Users send sensitive data to web servers over internet connections. Because the internet relies on openness, and relaying of signals across a vast unknown web of signals in order to move data from sources to destinations, it makes sense for users to want their information to be hidden from anybody who might read their transmission before it reaches its destination. It also makes sense that they would want to know that when they access a resource like "" that whatever they see in their browsers was truly sent by JP MORGAN CHASE, INC. and not some impersonator on the network who is intercepting the browser requests.

If those who manage web servers assume that users are using a standard, trusted browser to access the internet, they can provide these assurances by setting up their servers to send data in HTTP connections over TLS, i.e. using HTTPS. Since HTTP connections are essentially the type of connection we are talking about when we speak of "internet connections," HTTP connections secured by TLS are a way of providing secure internet connections.


HTTPS (or HTTP Over TLS) is the frequently seen abbreviation use to label websites whose managers have properly configured their servers to abide by the protocol laid out in RFC2818, which describes how to use TLS to secure HTTP connections.


TLS stands for Transport Layer Security. TLS is a protocol for encrypting data transmissions implemented by servers (your web server) and clients (browsers). If you set up your server appropriately, it will be able to use TLS in collaboration with your user's browsers to encrypt data sent over HTTP connections.

How does it work?

So if you look at RFC2818, it actually concisely explains how TLS should be used. But for completeness, I will also give a high-level summary of the principles of TLS and how it works.

First, shake hands

RFC2818 says that a secure connection should be initiated by the HTTP client (i.e. the browser that your user is using). This puts the burden on people who make browsers to design them in a way so that they initiate secure connections properly, hence the importance of the assumption that users use standard, well-known browsers.

In this case, before sending an HTTP request, the browser should first send over a TLS ClientHello to initiate a TLS Handshake. Only servers that are legitimate and correctly configured will be able to reciprocate and complete the TLS Handshake. Once the Handshake is completed, then HTTP requests and responses can be sent between client and server - nicely encrypted too.

  • Browsers/client software are the programs that actually implement certificate checking and encryption of information transmitted from the client to server.

  • Servers likewise implement encryption of information before sending it to clients. There is actually the ability to do something called mutual HTTPS, wherein the server also authenticates clients using certificates, but this is not uniformly implemented.

  • To enable HTTPS one needs to obtain a certificate from a Certificate Authority (CA). Let's Encrypt is a CA.

How do I set it up?

  • Before issuing a certificate, Let's Encrypt requires that the person seeking a certificate for their server demonstrate control over a domain. This process is governed by the ACME protocol.

  • ACME protocol is implemented by ACME clients, for example Certbot.