TLS & HTTPS Visualized, and HTTPS localhost setup in 2026

This lecture will introduce you to what TLS does. HTTP/2 and HTTP/3 are the way of the future. Hardly any serious website today will use HTTP/1.1.

This means its crucial for you to understand and master TLS and therefore HTTPS.

As you'll soon discover, there are numerous crypto algos that are used in order to achieve the desired goals of TLS. That's why its so intimidating for most developers and few developers appreciate how it works.

Enough said.

Let's get crackin'

Asymmetric key encryption guarantees confidentiality by using a pair of keys: a public key for encryption and a private key for decryption. When a sender encrypts a message with the recipient's public key, only the recipient can decrypt it using their private key, ensuring that unauthorized parties cannot access the message. This method eliminates the need to share private keys, significantly enhancing security against interception during transmission

The ultimate goal of HTTPS is for the client and server to use symmetric key encryption for efficient and secure communication. Initially, asymmetric encryption establishes a secure connection by allowing the client to send a symmetric session key, encrypted with the server's public key. Once the server decrypts this session key using its private key, both parties can communicate using symmetric encryption, which is faster and less resource-intensive for ongoing data transmission.

With HTTPS, the premaster secret is generated by the client and sent to the server, typically encrypted using methods specified by RSA. This premaster secret is then used to derive the master secret, which facilitates the generation of symmetric keys for secure data transmission. RSA enables secure key exchange, while symmetric key generation ensures efficient encryption and decryption for ongoing communication between client and server, balancing security and performance.

Asymmetric keys can produce digital signatures, which authenticate data integrity and origin. A sender uses their private key to sign a message, creating a unique signature. This signed message is sent to the recipient, who verifies it using the sender's public key. If the signature matches, it confirms that the message has not been altered and is indeed from the claimed sender, ensuring authenticity and non-repudiation in communications

Hashing ensures data integrity and is widely used for verifying data authenticity and security in various applications, including cryptography and yes ... you guessed it ... HTTPS.

I'll show you how hashing can be seed in Bash using utilities like sha256sum, which computes the SHA-256 hash of input data.

Hashing algos are one way functions - meaning that once you hash data, the "digest" or "fingerprint" cannot be reversed.

In HTTPS, hashing ensures data integrity by creating a unique digital fingerprint of the transmitted data. When a message is sent, its hash is calculated and sent alongside it. Upon receipt, the recipient computes the hash of the received message and compares it to the original hash. If they match, the data remains intact; if not, it indicates potential tampering or corruption during transmission, thus safeguarding against unauthorized modifications.

In ongoing HTTPS communication, combining hashing with key encryption ensures both data integrity and confidentiality. Each message is hashed before encryption, creating a unique fingerprint that verifies its integrity. The message is then encrypted with a symmetric key for secure transmission. Upon receipt, the recipient hashes the message and compares it to the original hash. If they match, it confirms the data is intact and unaltered, while encryption keeps the content confidential.

In the lectures i often refer to the sheriff, warthog and the certificate. I want to clarify something before we move on.

An explanation of the previous lecture.

HMAC using a combo of a hash and a secret key.

It involves hashing a message with a shared key to create a MAC, which is sent alongside the message.

Why is this done? Well, when the recipient receives the message, it uses the same key to generate a MAC and compares it with the received one to verify authenticity.

I'm teaching you this because HMAC is widely used in protocols like HTTPS to protect against tampering and unauthorized access.

A Public Key Infrastructure (PKI) is crucial for HTTPS because it enables secure communication over the internet. PKI uses digital certificates issued by trusted Certificate Authorities (CAs) to authenticate websites and encrypt data. This ensures that users are connecting to legitimate sites and that their information remains confidential and protected from eavesdroppers, preventing man-in-the-middle attacks and fostering trust in online transactions.

Public Key Infrastructure (PKI) supports HTTPS by providing a system for secure communications using encryption. It relies on digital certificates issued by Certificate Authorities (CAs), which verify the identity of websites. When you visit an HTTPS site, your browser checks the CA's certificate to ensure the site is legitimate and establishes an encrypted connection, safeguarding your data from interception and ensuring privacy during online transactions.

To request a certificate for HTTPS, a server generates a Certificate Signing Request (CSR). This CSR includes the server's public key and identifying information, such as the domain name and organization details. The CSR is then sent to a Certificate Authority (CA), which verifies the information and, if everything checks out, issues a digital certificate that binds the server's identity to its public key, enabling secure communication over the internet.

A quick recap

To view trusted Certificate Authorities (CAs) in relation to HTTPS, you can check your browser and operating system. In Chrome, access the settings by clicking the three-dot menu, then navigate to "Manage certificates" under "Privacy and security." For Windows, use certmgr.msc to open the Certificate Manager and view the "Trusted Root Certification Authorities." These lists include CAs that validate SSL/TLS certificates, ensuring secure connections when browsing.

To verify a server's signed certificate, a client first checks the certificate's validity period to ensure it is still active. Next, it verifies that the certificate was issued by a trusted Certificate Authority (CA) by checking the CA's signature against its public key. The client then uses this public key to validate the digital signature on the certificate, confirming its authenticity. Finally, it ensures that the domain name on the certificate matches the server's domain to establish a secure connection.

In reality, the browser not only checks the signature, but also performs a few other checks on the server's certificate.

In the next few lectures, we're going to apply all the knowledge you've gained in the course thus far to visualize what happens when a TLS session is negotiated between client and server.

In this particular lecture we will visualize the client hello and the server hello and what key (no pun intended) pieces of information are exchanged between them at this point in the TLS handshake.

I want to take a quick break here and use Wireshark to examine the client hello and server hello.

A quick recap on TCP vs UDP/QUIC streams

A quick Timeout.

In 2025, hybrid key exchange will involve combining traditional cryptographic methods with post-quantum cryptography (PQC) techniques. This approach aims to protect against quantum computers, which could potentially break current cryptographic standards like RSA and ECC.

Hybrid key exchange uses both classical algorithms (e.g., ECDH) and post-quantum algorithms (e.g., Kyber, Dilithium) to ensure security. The National Institute of Standards and Technology (NIST) has developed advanced crypto techniques, such as key encapsulation mechanisms (KEMs), to enhance security against quantum threats. This hybrid approach ensures that even if one method is compromised, the other remains secure.

If you will recall, a few lectures back when we were using Wireshark, the client in its "Client Hello" had two Key-Shares. One of these was the 4588 key share, which is X25519MLKEM768 algo, which basically combines ECDH with ML-KEM-768 to enhance security.

In this lecture I'm going to briefly explain to you what happens behind the scenes with these keys and how the server calculates the shared secret value (which by the way is constructed in two parts) as well as the cypher text used to send back to the client so that the client can calculate the same shared secret value.

It's going to be pretty heavy / advanced, but don't stress - i'm your wingman and here to walk you through it.

Let's get crackin'

A quick summary of what you've learned in the previous 2 lectures.

Let's finish off the TLS review by combining everything we've learned.

It is a complicated process so don't feel bad if you have to watch this lecture a few times to let it all sink in.

To establish a TLS connection, several key steps are involved. The process begins with a "ClientHello" message from the client, listing supported TLS versions and cipher suites. The server responds with a "ServerHello" message, including its chosen cipher suite and digital certificate, which the client verifies using ASN.1 syntax in PEM format. This verification ensures the server's identity and trustworthiness. The client and server then exchange keys to create a shared secret for encrypting communication. Various file types are used in this process, including .pem, .crt, .csr, and others.

In this lecture lets visualize the entire process of generating everything you need to allow your server to run over TLS.

The certificate generation process involves selecting a reputable Certificate Authority (CA) (usually in the real world it'll be someone like Let's Encrypt or DigiCert). Next, you generate a Certificate Signing Request (CSR) using tools like OpenSSL, which includes your public key and organizational details. You then submit the CSR to the CA, following their specific instructions. Once the CA issues the certificate, you install it on your server to enable HTTPS.

In this course I'll be showing you numerous ways to create all the files you need to spin up a localhost server over HTTPS.

In this part, you'll learn how to do this using a GUI, specifically with XCA.

XCA is used to create a local CA and self-signed certificates. It's totally free.

In this lecture let's complete the first 2 steps required for a TLS connection and that is to create our CA and generate its self-signed certificate.

In this lecture, I'll show you how to create keys, a CSR, and a signed X.509 certificate for localhost using XCA.

Buckle up, and you'll learn how to: 

1. generate CA Key and Certificate: Use XCA to create a CA's private key and self-signed certificate by selecting the "CA" template and generating a new key[1][2].

2. generate Server Key and CSR: Create a private key and CSR for the server using the "TLS_server" template.

3. use your CA to sign the CSR: Use the CA's private key to sign the server's CSR, producing a signed X.509 certificate for localhost.

After this lecture, you'll have everything you need in order to tell Live Server to run your localhost over HTTPS.

In order to run your website (including localhost) over HTTPS, you need a way to tell your server that this is what you want to do.

Remember, I also told you earlier that the 2 files a server needs is its (a) certificate and (b) private key.

In this lecture I'll show you how to set up a configuration file in Visual Studio Code using a folder .vscode and a settings.json file to configure Live Server to run over HTTPS and use those two files we have already created.

To finish off, let's examine our TLS request using Wireshark to ensure everything is working as expected.

A quick word on what we'll be doing in Part 2.

OpenSSL is automatically installed on macOS and Linux systems, but it must be manually installed on Windows. You can download it from the official OpenSSL website, which requires manual compilation and setup. Alternatively, you can use pre-compiled installers from sites like Shining Light Productions (SLProweb) for a simpler installation process

In this lecture let's use OpenSSL to produce the CA's private key, and then generate a self-signed certificate

In this lecture I'll show you how to inspect the private key file inside of OpenSSL as well as use free online tools to convert the PEM file into ASN.1 readable format.

By knowing this, you'll gain an advantage over other developers who get confused as to why the private key hex value looks the same as the public key.

In this lecture I'll show you how to use OpenSSL to create a Certificate Signing Request (CSR ) and generate a set of key pairs.

The final step is to use our self-created Certificate Authority (CA) to sign the CSR that the server generated.

After this lecture you'll have everything you need in order to run the Live Server over a secure HTTPS/TLS connection.

For simple use cases where only one or a few certificates are signed, managing uniqueness is straightforward, and the risk of serial number conflicts is minimal. However, when managing many sites that require a CA to sign multiple certificates, ensuring each certificate has a unique serial number is essential. This uniqueness prevents conflicts and allows reliable tracking and revocation of certificates.

This is where .srl files come into play. A .srl file stores the current serial number in use by the CA for signing certificates. Each time a new certificate is signed, the CA increments this serial number stored in the .srl file, guaranteeing that every certificate issued has a distinct serial number related to the CA. Without this mechanism, duplicate serial numbers could lead to validation errors or security risks.

Therefore, .srl files are fundamental to maintaining uniqueness across multiple certificates issued by the same CA.

The moment we've all been waiting for ... finally spinning up a localhost server using Live Server using HTTPS/TLS, using the OpenSSL files we have generated.

I can't wait.

Last but not least, let me show you yet another way to create a server running on localhost to spin up over HTTPS and TLS.

Before we start using the mkcert package in Node.js, I would like to set up our server-side code so we are ready to run our HTTPS server when all the certificates are generated.

In this lecture I'll show you how to use the modern ES Module syntax to "import" modules in Node. Specifically we we will the https, express, fs, and mkcert modules to set up our server.

In this lecture I'll show you how to use the mkcert API to create a Node.js localhost server and run it over an HTTPS connection.

Finally, I want to show you how to run mkcert directly in the CLI. As I'll show you, there are a few ways you can do this - you can install mkcert globally or you can use the npx command.

We will then fire up our Node.js server over HTTPS and you'll be done!

A huge thank you, and a VERY GOOD JOB for sticking with me until the bitter end.

See you soon, in a future course.