[Part 2] Mule 4: Using SSL/TLS
This is the second part of the series in learning how to configure the Mule Application to use One Way SSL and Two Way SSL.
Join the DZone community and get the full member experience.
Join For FreeThis is the second part of the series in learning how to configure the Mule Application to use One Way SSL and Two Way SSL.
In the first part, SSL/TLS Concepts were covered. In this second part, we are going to understand One Way SSL / Two Way SSL and then configure it for Mule Application (using self-signed certificates).
Let's first understand One way SSL and Two way SSL and then we look into the configuration in Mule Application.
One Way SSL
Let’s understand One Way SSL –
- Client makes an HTTPS call to access Server resource
- Server is configured with KeyStore and it retrieves its certificate from the KeyStore
- Server sends its certificate to the client
- Client uses its TrustStore to verify Server Certificate.
- The Server certificate has public key of the server along with other information
- Client generates a session key(some unique/ random key )
- Client encrypts this session key with public key of server and sends this encrypted session key to the Server
- Server gets this encrypted session key and decrypts this key using its private key
- Both Client and Server has the same session key now
- So during SSL Handshake process, the certificate is presented/verified and session key is negotiated.
- After SSL Handshake, the communication between client and server is as follows -
- Client sends the data to the server by encrypting this data with the session key. Server decrypts the data using same session key
- In the same way when server needs to send data to client, it encrypts the data with the same session key .Client receives the encrypted data and decrypt it using same session key
Now , lets talk about checking the identity of Client and Server.
In One Way SSL, Client checks the identity of Server and then there is encrypted communication between client and server. Client’s identity is not checked by Server .Any client can communicate with the server after verifying the identity of the server.
But sometimes the requirement is to verify client also. In such cases we use Two way SSL.
Two Way SSL
- In Two Way SSL, the identities of both client and server are verified.
- Both Server and Client have its own key store and trust store.
- Client is configured with the KeyStore to access its keys/certificates and Trust Store to verify server certificates.
- Server is configured with the KeyStore to access its keys/certificates and Trust Store to verify client certificate.
- Client makes an HTTPS call to access Server resource
- Server receives the client request, retrieves server certificate from KeyStore and sends to the client.
- Client gets the server certificate and verifies this certificate with the help of client Trust Store.
- After verification, client retrieves its own certificate from client key store and sends it to the server.
- Server receives client certificate and verify this certificate with the help of Server Trust Store.
- Once verified, client generates a session key , encrypt this session key using server’s public key(retrieved from server certificate) and send the encrypted session key to server
- Server receives the encrypted session key and server decrypts this session key using server’s private key
- After this SSL Handshake, whenever the data is exchanged between client and server, data is encrypted by this session key from one side and decrypted using same key at another side.
- So in this case both client and server are verifying the certificate and authenticating each other.
In One Way and Two Way SSL, SSL Handshake is done using public/private key pair (Asymmetric Encryption), and session key is negotiated. Then session key (symmetric Encryption) is always used for further encryption and decryption of data between client and server
In the above explanation, we have discussed the steps as per RSA algorithm.
Generating keys/Certificates
In this section, we will generate private keys and self-signed certificates. Next, we will import these certificates in the trust store.
First install JDK and set the PATH to JAVA_HOME. Please refer to Oracle documentation for installation and setting the environment variables.
keytool
keytool is a utility to manage keys and certificates.
There are many keytool commands for example :
- -genkeypair ,
- -exportcert ,
- -importcert
All keytool commands and it's option names are preceded by a minus sign and these options can be provided in any order.
Generate Server KeyStore
Use -genkeypair command to create private key and public key.Public Key is wrapped in a self-signed certificate.
options:-
-alias:- private key and certificate are stored together as a keystore entry . This entry is identified using a unique string known as alias.We have specified myserver as the alias in this example
-keyalg:- Algorithm used to generate the key pair. RSA is used in this example.
-storetype:- Keystore type like JKS , PKCS12 etc. . JKS is used in this example
-keypass : specify key password
-storepass: specify keystore password
Once we run the above command, we will be prompted with some questions.
In the answer to the first question, "what is your first and last name? - specify "localhost" or Full qualified name of server like hostname.domain.com
If keystore does not exist when you run this command, the keystore will be created.
Generate Client KeyStore (required in case of 2-way SSL)
Create client private/public keys. The generated key and self-signed certificate will be store in the client keystore.
Export Certificate from Server KeyStore
Use –exportcert command to retrieve the certificate from the server keystore. The certificate associated with a specific alias is retrieved.
options:-
-keystore:- Name of the keystore from where we want to retrieve the certificate
-storepass:- Password of the specified keystore
-alias:- alias name of the keystore entry
-file: name which you would like to specify for your retrieved certificate
Export Certificate from Client KeyStore (required in case of 2-way SSL)
Use –exportcert command to retrieve the certificate from the client keystore.
Import Server Certificate to Client TrustStore
Use -importcert command to store server certificate into client truststore and specify an alias for the entry.
options:-
-file : Name of certificate file which you want to import to truststore
-keystore: Name of your trust store
-storepass: password of your trust store
-alias: alias name of the entry
Answer yes when you are asked - Trust this certificate?
Import Client Certificate to Server TrustStore (required in case of 2-way SSL)
Use –importcert command to store client certificate into server truststore and specify an alias for the entry.
Next, lets configure one-way SSL and two-way SSL (with self-signed certificates) using Anypoint Studio.
Configure SSL/TLS in Mule Applications
One Way SSL
Server Application
Let's look into a simple flow of Server application -
This flow has an HTTP Listener with path /server listening on port 9091 with a Set Payload transformer which sets the payload as- hello from server
Declare HTTP Listener configuration with the protocol as HTTPS (in general tab) as shown below:-
In TLS Tab, Select Edit Inline. Once you select the edit inline, you can set the KeyStore Configuration-
The serverKeyStore.jks is placed in the src/main/resources.
The configuration above shows: -
KeyStore type is specified as JKS and path has Server keystore name(no need to specify src/main/resources). The alias, Key password, and store password are also specified.
The Server Application will use this KeyStore to retrieve its certificate (based on alias) to send it to the client application.
TrustStore Configuration is not required at the server end in the case of One Way SSL
Run the Server Application and test it using browser (you will see the error):-
We get this error as the certificate is a self-signed certificate and not signed by Trusted CA. This certificate is not shipped with OS/browser.
Click on Not Secure sign from the browser location bar
Click on Certificate to view this certificate –
Notice certificate information – This CA Root Certificate is not trusted. The self-signed certificate is considered as a Root CA certificate and the owner is considered as the Root CA.But this is not a trusted CA.
So how to resolve this. A certificate has to be installed in the operating system/browser. This article does not cover this scenario. Going further in this article, we will create a client mule application that uses the trust store that has the server's certificate.
As of now, we will just click on Advanced and then we will click on continue. This will show us the payload provided by the server application -
Next, let's create a client application that uses the trust store where this server certificate is imported. In this case, when the client is presented with the Server application's certificate, the client will trust the certificate.
Client Application
Let's create a simple Client flow. This flow consists of an HTTP Listener and HTTP Request. In General Tab of HTTP Listener Config, the port is specified as 8081, and protocol is selected as HTTP (not HTTPS) -
Next, we will configure HTTP Request Configuration.
In this configuration, we Select the protocol as HTTPS as we know that client is making an HTTPS request to the server. Then we specify the host and port of Server application -
In the TLS tab, Select Edit Inline from TLS Configuration dropdown and configure Client Trust Store -
In the configuration, we have specified Path (only trust store name is specified as clientTrustStore.jks is stored in src/main/resources so complete path is not required to be mentioned), Trust Store password and Type as JKS
Client will be using this trust store to verify the Server Certificate when the certificate is presented to client.
Let's continue with HTTP Request Configuration where we Set the path as /server -
Lets run server and client applications and then call the client application using browser and we will see that Server has sent the information to the client which is displayed over browser. Client and Server has done SSL Handshake and client application has displayed the data sent from server.
Two Way SSL
Server Application
Let's look into Server Application which has the same flow - an HTTP Listener and a set payload. In the HTTP Listener config, select the protocol as HTTPS as before.
In TLS Tab of HTTP Listener config, we will click Edit Inline( we will configure both keystore and truststore now) -
Server Application uses KeyStore to retrieve its own certificate to present to Client and it uses TrustStore to verify Client Certificate
Client Application
Lets look into client application which has the same flow with http listener and http request
In the HTTP Request configuration, we have selected HTTPS and we have also configured server path,port etc.
Lets change the TLS Configuration for HTTP_Request_configuration
In this configuration, both trust store and key store are configured. Client will use keystore to retrieve its own certificate to present to server and will use truststore to verify server certificate.
Run Client and Server applications and access the client application from browser. You will get the details sent by the server on the browser.
In this article, we have looked into how to configure one-way and two-way SSL with Mule Applications. In the next article, we will cover how to get certificate signed by CA.
I hope you find this article useful.
Good resources/references for learning these concepts -
Opinions expressed by DZone contributors are their own.
Comments