There are two components to achieve this: 1) authenticated access, 2) using HTTPS, not HTTP, at list for authentication, so no one could spy on the authentication-related traffic and later mimic the legitimate user.
Please see:
http://en.wikipedia.org/wiki/HTTPS[
^].
The use of HTTPS is based on public-key cryptography and the system of certificate authorities.
Please see:
http://en.wikipedia.org/wiki/Public-key_cryptography[
^],
http://en.wikipedia.org/wiki/Public_key_certificate[
^],
http://en.wikipedia.org/wiki/Certificate_authority[
^].
You should understand that the certificate check up has nothing to do with encryption itself. This is just a reliable way for a client side to check up that the Web service is legitimate, and not some malicious site trying to represent itself as a genuine one. The digital signature is something directly opposite to the decryption using a private key: the encryption key is uses as private, the decryption as public, that is, anyone can read the content of the certificate, no one can modify it or create an new certificate which could pass the check.
Ultimately, everything comes to using a service from some well-known and trusted certificate authority. You will need to pay fee for such service, for registration and support, per time of the usage. Alternatively, you can create and use self-signed certificate. In this case, the user should volunteer to accept such certificate. Imagine that you pass a certificate to some person hand to hand and say: "This certificate is self-signed. I'm giving you a copy of it on this flash drive (or I sent to via e-mail, if you choose to trust this e-mail). You can trust that this is my original certificate. Please install in on your system, then my code will trust it". In the client code, there is always an option to ignore certificate check up, but it's up to you to estimate the risk. For example, it can be quite acceptable if used insider some company…
—SA
Submit an article or tip