There is typically no private key on the client side.
At a high level the process goes something along the lines of (this is a simplification, read the protocol specs if you want the fine details)
The client sends the server a "hello" message with info on supported protocols and ciphersuites.
The server chooses a cipersuite and protoocol version and sends the client details of the ciphersuite and sends it's certificate. The server is suppose to respect the clients ciphersuite preferences, but not all servers do.
The client validates the certificate using the certificate chain to decide whether it is talking to the right server.
The client and server agree a master shared secret for the session and the client validates that the server it is talking to holds the private key for the certificate. Theres a couple of ways this can be done, the simplest is that the client generates the secret, encrypts it using the server's RSA public key and sends it to the server which decrypts it using its private key. The downside of that approach is it doesn't provide "forward secrecy". An alternative approach, is to use ephemeral diffe-hellman key exchange (or it's elliptic curve variant) to agree on a secret and use RSA signatures to validate that the key really was agreed with your server (and not agreed with a man in the middle). Most modern clients prefer the elliptic curve diffe-hellman ciphersuites.
Session keys are generated from the master shared secret and encrypted communication begins using a symetric cipher and those sesion keys.