Truststore and Keystore in MuleSoft: A Beginner's Guide to SSL/TLS Certificates and Handshakes

Secure communication is key in modern integrations, and MuleSoft heavily relies on SSL/TLS protocols for this purpose. Truststores and keystores play a significant role in ensuring secure communication. This guide will help you understand what truststores and keystores are, why they're important, and what happens before and during the SSL/TLS handshake in MuleSoft.

What Is a Truststore?

A truststore is a collection of trusted certificates that a client uses to validate a server's identity during secure communication. In the context of MuleSoft, the truststore ensures that the server's certificate is from a reputable source, has not expired, and forms a valid chain back to a trusted root certificate authority (CA).

What Is a Keystore?

A keystore, on the other hand, is a secure storage for certificates and private keys. In MuleSoft, keystores are typically used on the server side to present the server's certificate during SSL/TLS handshakes, ensuring secure communication.

In a nutshell

During communication between a client and a server, the server presents its certificate (Keystore, commonly in .pfx format) to the client. The client verifies this certificate against its truststore (often a .jks file). If the certificate is valid, the client and server complete an SSL/TLS handshake, establishing a secure connection.

For example, When Mulesoft connect to a server (say amazon.in for simplicity) over HTTPS the server presents a certificate that validates its identity and Mulesoft will verify the same using the truststore configured.

However, the certificate presented by the server (amazon.in) isn't isolated—it is part of a chain of certificates that leads to a trusted authority. The typical certificate chain includes:

Root certificate

              Intermediate certificate

                             End-Entity Certificate

End-Entity Certificate
This is the server certificate issued to the website itself. It represents the identity of the website
This certificate typically contains:
1. The domain name it is issued for.
2. The public key used for encryption and digital signature verification.
3. Information about the certificate's issuer.
4. The validity period.
5. Other metadata like key usage and digital signature.
 
Intermediate certificate
This is an intermediate certificate issued by a Certificate Authority (CA).
This certificate typically
1. Acts as a bridge between the end-entity certificate and the root certificate.
2. Is signed by the root certificate, establishing a chain of trust.
3. Contains the public key, validity period, and issuer information (the root certificate).
 
Root Certificate
Is the ultimate source of trust in the certificate chain and is issued by a well-known Certificate Authority.
Root certificates are at the top of the certificate hierarchy and are self-signed.
They are trusted because they are part of the system's or application’s list of trusted CAs.

Lets talk about an end to end integration between a Client and a server via Mulesoft

Say, Mulesoft have to post some data to the target, In that case, the target's (server's) certificate has to be verified by Mulesoft. 
How? 

we will have to configure a truststore within Mulesoft "request" connector that is used to connect with the target.

How to make truststore

Step 1: Open the Website in a Web Browser
open the target endpoint in a web browser like Chrome or Edge.

Step 2: View Certificate Details
                    In Google chrome/Microsoft Edge
                    Click the padlock icon in the address bar.
                    Select "Certificate" or "Certificate (Valid)".
                    In the Certificate window, click the "Details" tab.

Step 3: Export Certificates

                    Under the "Details" tab, click on the Root certificate, click Export. Select the                         format for the exported certificate (CER, CRT PEM, or other), choose a                                 location to save the file, and complete the export process.

Step 4: Create a Truststore with Keytool
Once you've exported the necessary certificates, you can create a Java KeyStore (JKS), the format often used in MuleSoft, using a tool like keytool:

keytool -importcert -file <exported_certificate_path> -keystore <truststore_name>.jks -alias <certificate_alias>

Replace <exported_certificate_path>, <truststore_name>, <certificate_alias> with appropriate values for your setup. 

Enter a password for truststore and verify it again.

 Step 5: Configure the Truststore in MuleSoft

• 1-Way SSL/TLS: Only the server presents a certificate to the client, which verifies it for a secure connection. Common for public-facing endpoints.
• 2-Way SSL/TLS: Both the client and server exchange certificates for mutual verification, providing a higher level of security and trust. Often used in more sensitive or secure communications.

Now lets take few example to understand the handshake over HTTPS using keystore and truststore

Scenario 1 : - Client to Mulesoft

Assumptions – Mulesoft is exposing an endpoint  

Client is hitting the endpoint to get some data

Expected validation – one way

In this case, Mulesoft will be acting like a server and here Mulesoft will have to verify itself to the client
As  client is hitting  Mulesoft endpoint, we will be using a “listener“
In general-> TLS configurations, you will find “truststore configuration” and “keystore configuration”

As it is one way validation, we will be only concentrating on “keystore configuration”

In one way validation, only the server has to validate itself (In our case - Mulesoft) and client verify it using the trustore configured

what really happens in this scenario ->
1.Initiation of Connection: Client initiates a connection to a target system using Request connector via HTTPS, indicating that SSL/TLS is in use.
2.Mulesoft Sends Its Certificate: During the handshake, Mulesoft sends its certificate to client.
3.Client side Validation: Client verifies Mulesoft certificate by validating the digital signature, checking the certificate chain to ensure it leads back to a trusted root certificate, confirming the certificate's validity period, and verifying that the certificate hasn't been revoked.
4.Secure Communication Established: If the certificate passes validation, the client and server complete the SSL/TLS handshake, establishing a secure, encrypted communication channel.

Scenario 2 : - Mulesoft to Target

Assumptions – Target is exposing an endpoint 
Mulesoft is hitting it to post some data, 
expected validation – one way

Here, In Mulesoft we will be using “request” connector to connect with the target
In general-> TLS configurations, you will find “truststore configuration” and “keystore configuration”

As it is one way validation, we will be only using “truststore configuration”

In one way validation, only the target(server) has to validate itself and Mulesoft will verify it using the trustore configured

Make a truststore for the endpoint as mentioned in "How to make truststore" above

what really happens in this scenario ->

1.Initiation of Connection: Mulesoft initiates a connection to a target system using Request connector via HTTPS, indicating that SSL/TLS is in use.
2.Server(Target system) Sends Its Certificate: During the handshake, server sends its certificate to mulesoft.
3.Validation in Mulesoft: MuleSoft verifies a server certificate using the truststore by validating the digital signature, checking the certificate chain to ensure it leads back to a trusted root certificate, confirming the certificate's validity period, and verifying that the certificate hasn't been revoked.
4.Secure Communication Established: If the certificate passes validation, the client and server complete the SSL/TLS handshake, establishing a secure, encrypted communication channel.

###   Did you noticed something??   ###

In scenario 1, Mulesoft had to explicitly make a truststore and configure it in request connector inorder to verify target’s (server’s) certificate.
But in scenario 2, Did the Client explicitly made a truststore out of mulesoft certificate?? Probably Not. Also, while you hit Mulesoft endpoint via postman/browser you do not have to explicitly make a truststore certificate
Why? 

Because, Postman, like many clients, has a built-in truststore containing trusted root certificates from well-known Certificate Authorities (CAs).  Since MuleSoft doesn't have this built-in truststore, you must explicitly configure a truststore with the necessary certificates to enable secure communication.

*** What if a service/client other than Postman or web browser doesn’t have built-in truststore?
In that case, we have to convert mulesoft’s .pfx certicate either .pem or .crt or .cer and passon this public certificate to the client and ask them to make a truststore out of it and configure it at their end

Two way SSL validation  -  Client to Mulesoft   

Assumptions – Mulesoft is exposing an endpoint and a client is hitting it to get some data 

In this case, both Client and Mulesoft have to verify itself
As the client is hitting the mulesoft endpoint, we will be using a “listener“
In general-> TLS configurations, you will find “truststore configuration” and “keystore configuration”
As it is two way validation, we will have to configure both “truststore configuration” and “keystore configuration”

what really happens in this scenario ->
1.Initiation of Connection: Client initiates a connection to a target system using Request connector via HTTPS, indicating that SSL/TLS is in use.
2.Mulesoft Sends Its Certificate: During the handshake, Mulesoft sends its certificate to client.
3.Client side Validation: Client verifies Mulesoft certificate by validating the digital signature, checking the certificate chain to ensure it leads back to a trusted root certificate, confirming the certificate's validity period, and verifying that the certificate hasn't been revoked.
4.Client Sends Its Certificate: During the handshake, Mulesoft sends its certificate to client.
5.Mulesoft side validation: Mulesoft verifies client certificate by validating the digital signature, checking the certificate chain to ensure it leads back to a trusted root certificate, confirming the certificate's validity period, and verifying that the certificate hasn't been revoked.
6.Secure Communication Established: If the certificate passes validation, the client and server complete the SSL/TLS handshake, establishing a secure, encrypted communication channel.