HTTPS is HTTP + TLS, which adds security via X.509 certificates at the transport layer. An X.509 certificate identifies its owner and includes a public key associated with that owner. The private key is kept secret, and used by the certificate owner to decrypt communications encrypted by the public key.

An X.509 certificate contains four pieces of information:

1. Name of the owner, e.g. subject.
2. Subject’s public key (e.g. some key generated via asymmetric algorithms like RSA or ED25519)
3. Certificate Authority (CA) that issued the certificate, by name.
4. Expiration date of the certificate.

Certificates are signed by a CA via Certificate Signing Requests (CSRs). Each trusted certificate in a browser is signed by a higher-level certificate, until we get to some root CA certificate that we trust. That root CA certificate is self-signed. All browsers come with root CA certificates.

For our own public websites, we need a certificate signed by a trusted, public CA. Things like Let’s Encrypt provide this for free. For private PKI, e.g. your Kubernetes cluster components, you can have a private root CA with its own generated self-signed certificate, and then that signs the certificates of all other components. It’s important for private PKI to trust itself and each other, but we don’t need a public CA to be involved.

If a key or certificate is compromised, we use Certificate Revocation Lists (CLRs) to take the certificates in question out of service.

TLS Connections

TLS connections begin using X.509 certificates, which contain the public key of a key pair generated via asymmetric algorithms, as opposed to symmetric algorithms like AES. When a client connects to a server, it receives the server’s certificate. It can validate that the certificate is signed by a trusted, public CA (one it also knows about!), and then can use the public key to encrypt communications for establishing a symmetric key to be used for the rest of the session. Asymmetric algorithms like RSA and ED25519 must be used to establish connections, but then more performant and secure symmetric algorithms like AES will be used once we establish trust via the asymmetric key pairs.

Note that this process can simultaneously happen in reverse, where a server verifies a client’s certificate. This is called mTLS. It’s common in infrastructural communications, like Kubernetes, but on the public internet, a lot of clients are verified at Layer 7, via simple user/password or text message mechanisms.