The client knows that the server is who it says it is, because it has the private key corresponding to the public key in a certificate signed by a trusted third party (i.e. for HTTPS, a certfication authority).

Client certificates can be signed in the same manner, and provide secure authentication in the other direction.

Each party has a private key and public key - their public key is embedded in a signed certificate. The protocol is such that it is difficult for someone without the private key to impersonate them (For difficult, read: as difficult as brute-forcing the private key).

---

Some SSL setups, for example, SSH, rely more on individually trusted public keys than a central CA. So the client and/or server, keeps a list of trusted public keys, and anyone who has the private key which goes with the public key, is let in.

---

The basis of the entire system, is that the public/private keys are asymmetric, i.e. if you encrypt something with one, it must be decrypted with the other. So if A wants to know that B is who they say they are, they encrypt something with B's public key, and B needs their private key to decrypt it. Or vice versa. B encrypts something with their own private key, and anyone with their public key can decrypt it, thus proving that it must have been encrypted by someone in posession of B's private key.

SSL systems normally use a symmetric cipher for the actual encryption though, with a randomly selected session key which is sent securely at the beginning of the session.

Symmetric encryption is much quicker than asymmetric, so it's usually used for large amounts of data.

Slarty