Mutual SSL Authentication

In contrast to the usual one-way SSL authentication where a client verifies the identity of the server, in mutual SSL the server validates the identity of the client so that both parties trust each other. This builds a system that has a very tight security and avoids any requests made to the client to provide the username/password, as long as the server is aware of the certificates that belong to the client.

Before the process begins the client and servers certificates are stored in there relevant keystores. In the case of JAVA they are jks files. Let's take a look at where the JKS files are saved:

• WSO2 product certificates are stored in the wso2carbon.jks file.
• Server side certificates are stored in the clienttruststore.jks file. 
• Android agent side certificates are stored in the bouncycastle keystores(bks) files that are in the <ANDROID_AGENT_SOURCE_HOME>/client/iDPProxy/src/main/res/raw directory in the Android agent source code.  

These certificates are signed and issued by a certificate authority that allows both the client and server to communicate freely. Now let's look at how it work:

1. The Client attempts to access a protected resource and the SSL/TSL handshake process begins.
2. The Server presents its certificate, which is the server.crt according to our example as shown above. 
3. The Client takes this certificate and asks the certificate issued authority for the authenticity and validity of the certificate.
4. If the certificate is valid, the client will also provide its certificate to the server.
5. The Server takes this certificate and asks the certificate issued authority for the authenticity and validity of the certificate.
6. The Client is granted access to the resource it was trying to access earlier.