{{announcement.body}}
{{announcement.title}}

Two-Way SSL Authentication Setup in Mule

DZone 's Guide to

Two-Way SSL Authentication Setup in Mule

In this post, we will set up a two-way SSL from CA-signed certificate hosted as a server and a client-server and demonstrate the connectivity between client and server.

· Security Zone ·
Free Resource

What is Two-Way SSL?

Two-way SSL means that a client and a server communicates on a verified connection with each other. The verifying is done by certificates to identify. A server and a client has implemented a private key certificate and a public key certificate.

Two-way SSL representative:

Two-way SSL

Let's get into a demonstration on how the client and server setup is done and could be used in real-world case scenario.

We will proceed with the below steps:

  • Create a server setup.
  • Integrate it with Mule and deploy it locally.
  • Create a client setup.
  • Import client public certificate(.crt) to server truststore.
  • Import server public certificate(.crt) to client truststore.

Create a Server Setup

  1. Generate a CSR along with private Key.
    openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr  (It will prompt some questions like country name, organization etc.)
    Note: Please make sure you provide a proper common name(Common Name (your name or your server's hostname))
    You can view and verify the information contained in the CSR
    openssl req -noout -text -in server.csr 
  2. Either you can Self-Sign the certificate or provide your CSR to Authorised (Skip this step if you are not self-signing it)
    openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crtFor CA-signed, an Approved Authority will provide you the .crt file
    Note: Two-way SSL will only happen on CA-signed certificate
  3. Create a JKS file using .crt file and private key
    You must generate a p12 file which comprises of private and .crt file
    openssl pkcs12 -export -in server.crt -inkey server.key -certfile server.crt -out server.p12 
    Now you must generate jks using a p12 file.
    keytool -importkeystore -srckeystore server.p12 -srcstoretype pkcs12 -destkeystore server.jks -deststoretype JKS 
    Change the alias server.jks. Above command set the alias for server.jks to 1. To rename it use this command:
    keytool -changealias -keystore server.jks -alias 1 
  4. Add the JKS to your Keystore and deploy your API using HTTPs
    You can view your certificate through the browser. It would be unsecure for self-signed and secure for CA-signed
    You can view your certificate through a browser. It would be unsecure for self-signed and secure for CA signed. Now you will have the below files generated:
    1. server.crt
    2. server.csr
    3. server.jks
    4. server.key
    5. server.p12

Integrate It with Mule and Deploy Server Application

  1. Create a new application in Mule.
    Create new Mule app
  2. Drag and drop an HTTP listener, set the protocol as HTTPS, and add the JKS file which we have created in the previous step.HTTP Listener configNote: I have not included any trust store because we have not setup any client until now. We will see in the next step.
  3. Add a Set Payload and run it locally.
    Set Payload
  4. You can check the certificate detailsCertificate details

Create Client Setup

  1. Perform the same step as we did for the server setup. But this would be on the client end.
    You will have the below files generated for the client:
    1. client.crt
    2. client.csr
    3. client.jks
    4. client.key
    5. client.p12

Import Client Public certificate(.crt) to Server Truststore

In order to access the server API, we need to request serve to add client public certificate(client.crt) to server truststore. If we miss this step we will get SSL Handshake failure. Please follow the below command to add client public certificate to truststore and deploy that application on cloudhub/onprem.

  1. Import client.crt to server truststore.
    keytool -import -alias client-cert -keystore client-truststore.jks -file client.crt
  2. Import the truststore to your demo-server API and deploy it on Cloudhub/Onprem.
    HTTP Listener configThe application will get deployed and if you try to hit the endpoint you will get an error as SSL handshake error: null cert chain. This is because you are trying to hit it directly and not using client certificate.
  3. Create a demo-client application and try to consume server payload
    Project settings
  4. Add HTTP listener and HTTP request (which points to your demo-server)HTTP listener and request
  5. Add client keystore to HTTP request, so server can validate and allow access to client.Adding client keystore
  6. Since we have already added client public certificate to server keystore. It will provide a response from server.
    Server response

Import Server Public certificate(.crt) to the Client truststore:

This demonstrates one-way SSL as it only shares the client public certificate to server. To achieve two-way SSL, add the server public certificate to client truststore. Perform the below steps:

  1. Generate truststore from server.crt
    keytool -import -alias server-cert -keystore server-truststore.jks -file server.crt 
  2. Add server-truststore.jks to truststore of demo-client
    Adding server-truststore.jks
  3. Once you add the truststore, deploy your project locally to test the connectivity.
    Test connectivity

This is how two-way SSL works. In real-world case scenarios we only do configuration either on the server-side or client-side. I hope this example would help you to configure two-way SSL. 

Topics:
cloudhub, keystore, mule, mule 4, mule tutorial, onprem, securing apis, security, ssl, truststore

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}