HTTPS WITH SSL/TLS
In this article, we will learn about how web encryption and web security works based on the SSL/TLS protocol. We will also go through the anatomy of SSL certificates and how to generate a self-signed certificate for your own use.
(source: unsplash.com)
I?m currently writing an article on how to create a secure HTTP server in Go (golang) and I thought what could be a better opportunity than this to discuss this broad topic about web security.
In this article, we will be extensively talking about SSL/TLS communication, HTTP protocol, Internet packets, SSL certificates and other essential features of the web/internet that do not come up in our day to day web development life but we should be absolutely aware of them.
How does the internet works?
I could answer this question in one sentence or we could be here for hours. But I want to keep things simple and easy to understand.
The internet is literally a mesh of wires spread around the world that connect different devices to each other. Even if you do not see a physical wire, you can imagine your smartphone connected to a WiFi router via a virtual wire that lets you talk to a Google server situated miles away from you.
When you want to send some data to a device that is connected to your personal device via the internet, you need to follow some rules. All the data transferred over the internet is binary data consist of 1s and 0s.
1. First of all, the application being used to send data needs to communicate with the hardware on the device to send the data over the internet. Also, the hardware of the device needs to communicate with the device that is actually transmitting the data over the internet like a WiFi router.
2. When you send a letter to a person, you label your letter with the address of the receiving person so that the letter gets delivered to the right person. Similarly, when you send some data over the internet, you need to know the address of the device that will receive it eventually.
3. When a network application is launched in a device like a web browser or a web server to transmit or receive the data, it will listen to the internet data on a port number like 8080. The sender needs to know about the port number of the receiver device so that the data is received by the correct application and not the one that may abuse it.
? These port numbers are randomly assigned by the operating system but we can force the operating system to bind an application to a certain port number.
4. The device receiving the data would not be able to make sense of it unless it has prior knowledge of what it is looking at. The data could be an image, a song, a plain text message or an HTML document. Hence we need to tell the receiver about the data type so that it can interpret it correctly.
These four steps describe a communication model for data transmission on the internet. Each of these steps is defined by a protocol. Depending on the type of protocol, each of these steps formats the data accordingly so that the receiver can extract the data properly.
? There might be more steps in a particular model depending on the use case of the data transmission. You can read about the OSI model which can be used by anyone to transmit data over the internet or Local Area Network (LAN).
If we inspect these steps carefully, they form a pipeline where data from one step is sent to the other step for further processing until it gets transmitted over the internet. However, the layer would be the most suitable word to describe each step and we will soon learn why.
TCP/IP Communication Model
The Transmission Control Protocol (TCP) is the transport layer protocol in the communication model we saw earlier while Internet Protocol (IP) is the internet layer protocol.
These protocols together drive most of internet communication. At this very moment, your browser is using the TCP/IP model to load this webpage from a server. Hence, these together form the internet protocol suite.
(Internet Protocol Suite)
(source: Wikipedia)
In the above communication model (left side), the application layer gets the data from a source (like internal storage or RAM) and wraps some headers of a particular protocol like HTTP. This creates a data package of the HTTP protocol and can be read by an application that can understand it like a web browser.
This HTTP package is sent to the transport layer. The transport layer wraps the package with TCP protocol headers along with the source and destination ports. The source port is the port of the application transmitted the data (like a web browser) and destination port is where the application running on the receiving side will receive it.
This TCP package is received by the internet layer which wraps some IP protocol headers with source and destination IP addresses. The source IP address is the IP address of the sender device while the destination address is the IP address of the receiver device.
? An IP address is a unique number allocated to a device on the internet. You can read more about IPV4 and IPV6 IP address formats. The IP address of a device can be known prior to the data transmission or can be resolved from a DNS server using the domain name contained in the HTTP header.
Once the package is stamped with IP protocol, it becomes a network packet that is good enough to be transmitted over the internet. This is the last step of the virtual layers (processed by a computer program).
The last link layer is a physical layer on the device. This is a hardware part like the Network Interface Card (NIC) on your device which takes the packet and adds the source and destination MAC addresses to it.
? The Media Access Control (MAC) address is the unique address of a hardware part provided by the equipment manufacturer. Using MAC addresses, communication between two devices becomes possible.
Once the packet is labeled with source and destination MAC addresses with some additional headers of a data transmission protocol (like Ethernet), it can be sent to the internet communication device like a WiFi router or Satellite Dish that will take care of the transmission over the internet.
Once the packet is received at the receiving end (right side of the diagram above), it will be peeled like an onion until the original data (the HTML document) is recovered.
The data is extracted successfully without any misinterpretation, one layer at a time, by looking at the protocol of that layer. Once the original data is extracted, it can be consumed by the correct application.
For example, if a server sends an HTML page using the HTTP protocol, a web browser is fully capable of understanding a package of an HTTP protocol and extracting the HTML page. This HTML document will then be rendered on the screen by the browser.
? The HTTP protocol can also be used to transmit data other than HTML pages. The Content-Type header of the HTTP protocol is used by the application like a browser to understand the MIME type of the content.
If the receiver wishes to send the data back, it can use the source address of each layer provided by the sender to successfully send the data back in the same manner.
HTTP Protocol
The HTTP protocol is based on TCP/IP or UDP/IP protocol. Before any data is sent to the receiver, a communication channel should be opened between the sender and the receiver. This is done using TCP/IP alone without any application layer, as shown in the diagram below.
? The destination port of the TCP layer is derived from the HTTP protocol. The internet agrees on port number 80 as the default port of HTTP protocol.
(source: Wikipedia)
(TCP three-way handshake / source: Wikimedia Commons)
First, the client sends an empty packet (without any application data) to the sender with the TCP protocol SYN (synchronize) flag set to 1. When this packet is received by the server, it knows that a client is trying to establish a connection (session).
? The application data is the data contained in the application layer.
The server sends back an empty packet with SYN and ACK (acknowledge) flags set to 1. When the client receives this packet, it knows that the server has responded and willing to accept the request.
Then the client sends an empty packet with ACK flag set to 1. Once the server receives this packet, a TCP communication channel is opened.
This is called the TCP three-way handshake. Once the handshake is completed and a TCP communication channel is opened, the client or server can send and receive the application data over the same connection unless the client or server closes the connection.
Let?s see this handshake in real life using Wireshark. I am going to open http://info.cern.ch in the browser (the very first website) and Wireshark will capture all network packets for me.
(HTTP GET Request)
As you can see from the screenshot above, when we wanted to send an HTTP GET request to the info.cern.ch server, the first thing that happened was a TCP three-way handshake.
? There are a lot of awesome stuff that you can?t see in a single screenshot. I would recommend you to install Wireshark on your system and give it a try. You can follow this awesome talk to use and apply filters in Wireshark to follow the packets in a TCP/IP communication channels.
Once the connection is established, the HTTP protocol data was sent as the application data to the server in the network packet. This data contains the HTTP headers in plain text formats.
? However, the data obviously will be encoded in binary.
(HTTP protocol)
Once this data is received by the server, the server can acknowledge the request by sending the data back to the client. As you can see from the above screenshot, the server responds with an HTTP protocol application data that contains the response headers and the HTML document in plain text.
Once the server has sent all the data back, could be in one packet or multiple packets, the client has to acknowledge the receipts by sending empty packets that have ACK flags set to 1 and the sequence numbers of the packets it is sending acknowledge for.
? You can follow this video to better understand what sequence numbers and acknowledge numbers are used for.
Once the server has no more data to send, it will send an empty packet with FIN (finished) flag set to 1 to indicate the finished message. The client can acknowledge this packet to close the connection as described below.
(source: Wikipedia)
? In HTTP persistent connection (keep-alive), the same TCP connection will be used to request for other resources. This is more efficient because we don?t have to go through the same TCP three-way handshake again and again.
Many times, the client and server communication is not smooth. There could be a loss of packets and packets may arrive in the wrong order, hence such packets need to be retransmitted again.
? The UDP protocol differs in this aspect. In the UDP protocol, the receiver does not have to send the receipt packets and packets loss or packets order is not dealt with any seriousness. You can follow this video to understand the differences between TCP and UDP protocol.
Security concerns
HTTP is an insecure protocol since data in an HTTP protocol is encoded in plain text format. Any man-in-the-middle can listen to TCP communication and read your personal data transmitted over the web.
This is why search engines like Google assign lower indexes in the search result to the insecure websites. However, making a website secure is not an easy task. But you can always use websites like Cloudflare to make your website secure without having to worry about the implementation.
Overview of SSL/TLS
HTTPS stands for HyperText Transfer Protocol Secure and but it is misleading in some ways. HTTPS protocol can not alone do the encryption of data, in fact, it depends on the SSL or TLS protocol layer.
? I am just going to use TLS protocol to refer to both SSL and TLS protocols and it will be clear soon why SSL name could be misleading in the 21st century.
Both the HTTP protocol layer and the TLS protocol layer are part of the application layer. The role of the TLS layer is to establish a secure connection with the server using a TLS handshake (after the TCP handshake) and encrypt the HTTP data using some encryption algorithms negotiated with the server.
The final encryption data becomes the application data of the network packet the server is going to receive. Since the application data is encrypted, any man-in-the-middle might obtain the data but won?t be able to make sense of it. This prevents a man-in-the-middle attack.
When HTTP protocol is used in conjugation with TLS protocol, it is called HTTPS protocol. To invoke a browser or a program to use TLS for the communication, we usually use https:// protocol prefix in the URL.
To understand how TLS works, we first need to understand how encryption works and the different kinds of encryption algorithms.
Encryption is a process of encoding data of one format into another format that can not be read by us humans. To encrypt some data, we use a different kind of mathematical tricks on the data with some secret parameters.
Some of these parameters are not made public intentionally. Using these same or similar parameters we can decrypt encrypted data. These parameters are collectively called a key. If this key is made public, anyone who has access to it will be able to decrypt and read our secret data.
Asymmetric Key Algorithm
In Asymmetric key algorithm, we have two keys to do encryption and decryption. The public key is used to encrypt the data and made it available to the public. Only the secret key which is kept secret can decrypt it.
? The asymmetric key encryption is called the public-key cryptography.
The most popular asymmetric key algorithm is RSA (Rivest?Shamir?Adleman) because it extensively used on the web for key exchange and digital signature validation. But browsers are now adopting a more secure and efficient Diffie-Hellman key exchange algorithm for key exchange.
? RSA private key can also be used to encrypt data and public key to decrypt data encrypted by the private key. This used for generating and verifying digital signatures of encrypted data and SSL certificates (explained later).
Asymmetric key algorithms are generally slower and CPU intensive (why?). Bigger the length of the key or the data, longer it will take to encrypt or decrypt the data.
Hence public key cryptographic is not used for bulk data encryption. Instead, we use symmetric key cryptography to encrypt or decrypt large amounts of data which is much faster and efficient and the asymmetric key cryptography is just a means to transfer the shared symmetric key.
Symmetric Key Algorithm
In the symmetric key algorithm, the same key is used to encrypt and decrypt the data. This key is also called a shared key. This is also a secure algorithm but you can not send this key to the public.
Symmetric key cryptography is generally faster than public-key cryptography (why?) and can be used for bulk data encryption. Hence it is also called block cipher or block cipher.
The symmetric key algorithm is mainly used to open an encryption channel between two trusted parties. Only these two parties will ever know about the data being shared between them since nobody else on the network has access to the shared symmetric key.
One of the most popular symmetric-key algorithms on the web is AES (Advanced Encryption Standard).
SSL (secure sockets layer) Protocol
The SSL protocol was first designed by the Netscape browser team and SSL 2.0 was publicly released in 1995. It was soon replaced by the SSL 3.0 that came with security improvements but it was deprecated by IETF in 2015.
As of now, SSL protocol is broken (except some variations) and nobody uses it. The IETF launched the first version of the TLS protocol in 1999 which is now the standard for all encrypted communications on the web.
? When somebody talks about the SSL, they are probably talking about TLS. Even the SSL certificates are in fact the TLS certificates. SSL v3.1 or SSL v4 are just aliases for the TLS 1.0+ versions.
TLS (transport security layer) Protocol
The TLS is an improvement over the SSL protocol. TLS 1.0 was launched in 1999 and it has gone through some iterations. The current most supported version of TLS is TLS 1.2.
TLS 1.3 was launched in 2018. It is a major overhaul of TLS 1.2 which improves efficiency and data security. This version reduces the number of handshake requests to establish a secure TCP connection.
TLS 1.3 only supports the modified version of the Diffie-Hellman public-key cryptography algorithm to share a symmetric key between a client and the server. It has also dropped the support of the RSA algorithm for the key exchange.
? However, TLS 1.3 is not supported by all browsers and servers. Hence a browser and a server may not be compatible with each other for TLS 1.3 communication and will use a lower TLS versions like TLS 1.2.
HTTPS Handshake with TLS 1.2
When we send an HTTP request with https:// protocol prefix, first thing first, a TCP connection is established using a three-way handshake we saw before. This is indicated by the blue lines in the diagram below.
? This time, the destination port of the TCP layer is 443 which is the default port of HTTPS protocol.
(TLS 1.2 Handshake / source: Wikimedia Commons)
After a TCP connection is established, the TLS handshake begins. First, the client sends an empty packet but with a TLS 1.2 protocol layer. This layer contains some metadata and a Client Hello message.
(TLS Client Hello Message)
As you can see from the screenshot above, in the Client Hello handshake message, we are attaching some list of cipher suites our application (like a browser) currently supports. We will talk about them in a bit.
? When a Client Hello handshake message is being sent, the application commencing the communication may first try with the highest TLS protocol version like TLS 1.3 and downgrade to a suitable version that server supports. If the application does not support the version that the server is asking, it may drop the TCP connection with a warning.
(TLS Client Hello Message)
Along with a list of cipher suites, we are sending a server name indication (SNI) message that indicates the hostname (domain name) of the service we are trying to connect with. This is used by the server to send back an appropriate SSL certificate that matches this hostname.
(TLS Server Hello Message)
When the server receives the Client Hello packet, it responds with an empty packet that contains the Server Hello message. This packet contains the cipher suite the server has chosen from the list of choices the client provided.
It then sends a packet that contains the SSL certificate for the domain name we asked for using SNI value. At this point, the server has nothing more to send, so it sends the packet with Server Hello Done message.
One the client receives the SSL certificate, our application can validate it. This certificate also contains a public key of the cipher suite chosen by the server. We will talk more about the certification validation process in the SSL lesson.
A cipher suite contains a list of cryptographic algorithms and a hash function to encrypt and validate data being transmitted between a client and a server. A simple example of a valid cipher suite would be as follows.
TLS_RSA_WITH_AES_256_CBC_SHA
If the server chooses the above cipher suite, it means that the server will use the RSA algorithm to encrypt the shared secret key of bulk data encryption. The bulk encryption algorithm used by both the client and the server is AES 256 bit (in CBC mode).
The last part of the cipher suite is the one-way hashing function to create digital signatures. We will talk more about the digital signature later.
Once the client and server agree on a cipher suite, encrypted communication can be started. So far all our packets were not encrypted as they did not contain any application data and had no prior knowledge of encryption.
The client now generates a shared secret key for bulk data encryption. As stated in the cipher suite, it will create a 256-bit key of the AES symmetric-key algorithm. This key needs to be shared with the server.
(Client Key Exchange)
Using the RSA public key of the server obtained from the SSL certificate, the client will encrypt the shared key and send it to the server with the message Client Key Exchange.
This packet also contains the Change Cipher Spec message to indicate that the client is using the agreed cipher spec for data encryption.
In the same packet, the client sends a Finished handshake message to indicate that the TLS handshake from the client?s side has been completed. This message is encrypted using the shared symmetric key (AES).
Once the server receives this packet, it will receive the shared symmetric-key by decrypting the data using its private key. Since nobody else has access to the private key, this shared secret key can not be read on the network.
By looking at the Change Cipher Spec message, the server will also change its data read/write mode to the agreed cipher spec. Then it will decrypt the handshake message using the shared secret key it just extracted.
Since the handshake message is Finished, it will send a packet back to the client that contains a Change Cipher Spec message to indicate that the server is using the agreed cipher spec for data encryption and a Finished message encrypted with the shared key.
(Server Finished)
Once the client receives this packet, TLS 1.2 handshake is complete and application data can be transferred over the TCP channel by encrypting/decrypting it using a selected bulk data encryption algorithm.
? A man-in-the-middle can tamper the handshake but since the shared key has been exchanged with RSA cryptography, handshake it totally secure. However, if the encrypted Finished messages have been tampered with, the TCP connection is dropped and no further communication is possible over the same channel.
Session Keys
May at times, the raw shared secret key is not shared with the server, no matter how strong the RSA encryption is to encrypt it beforehand. Instead, a pre-master secret is shared with the server instead of the shared key.
This pre-master secret is used by the client and the server to come up with the same shared secret key based on an algorithm that was negotiated during the TLS handshake. This shared secret key will be generated while reusing a previous TLS session (resuming) without going through a full handshake.
However, this does not prevent man-in-the-middle attacks if the private key of the server gets compromised.
HTTPS Handshake with TLS 1.3
TLS 1.3 comes with a lot of improvements. It has dropped support for RSA encryption for key exchange. If the private key of the server is compromised, anybody who has access to this private key will be able to decrypt all messages transmitted between the client and the server.
Security
TLS has made the ECDHE key exchange algorithm mandatory for TLS 1.3 protocol. It is basically a Diffie-Hellman (DH) public key algorithm with Elliptic-curve cryptography. Together they form ECDHE cipher which is much secure.
The way ECDHE works is by keeping a randomly generated private key at both the client?s and server?s side. Using the DH algorithm private parameters, DH algorithm public parameters and the elliptic-curve public parameters, the client generates a public key that will be shared with the server along with all the public parameters.
Using this public key and parameters of the client along with its own DH algorithm private parameters, the server comes up with its own public key and shares it with the client. The server generates a shared secret key from these results.
Using this public key of the server and previous parameters, the client comes with a shared secret key as well. The fancy math behind the DH algorithm allows both client and server to generate the same shared secret key. This shared key is used for bulk data encryption.
? I am not going to explain the math behind ECDHE but you can watch this brilliant video to understand how the DH algorithm works.
Forward Secrecy
Similar to TLS 1.2, a raw secret key won?t be generated at the client and the server ends. Instead, a pre-master secret is generated to compute the final session key that will be used for bulk data encryption.
The E in ECDHE stands for ephemeral which means the DH parameters generated by the client and the server using the DH algorithm are short-lived. Unless a TLS session is being reused, for every new TLS session, new parameters are chosen and new session keys are generated.
Since the SSL private and public keys are not involved in this process, they are not very useful to extract the data being transmitted over a TLS 1.3 channel. This empowers TLS 1.3 communication with perfect forward secrecy (PFS).
? If the private parameters, pre-master secret or session keys are compromised, an attacker will be able to extract data for a single TLS session only.
Shorter Handshake
Not only the perfect forward secrecy is the benefit of using TLS 1.3, but TLS 1.3 makes the TLS handshake very short.
Like TLS 1.2, the client sends the Client Hello message but in this packet, it also sends the public parameters that will be ultimately used for generating the shared secret key, as shown in the diagram below.
(TLS 1.3 Client Hello Message)
The client also sends the list of supported cipher suites in the same packet and the server will choose a suitable ECDHE algorithm to use.
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
If the server chooses the above algorithm, ECDHE with RSA is used for the key exchange. RSA encryption is only used to digitally sign (basically encrypt with the SSL private key) the public key (of the key exchange process) sent by the server so that the client can verify if it is actually being sent by the server.
(TLS 1.3 Server Hello Message)
When the server responds back with a Server Hello message, it sends the digitally signed public key (of the key exchange process), SSL certificate, Change Cipher Spec message and encrypted Finished message. At this point, the TLS 1.3 handshake from the server?s side is completed.
(TLS 1.3 Client Finished Message)
One the client receives the digitally signed public key from the server, it will generate the shared secret key and respond back to the client with a Change Cipher Spec and encrypted application data. This is the end of the TLS 1.3 handshake from the client?s side.
(TLS 1.3 Handshake / source: Wikimedia Commons)
As you can see from the above diagram, this handshake is much shorter compared to TLS 1.2 handshake. However, it may take longer if there are any compatibilities between the client and the server on the public parameters used for the key exchange.
HTTPS Data Encryption and Integrity
So far, we have learned that TLS is used primarily to encrypt data between two communication parties. If the data coming from the client is encrypted with the public key of the server, only the server can decrypt it with its private key. This makes the client to server communication secure.
But what if the man-in-the-middle tampers with the data coming from the server? Even though the data coming from the server is encrypted with the shared secret key, we need to validate it for its integrity.
Digital Signature
A digital signature is nothing but data encrypted with a private key that can be decrypted with the public key. Most public-key cryptography algorithms do not support this feature, but RSA does.
Data Integrity over TLS
When the server sends the data back, not only it sends the encrypted copy of the data but also a digital signature. The digital signature is generated by encrypting the data with the private key.
Before consuming the data, the client can verify this digital signature using servers public key and if it fails, then the TCP connection is dropped.
This obviously has a few problems. First, RSA is not meant to be used for bulk data encryption and second, we do not have a mechanism to verify if the internal data is actually compromised.
This is where the one-way hashing function negotiated with the server comes into the play. The server first computes the hash of the data with the hashing function like SHA and encrypts (signs) it with the private key. The result is the digital signature everybody is talking about and it is also called a Message Authentication Code or MAC.
When the client receives the encrypted payload, it recovers the data and the digital signature using the symmetric key algorithm. Then it first checks if the digital signature is actually signed by the server using the server?s public key and extracts the hash value.
Then the clients compute its own hash by using the same hashing function over the data is received from the server. If the hash sent by the server matches the hash it computed on its own, the data is secure.
This is the basic mechanism to validate data integrity and it is taken care of by the TLS protocol layer.
Hashing is used in many places, for example, while releasing software to the public. When software is distributed, its hash is also provided along with it.
The consumer can match the hash provided by the distributor with the hash of the software content he/she computed locally. This hash is also called the checksum or a digest.
// MD5 checksum of `Hello`8b1a9953c4611296a827abf8c47804d7// SHA-256 checksum of `Hello`185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
Hashing is different from encryption. It strictly one-way data mangling method and it can not be reversed back to the original data. If the data has been tampered with, even by a small amount, it will generate a different hash.
? MD5 and SHA-1 have been deprecated by IETF.
What are SSL certificates?
There are three principles of secure communication. Data Encryption, Data Integrity, and Data Authenticity. We have seen the first two so far. Data authenticity means the data is coming from the entity we are intending to communicate with.
When we access google.com in our browser, why are we so sure that a man-in-the-middle is not serving us the bad content? The man-in-the-middle could be using an HTTP server with public-private key cryptography, so is there any way to tell if our data is actually being sent to the google.com server?
When we access https://google.com, our browser communicates with the Google server with a suitable TLS protocol. The server responds with an SSL certificate that contains the public key of the server.
This SSL certificate is special, though its nothing but some binary data. This SSL certificate is digitally signed by an organization called Certificate Authority (CA) using its own private key.
Brower comes with preinstalled with CA public certificates. These are the certificates that the browser absolutely trusts, even blindly. There are two kinds of certificate authorities, the Root CA and the Intermediate CA. GlobalSign is one of the trusted root certificate authorities.
When google.com server sends the SSL certificate, it will be installed in the browser and it will look like below.
(google.com SSL certificate)
From the issuer information of the certificate, we can see that it was signed by the Google Trust Services. You can also see the public key information of google.com server in the Public Key Info section.
Since the SSL certificate of Google Trust Services was already installed in the browser, it could verify the digital signature contained in the SSL certificate sent by the google.com server. If a man-in-the-middle sends the wrong SSL certificate, our browser would complain about it since it is not signed by a certified CA.
You can also see the signature algorithm used to generate the digital signature of the SSL certificate. In the above example, the RSA algorithm is used in conjugation with SHA-256 to generate the digital signature of the certificate.
? Even if a man-in-the-middle sends the wrong SSL certificate which was indeed signed by a CA, the browser would not accept it since it would not contain the domain name of the website we are trying to access (google.com). CA verifies the background of a organizational before issuing a certificate.
If you are wondering if Google Trust Services is a part of the Google company then you are probably right. Does that mean it discredits the SSL certificates signed by them for their own purpose? Absolutely not.
Google Trust Services is an intermediate CA. Some organizations with a ton of websites and a ton of money would probably hesitate to contact a CA for certificate signing on daily basis. Instead, they become an intermediae CA and ask a root CA like GlobalSign to generate a certificate for them.
Using the private key of this signed certificate (which is kept private from a CA), it can sign other SSL certificates. What browsers have to do is to check for the parent CA of a certificate authority and verify the digital signature.
By walking up to the ladder up until the root CA, a browser can build a chain of trust. You can see this in the above screenshot. The GlobalSign is clearly the root CA of google.com and parent CA of GTS CA.
If any of the intermediate certificates fails, the whole trust chain fails and the website will be insecure to access or transmit data over. If everything checks out, a browser will show the green padlock icon in the status bar to indicate a trusted and secure connection.
(TLS 1.3 Handshake / source: Wikimedia Commons)
Not all browser comes with preinstalled intermediate certificates. Hence, instead of sending only one SSL certificate, a server may send a certificate bundle that contains an SSL certificate of its own and all the intermediate certificates. Only the root CA needs to be trusted to build the trust chain.
Certificate Generation Process
You can not create a certificate on your own, that?s the only rule. What you need to create is a public-private key pair and provide your public key to a certificate authority for signing and generating a certificate.
However, a standard process is to create a private key file first which ends with .key or .pem extension and create a certificate signing request file ending with .csr extension. This .csr file is then submitted to the CA.
The CA will take care of the process to generate a valid and trusted certificate. Once CA has gone through the CSR, it will validate your organization and then send a certificate file ending with .crt extension.
? This file may contain only one certificate asked for a particular domain name or a bundle of certificates which also include intermediate certificates.
Once you have your hands on the .cert file and the private key, you can configure your server to consume these files and provide a secure HTTP connection to the users who are trying to connect with your server using the HTTPS protocol.
Self-Signed Certificates
A self-signed certificate, as you can tell from the name is signed by yourself. If you are an intermediate CA, then this is the process you will follow to sell SSL certificates to your clients.
However, if you are not, then this doesn?t make any sense. When a browser downloads a self-signed certificate, it can not be linked to a valid root CA because the certificate was not signed by a trusted CA.
If a certificate is not accepted by the browser, that doesn?t mean the data is not being encrypted. You can absolutely communicate with a server securely despite some red SSL flags. But that?s not usually you should be doing.
If you have a self-signed certificate, you can install that certificate in your system/browser manually (as a trusted certificate) and the browser will stop complaining.
This also means that if you need to provide a secure and trusted communication channel for some people at your home, you can do that without having to go to a CA and pay a ton of money. Just that some people would need to work harder to make you happy.
Generating a Self-Signed Certificate
The certificate format used by the SSL/TLS protocol is X.509 developed by IETF. To generate an SSL certificate, we are going to use OpenSSL.
? OpenSSL is one of the most popular toolchains for TLS communication. It is also a command line interface (CLI) and toolkit to generate SSL certificates, private keys, CSRs and perform other kinds of cryptography operations.
First of all, we need a private key .key file and a certificate signing request .csr file. We are going to use the RSA cryptography to encrypt traffic on our server. To create these files, use the below command.
$ openssl req -new -newkey rsa:2048 -nodes -keyout thatisuday.key -out thatisuday.csr
The command above generates thatisuday.key file which is RSA 2048 bits private key file and a CSR in thatisuday.csr file which contains the matching public key.
This command asks for some input information about CSR among which Common Name is critical. This field basically tells the CA about the domain name for which a certificate has to be generated. You can also opt for a wildcard certificate.
(CSR Generation)
Now that we have a CSR, instead of submitting it to a CA, we are going to sign it ourselves using our own private key.
$ openssl x509 -req -days 365 -in thatisuday.csr -signkey thatisuday.key -out thatisuday.crt
The command above generates a thatisuday.crt certificate file that is self-signed, which also means that it has no root CA.
I am going to create a simple express server to launch an HTTPS server on Node.js. You can follow this program from the snippet below.
(https://gist.github.com/thatisuday/01657d2dfcb0120935acab4da4b1f13a)
After the server is launched using node server.js command, you can go to a browser and access thatisuday.com. But before that, map thatisuday.com to the IPV4 loopback address (127.0.0.1) in /etc/hosts.
(https://thatisuday.com)
As you can see from the above screenshot, the Safari browser does not trust this website because it does not trust the certificate. To make this work, we need to install this certificate in our system and configure it.
(Install a certificate in MacOS)
By double-clicking on a certificate file or importing inside the Keychain Access application, you can install a certificate locally. Then you can double click on the certificate to modify its trust parameters.
(Modify trust parameters of a certificate in MacOS)
Once this process is complete, now your Safari browser can get the trust parameters of the certificate from the local system. Once you reload the browser, the website should start working normally.
(https://thatisuday.com)
(thatisuday.com / GitHub / Twitter/ StackOverflow / Instagram)
