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 need of the username/password to be presented from the client, as long as the server is aware of the certificates that belongs to the client.

Let's take a look at how it works:

Before the process begins the client and servers certificates are stored in there relevant keystores, in the case of JAVA these are jks files. WSO2 products certificates are stored in the wso2carbon.jks and the clienttruststore.jks in server side while the Android agent side certificates are stored in bouncycastle keystores(bks) files that are in the 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 communicating freely.

The Client attempts to access a protected resource and the SSL/TSL hand shake process begins.
The Server presents it's certificate, which is the server.crt according to our example as shown above.
The Client takes this certificate and ask the certificate issued authority for the authenticity and validity of the certificate.
If the certificate is valid, the client will also provide it's certificate to server.
The Server takes this certificate and ask the certificate issued authority for the authenticity and validity of the certificate.
The Client is granted access to the resource it was trying to access earlier.

For more information on managing the certificates via REST APIs, see Client Side Mutual SSL Certificate Management via the Console.
For more information adding certificates via the EMM console, see Working with Certificates.