Demystifying SSL Mutual Authentication

Two way SSL authentication 

In this post let's explore in detail how the two way SSL authentication works which is primarily used in application to application communication. 

To understand the secure communication between a Browser and Server read this post

Some basics:

Encryption: It's is the process of converting plain, readable data (plaintext) into an unreadable form (ciphertext) using an algorithm and a key.

Decryption: It's the process of converting encrypted data (ciphertext) back into its original, readable form (plaintext) using a decryption algorithm and a key.

Symmetric Key Encryption: In symmetric key encryption, there's only a single key and the same is used for both encryption and decryption.

Asymmetric Key Encryption: Also known as public-key encryption, asymmetric key encryption uses a pair of keys: a public key and a private key. The public key is used for encryption, while the private key is used for decryption. The data encrypted by a public key could only be decrypted by it's corresponding private key and vice versa.  

Certificate Authority (CA): A trusted entity that issues digital certificates used to verify the identity of individuals, organizations, or servers in a networked environment. E.g. Verisign

Certificate Signing Request: A Certificate Signing Request (CSR) is a message sent to a CA by applicant to get a Digital Certificate issued. The CSR contains information that will be included in the certificate, such as the applicant's public key, organization name, and domain name

Digial Certificate: CA issues a digital certificate containing the Entity's (applicant’s) public key and the CA’s signature

Keystore: A storage mechanism used to store and manage cryptographic keys and Certificates. E.g. JKS -Used in Java applications to store private keys and certificates.

Truststore: A truststore is a repository that contains a collection of trusted certificates. It is used to store and manage the certificates of external entities that are trusted by a system or application. These entities could be other servers, clients, or Certificate Authorities (CAs). The primary purpose of a truststore is to verify the identity of these external entities during secure communications

Setting up:

• Generate a keypair each for both Server and Client using tools such as keytool or openssl
• Generate Certificate Signing Request (CSR) for both Server and Client keys
• Submit the CSR to a CA. Get it verified and a Digital Certificate issued
• Install private keys of corresponding entities in its keystore. For example, server's private key gets installed in Server's keystore
• Install the Digital Certificate issued by the CA in the corresponding entities keystore.
• Install the CAs own Certificate in both the Server and Client's Truststore

The final setup will look as in the picture

How authentication works:

The authentication working mechanism is simplified for brevity. 

• When establishing connection (authentication) both Server and Client exchanges its Digital Certificates. 
• Both entities verifies if the other entity's Certificate is signed by (issued by) a CA which it trusts, meaning it has the corresponding CA's Certificate installed in it's Truststore
• With the SSL/TLS handshake completed, both the client and server use the session keys generated during the key exchange to encrypt and decrypt the data transmitted between them, ensuring secure communication

Detailed Sequence of all steps:

SSL/TLS communication between Browser and Server

SSL/TLS Communication Between Browser and Server Demystified

Have you ever wondered how a browser communicates securely with a server, safeguarding sensitive data from prying eyes? In this post let's demystify the process of establishing a secure communication channel using SSL certificates, now being called TLS. Let's keep things simple, avoiding overly technical jargon for easy understanding

SSL Certificate - for Server: An SSL certificate for a server comprises crucial elements: a private key, a public key, and identity information like the server's domain. During the establishment of a secure connection, the server presents its public key in the form of a certificate to the browser. However, for browsers to trust this certificate, the public key must be certified by an authorized Certificate Authority (CA)

Certificate Authority (CA): A Certificate Authority (CA) is a trusted entity responsible for signing public keys and issuing them in the form of digital certificates. The CA maintains a pair of private and public keys, with the private key kept securely confidential. When an entity requests certification, the CA uses its private key to sign the entity's public key. This process ensures that the digital certificate certifies the ownership of the public key by the named subject of the certificate. Before signing the public key, the CA conducts necessary verification to confirm the identity of the requesting subject

Process of obtaining a Server certificate and getting it certified by CA:

1. Create a Key Pair: Generate a pair of cryptographic keys consisting of a private key and a corresponding public key. The private key remains confidential and is used for encryption and decryption, while the public key is shared openly for encryption
2. Create a Certificate Signing Request (CSR): Generate a CSR file that includes the public key along with essential information about the entity, such as its domain name and organizational details
3. Submit the CSR to a Trusted CA: Send the CSR to a trusted Certificate Authority for verification and certification. The CA will validate the information provided in the CSR and authenticate the entity's ownership of the domain
4. CA Verification and Certificate Issuance: Upon receiving the CSR, the CA performs necessary verification procedures to ensure the authenticity of the entity. If the verification is successful, the CA signs (certifies) the public key and issues a digital certificate to the entity. This certificate contains the entity's identifying information, along with the CA's digital signature, confirming the certification of the public key
5. Use of Certified Public Key: With the issued certificate, the entity now possesses a CA-certified public key, which can be used to establish secure communication with clients. The certificate provides assurance to clients that they are connecting to a legitimate and verified server

 

Once the CA signs the server's public key, both the private key and the CA-certified public key are installed in the server's keystore. The keystore is a repository that securely stores cryptographic keys and certificates for use in SSL/TLS communication.

Additionally, the CA issues its own certificate, which serves as identification for the CA. For a Browser to trust the Server, the CAs own certificate needs to be present in the Browser's truststore as well. The truststore is a repository of trusted certificates, including those of CAs, used by the browser to verify the authenticity of certificates presented by servers during SSL/TLS communication.

By installing the CA certificate in both the server's keystore and the browser's truststore, a secure chain of trust is established. This ensures that when the browser receives a certificate (Server's public key) from the server during SSL/TLS communication, it can verify the certificate's authenticity by checking if it is issued by one of the CAs whose CA certificate is present in its truststore

 How Browser establishes a secure connection with Server

• Browser initiates a secure connection with the server
• The server returns its certificate that contains the public key
• The browser verifies whether the server's public key is signed by one of the CAs whose CA certificate is installed in its truststore
• The browser also verifies that the server's domain matches the domain name in the certificate
• If the verification is not successful, like the Server's public key was not signed by a CA whose Certificate is present in the Browser's Truststore or the Client's Certificate is expired then Browser throws a warning
  
• If the verification is successful, the browser generates a pre-master secret, a random value
• The browser sends the pre-master secret, cryptographic algorithms to be used, protocol version, etc., to the server. This information sent by browser is encrypted with the server's public key
• Server decrypts the information sent by Browser using its private key
  
• From the pre-master secret and additional information, both the server and the browser derives a session key
• The session key is used to exchange data between the client and the server
• The session key is a Symmetric key, ensuring secure communication