To understand how the client is also verified requires understanding a bit about how TLS works. Let's use an https connection to https://security.stackexchange.com as an example:
I connect to https://security.stackexchange.com and am sent their cert signed by Digicert Inc vouching that the cert- and the stackexchange's key I've been sent- belong to the domain stackexchange.com.
I use stackexchange's public key to encrypt data I'll send them to create symmetrical keys to encrypt our session. This ensures that the resulting keys are not compromised.
Only stackexchange can decrypt the data I sent them which was encrypted with their public key- they have the corresponding secret key.
Once the symmetrically key encrypted session has commenced, stackexchange's public key is no longer used.
SO: The result is a pair of symmetric keys: I have one, stackexchange has the same one. Since these keys were built using stackexchange's public key when passing the data, so when I now communicate with stackexchange, it could ONLY be me- unless stackexchange's secret key was somehow fatally compromised.
I could be sure stackexchange was stackexchange at the beginning of our interaction because Digicert endorsed their cert containing their public key. Stackexchange could be sure it was me because I used their Public key to safeguard the key material I passed to them to build the symmetrical keys using their trusted public key ensuring nobody in the middle could derive the symmetrical keys we would now be using.