What is this S in HTTPS? How does the Internal process of obtaining this S work? (Part 1)
Have you ever wondered what the “S” in HTTPS stands for and how it’s obtained? Let’s dive into the fascinating process of securing your online communication with the HTTPS protocol.
This article is going to be divided into three sections. In the first section, we’ll have a quick introduction to HTTPS. Then, in the second section, we’ll take a deep dive into how the SECURE part of HTTPS works, and we’ll go through the steps needed to have a website verified with HTTPS. Finally, in the third section(a separate article), we’ll see how the certificates obtained during the HTTPS process are confirmed in the client-side web browser.
What is HTTPS and why do we need it?
So, in a normal HTTP model, all the data transferred between the client and the server is in plain text. This means that if someone intercepts the data, they can easily read and access all the variable information. For instance, let’s consider a credit card transaction. The credit card number, security code, and other personal details are all transferred through plaintext, which isn’t secure at all. That’s where HTTPS comes into the picture. It provides security by encrypting all the data transferred between the client’s browser and the server. This way, only the client and the server can access the data, and nobody in the middle of the chain can read or access it.
But the process of enabling HTTPS involves several steps that need to be configured beforehand. In the later part of this article, we’ll take a deep dive into the actual process of how HTTPS works and what needs to be done to make it happen.
What is the internal process that happens in obtaining HTTPS to a server?
In this part 1, according to the above picture, we are considering only the left-hand side which means getting a certificate from the CA (Certificate authority).
- The server generates a public and private key pair.
In order to enable secure communication via HTTPS, the server needs to have both a public key and a private key. These keys belong to the category of cryptographic keys. There are two types of cryptographic keys: symmetric keys and asymmetric keys. Symmetric keys use a single key for encryption and decryption, while asymmetric keys have two different keys: a private key and a public key. The private key is kept by the owner, while the public key is exposed to the public.
The private key and public key concept are mainly used for signing purposes. If the owner wants to send something to someone else, they can encrypt the data with their private key, and the recipient can decrypt it with the corresponding public key. Likewise, if a third party wants to send something to the owner, they can encrypt the data with the owner’s public key, and only the owner can decrypt it with their private key. This ensures that the data can only be accessed by the intended parties and that it has not been tampered with.
Because of the above reasons, for HTTPS communication to happen, this server needs to have a public key and a private key. So, this first step is for that. In the upcoming steps, we’ll explore how these keys are used to enable secure communication between the client and server.
2. Server creates a Certificate Signing Request (CSR) containing its public key and information about the domain name and organization.
So, let’s talk about certificates and certificate signing requests. A certificate is like proof of legitimacy for a server, kind of like how we get certificates for our achievements in school. It includes important information that proves the server is not a scam and can provide a good service. Certificate authorities (those are the organizations responsible for certifying the third-party servers) sign these certificates to prove their legitimacy and prevent them from being altered by someone else. Now, a certificate signing request (CSR) is a document that includes relevant information like the domain name, organization name, city, country, etc. The server sends the CSR to a Certificate Authority (CA) along with any additional required information.
3. The CA verifies the information in the CSR and performs its own checks to validate the identity of the requester.
4. If the verification is successful, the CA issues a certificate containing the server’s public key and other identifying information.
So, the Certificate Authority is responsible for creating the certificate that verifies the legitimacy of a particular server. They include relevant information from the server (like the domain name, country, city, expiration dates, ciphers used to sign the certificate, and much more) and sign the certificate using their private key. It’s important to note that this private key belongs only to the Certificate Authority. Here signing means CA will encrypt the hash of that certificate using its private key, then others can generate the hash for the available certificate information and decrypt the CA encrypted hash (using the public key of the CA) to check whether both hashes are matching. If matching then that means no one has altered the certificate and then if the domain name in the certificate and the domain name of the server matches then all are good to go and the service is legitimate. In short, the Certificate Authority creates and signs the certificate, and using the public key of that CA, a client (mostly a web browser) can verify the certificate’s legitimacy.
5. The CA sends the certificate back to Server
6. The Server installs the certificate on its web server and configures it to use HTTPS.
When a client wants to connect to a server, the server sends its certificate to the client. The client’s job is to verify that the certificate is legitimate and has not been tampered with or faked. If the certificate is genuine, then the client can trust that the server is who they claim to be and that the communication channel is secure. However, if the certificate is fake or has been altered, then the client will not continue with the communication process because it cannot trust the identity of the server or else the browser will show an alert that this server’s certificate is not valid. Therefore, the certificate plays a crucial role in establishing trust and security between the client and the server.
From this article, I tried to give as much as information regarding how a service-providing server obtains a certificate from the CA. In the next article, we’ll see how the next part of this whole HTTPS story how the client obtained this certificate from this server and how the verification thing happened, and deep dive into the several handshakes involved in this process, which will be more interesting.
