The client proves possession of the private key by signing a hash of the TLS handshake. The relevant section of RFC 5246 is 7.4.8, and a plain English explanation can be found here. So the communication is, roughly:

1. Client sends hello
2. Server sends hello, including server certificate chain and list of accepted client certificate issuers
3. Client sends certificate
4. Client sends key exchange message
5. Client sends certificate verify, a signature over all previous steps

Server then verifies that the signature is correct and the certificate is valid. So now the server can be sure the client is in possession of the private key and proceeds to match the CommonName, or a specified SAN field (e.g. DNS, RFC822, UPN) against its user database.

The client proves possession of the private key by signing a hash of the TLS handshake. The relevant section of RFC 5246 is 7.4.8, and a plain English explanation can be found here. So the communication is, roughly:

1. Client sends hello
2. Server sends hello, including server certificate chain and list of accepted client certificate issuers
3. Client sends certificate
4. Client sends key exchange message
5. Client sends certificate verify, a signature over all previous steps

Server then verifies that the signature is correct and the certificate is valid. So now the server can be sure the client is in possession of the private key and proceeds to match the CommonName, or a specified SAN field (e.g. DNS, RFC822, UPN) against its user database.