SSL Scenario 2: Establishing Trust for Mutual Authentication 
To establish trust for mutual authentication, you must first establish server-side authentication as described in SSL scenario 1. In addition, you must also establish trust for the client side. To do this:
You must make sure the server trusts the client's public-key certificate. As with the server, the client can use either a self-signed certificate or one that has been issued by a CA. If the client's certificate is self-signed, then the server must have access to the client's certificate to verify it's identity. If the client's certificate has been issued by a CA, then the server must have access to the CA's root certificate. By trusting the CA, the server can verify the identity of many clients without having access to each client certificate. This reduces administrative overhead.
The server must be able to determine the user ID that is to be used for the connection, for example, by using a user mapping table.
See the figure below for an example for establishing mutual authentication between a Web browser client and the AS ABAP server, when using certificates that are signed by a CA. The CA root certificate that issued the AS ABAP server its certificate is imported into the trusted root CA certificate store in the Web browser. The CA root certificate that issued the Web browser client (or user) its certificate is also imported into the AS ABAP's certificate list in the SSL server PSE.
Establishing Trust Between a Web Browser Client and an AS ABAP Server (Mutual Authentication)
Note
The same process applies for the AS Java except that the certificate list on the AS Java is in the keystore view service_ssl in the entry ssl-credentials.
In addition, when a user accesses the AS ABAP or the AS Java, the server must be able to determine the user ID based on the user's Distinguished Name as contained in the certificate. For this mapping, the AS ABAP uses the mapping table USREXTID and the AS Java uses options set in the ClientCertLoginModule.