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
- Server side certificates are stored in the
- 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/rawdirectory 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 works:
- The Client attempts to access a protected resource and the SSL/TSL handshake process begins.
- The Server presents its certificate, which is the
server.crtaccording to our example as shown above.
- The Client takes this certificate and asks the certificate issued authority for the authenticity and validity of the certificate.
- If the certificate is valid, the client will also provide its certificate to the server.
- The Server takes this certificate and asks 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 adding certificates via the device management console, see Managing Client Side Mutual SSL Certificates.