Introduction and Deep Dive to One-Way SSL Authentication in MuleSoft

Published in

Another Integration Blog

8 min readFeb 1, 2023

Purpose of this article is to give some high-level idea about how the SSL/TLS Protocol works and how we can make a use of one-way SSL handshake over a HTTPS protocol in MuleSoft. But before directly jumping on one-way & two-way (MTLS) authentication mode lets understand some basic concepts about TLS/SSL protocol, what is encryption & how symmetric and asymmetric encryption works and what is digital certificates.

What is TLS protocol and why it is required?

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible (e.g. web packages and servers, including a web browser loading page).

TLS protocol uses Digital Certificates which will be configured on Client and Server side to secure (encrypt/decrypt data) the communication over a transport layer.

Reference — Transport Layer Security — Wikipedia

Now we understand that what TLS protocol is, before jumping on how Data Protection works over TLS protocol lets understand about the symmetric and asymmetric encryption.

What is Symmetric and Asymmetric encryption and how it works?

What is encryption and decryption?

In cryptography, encryption is the process of encoding information. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Ideally, only authorized parties can decipher a ciphertext back to plaintext and access the original information that process is called as decryption.

Reference — Encryption — Wikipedia

Symmetric Encryption

**High-Level Diagram: — Encryption with Symmetric Key**

In symmetric encryption a single common key would be used for data encryption and decryption. Common key is also referred as a symmetric encryption key.
The key must be shared among the parties involved (in this case client and server, as shown in above diagram) who wish to encrypt and decrypt data.

The key involved must be protected and transferred securely. If the key is lost, then the data cannot be decrypted, and if the key gets compromised, that will compromise the encryption.

Asymmetric Encryption

**High-Level Diagram: — Encryption with Asymmetric Key**

Asymmetric encryption uses two separate keys which are mathematically involved with each other. The first key is called private key and the second one is called public key.
Public key is used to encrypt the data and private key is responsible to decrypt the data. Usually, data receiver party will generate the key’s and share only public key with client (data producer).
Hence the private key is the one that is heavily protected. The public key is derived from the private key and can be distributed. A certificate is often created with a public key containing information about the key’s owner and a few details about the key itself.
Using a private key, we can find the public key, but the private key cannot be obtained using the public key.

Even though asymmetric encryption provides more protection to the keys, they are comparatively slower than symmetric encryption. For this reason, asymmetric encryption is often used to exchange the secret key, which can be used to establish symmetric encryption for faster data transfer and make encryption and decryption of the data faster.

How the TLS Works (High-Level)

**High-Level Diagram: — Data Protection Over TLS Protocol**

As shown in the diagram, client initiates the request to server and server respond back with it’s asymmetric public key/certificate to client.
Client validates server’s public certificate either with CA (Default JRE truststore) or with custom truststore (in case of Self-signed certificate)
Client generates a session key (a random string) and encrypt that with server’s public key.
Client send’s encrypted session key to server.
Server decrypt the session key using its private key.
Now both server and client have access to symmetric session key, and for further communication both parties will use this symmetric session key to encrypt and decrypt the data.

There are few more interaction happens between client and server where they decided which TLS version, cipher suites (algorithm to encrypt/decrypt data), etc.. to use. To understand this interaction, you can refer some detail level blogs around the TLS/SSL process.

What is Digital Certificate, Truststore and Keystore?

Digital Certificates are Public/Private key Signed by Certificate Authority (CA) or self-signed certificate, used of communication over a TLS/SSL protocol. With this client and server can identify each other authenticity.

Self-Signed Certificate — A Self Signed Certificate is not signed by a trusted Certificate Authority but instead is signed with its own private key. The purpose of a certificate is to provide trusted validation of identity or provide public keys for asymmetric encryption.

CA signed Certificate — A CA signed certificate is a certificate that has been issued and signed by a publicly trusted certificate authority (CA).

It is recommended to always use CA signed certificate, but self-signed certificate can be used for non-prod environment or internal services.

This private key, public key (certificates) and sysmmetric key can be stored in Keystore and Truststore.

Keystore can be a repository where private keys, certificates (public keys) and symmetric keys can be stored. This is typically a file.

Truststore can be repository where certificates (public keys) can be store. This is typically a file

Both “keystore” and “truststore” are keystores, they’re just used for different purposes. Keystore mostly hold both private and public key and truststore holds the public key’s

One-Way SSL Handshake

In one-way SSL authentication, the server application shares its public certificate with the client. Client verifies the server certificates. At the server end, there will be a Keystore that will hold the private and public certificate of the server whereas, at the client end, there will be a truststore that will hold the public certificate of the server.

If the certificates are CA-Signed Certificate then client don’t have to configure the truststore as the certificate will get validated in the default JRE truststore.
If the certificates are Self-Signed Certificate then client needs to create a custom truststore and import the server certificate into that truststore.

In below sections we are going to talk about the One-Way SSL with CA-Signed and Self-Signed Certificate. And explain how to configure One-Way SSL in MuleSoft with Self-Signed Certificates.

CA-Signed Certificate

As we can see in above diagram the server public certificate is CA-Signed Certificate so custom truststore at client side is not required.

Self-Signed Certificate

As we can see in above diagram the server public certificate is Self-Signed Certificate so custom truststore at client side is required.

Steps To Generate Self-Signed Certificate

Generate Server Keystore

keytool -genkey -alias server -keysize 2048 -keyalg RSA -keystore server-keystore.jks

Once the command executed in CMD you will see above information in CMD console, type in yes and press enter. You will see the keystore is generated successfully.

If keystore is generated in the PKCS12 format, then you can either add a storetype attribute in above command or make a use of below command to convert the type of keystore from PKCS12 to JKS.

keytool -importkeystore -srckeystore server-keystore.jks -destkeystore server-keystore.jks -srcstoretype PKCS12 -deststoretype jks

Now it’s time to export the public certificate from the server keystore file, use below command to perform this activity.

keytool -export -alias server -keystore server-keystore.jks -file server-publickey.crt

Now this public certificate (only public certificate) needs to share with the client team.

Generate Client Truststore

Once client team has received the server’s public certificate, same needs to be configured on the client custom truststore. To fullfil this steps need to make a use of below command and generate the trustsore.

Use below command to create a truststore

keytool -genkey -alias clientts -keysize 2048 -keyalg RSA -keystore client-truststore.ts

Add server public certificate in client truststore

keytool -import -alias server-publickey -keystore client-truststore.ts -file server-publickey.crt

Configure the keystore and truststore in MuleSoft.

Server Configuration

Place the Keystore under server application’s resource folder.

Configure the Keystore in server HTTPS listener configuration.

Client Configuration

Place the truststore under client application’s resource folder.

Configure the truststore in HTTP requester.

Before running the application I have enabled the SSL logs in the log4j file on local, below is the high-level snapshot of those logs message. Which shows how the connectivity established between client and server.

**Server Response to Client’s Hello Message**

Once client validates server identiy with certificate present in client truststore all other interaction takes place with client and server with TLS hello message. Once the symmetric encryption key available in both client and server side one last data verification message will be seen in console as shown in above diagram.