One-way SSL
In one-way SSL, the server alone presents the certificate to the client and the client doesn’t provide any certificate to the server to prove the identity. For e.g. when a user does a transaction with ebay.com, it is the server who has to prove its identity to the client; hence the server has to be secured with the certificate and present it to client. The modern browser clients will accept the certificate and show the status in green if the certificate is signed by public CA and is valid. If it is a self-signed certificate or signed by private CA, then the browsers will show the warning.
Two-way SSL
In two-way SSL, both the server and the client proves their identity by exchanging the certificates. This type of security is mostly needed where both the server and the client needs to establish their identities to each other. By exchanging the certificates, both the client and server proves their identities. The digital certificate is used as the identity and this digital certificate should be signed by the Certificate Authority. The Force.com platform only supports certificates signed by public CA such as Verisign, DigiCert, Thawte, etc, when making HTTP/REST/WSDL requests to third party/enterprise server(s). A complete list of the public CA that Force.com platform supports can be found in the saleforce wiki. When making outbound web service callouts, the Salesforce can use either, a certificate signed by public CA or self-signed certificates to present it to the third party/enterprise server(s). We will cover more on this later.
link - https://krishhari.wordpress.com/2012/02/04/making-authenticated-web-service-callouts-from-salesforce-to-ibm-cast-iron-using-sslcertificatespart-i/
link - https://krishhari.wordpress.com/2012/02/04/making-authenticated-web-service-callouts-from-salesforce-to-ibm-cast-iron-using-sslcertificatespart-i/