While there are multiple security implementations in enterprise systems with distributed architecture, including authentication, authorization, and role-based access, one of the preferred and secured way of establishing the system integration is through a two-way SSL. In this concept, both the client and server shake hands by sending the expected and known Domain Name System (DNS)-named certificates (server certificate and client certificate) and confirming the system protocol before exchanging any information. Once the known system encryption is established, they start exchanging the information, which is a secured way of communication. The following diagram represents the SSL/Transport Layer Security (TLS) handshake mechanism between a client and server:

Let's review the steps involved in the SSL/TLS Handshake process here:

• ClientHello: In this stage, the client application invokes the server with the details of the highest version of SSL it is supporting and a list of the cipher suites it can support (TLS 1.0 is represented by SSL 3.1). Cryptographic algorithms and key sizes are included in the cipher suite details.
• ServerHello: In this stage, the server selects the highest version of SSL and the best cipher suite that both the client and server support, and confirms the details with the client.
• Certificate (Optional): The server sends the client a certificate or a certificate chain. It may include the server's public-key certificate, the authority-root certificate, and so on.
• CertificateRequest (Optional): If the server authenticating the client is enforced, then the server sends a certificate request to the client.
• ServerKeyExchange (Optional): The server sends a server key exchange message to the client, if the public-key details from the certificate are not enough for the key exchange.
• ServerHelloDone: The server confirms to the client that the initial conciliation is completed.
• Certificate (Optional): The client sends its certificate chain if the server requests one.
• ClientKeyExchange (Optional): The client produces the details submitted for key generation and symmetric encryption. The client then encrypts this key information with the server's public key and sends it to the server for RSA.
• CertificateVerify (Optional): When this message is used along with the certificate that the client sends the server, the client sends details that it digitally signs using a cryptographic hash function. When the server decrypts this detail with the client's public key, the server can authenticate the client.
• ChangeCipherSpec: This message from the client to the server confirms that the server can change to encrypted mode.
• Finished: This message from the client to the server confirms that the protocol is ready for secure data communication to be established.
• ChangeCipherSpec: This message from the server to the client confirms the client to change to the encrypted mode.
• Finished: This message from the server to client confirms that the protocol is ready for secure data communication to establish, and this concludes the SSL handshake process.
• Encrypted Data: During the SSL handshake, the client and server interact with symmetric encryption and cryptographic hash function with the secret-key. This is sent by the client to the server in the client-key exchange stage. This process can be repeated during the renegotiation stage.
• Closed Messages: Once the communication is completed, the server and client pass close_notify message to each other to confirm that the connection is closed.

In general, the secured two-way SSL protocol observes a slight degradation of performance due to this process. The details shared as parameters in SSL handshake can be stored and reused in future handshake to improve the performance.

The two-way SSL communication can be established in multiple communication channels, including Java message service and web services.

For implementing the two-way SSL, the first step is to procure the right set of certificates along with the DNS. This can be achieved with a number of tools and providers such as Venafi.

The KeyTool is a key and certificate management utility for generating and administering the private and public key pairs and associated certificates with the SSL security protocol. It uses a file called KeyStore to stores the keys and certificates, which are secured with a password.

Check the following Oracle document for more information about using the KeyTool utility:

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html