In Part 1 we cover the basic of SSL, PKI. CA. In Part 2 we covered truststore and identitystore. I classify the HTTPS – SSL communication in 2 sub types.
1. 1 way SSL
2. 2 way SSL
They are not 2 types but i call them as such. The protocol wise there are minor variations but from setup perspective there is lot of difference between 2.
1 Way SSL
This most commonly used for consumer to business communication. When I launch my bank’s website to login into my account, it is 1 way SSL.
In this case we (the client) wants to validate the server’s certificate, to make sure it talking to right server \ entity. The server verifies the client’s identity using username and password.
In this case, client will have to add server certificate or signing CA (CA that singed server’s certificate) to its truststore. In case of banking example, most bank has cert signed by well known CAs, and certificate for these CAs are already in the browser.
2 way SSL
This mostly used for server to server communication.
In case, let say entity 1 is server and entity 2 is client. So when client entity 2 connects to server entity 1, it will provide it’s certificate to client, but also ask \ challenge client to provide its certificate. So client certificate instead of username \ password is use to authenticate client identity. So in case client also has to have certificate for itself.
So client will have to include server’s certificate or singing CA in its truststore. Similar server will need to have client’s certificate or signing CA in its truststore.
So when debugging SSL issue you need to first understand whether you communication is 1 way ssl or 2 way ssl. Based on sub type right certificate are in right keystore file.
If i have customer facing website i cannot expect everyone to have certificate generated by verisign to validate their identities, i would use 1 way SSL there. If its back end service i can use using user name \password or 2 way SSL for authenticating client identity.