Welcome to security.stackexchange.com. I think you have a few misunderstandings of how certificates are created, issued, served, and verified.
the client obtains an X509 certificate from a trusted third-party CA
No. The client obtains the certificate from the server when it connects to the server by https.
In this certificate, there is a public key given by the CA which can be validated by the server to come from CA)
No. The CA does not issue the public key. To do that, the CA would also have to know the private key, which would mean that it is no longer private. Only the server knows the private key.
and there is a private key which is stored locally on the client.
In most cases, No. Unless the client is using a client certificate (which is not very common) the client does not store a long-term private key, like the server does.
Let's clarify the above before we move on. Here's how it works: The server creates a key pair (consisting of a private key and a corresponding public key). Then the server creates a certificate signing request (CSR), which contains information about the server (such as the FQDN of the server), and the public key. The server then sends the CSR to a CA, and the CA creates a certificate from the CSR and signs the certificate. The CA signature on the certificate is to indicate that the CA verified the the server 'is who it says it is' (how they do this is another questions). Then, the CA sends the signed certificate back to the server. At this point, the CA is no longer involved.
When a client connects to the server by https, the server sends the certificate. The client checks that the certificate is signed by a CA that the client trusts, and if so, the client proceeds with TLS, using the server's public key contained in the certificate. Importantly, in order for the TLS connection to succeed, the server must have the private key that corresponds with the public key in the certificate.
From my understanding, the only use for the X509 certificate is to verify that a message from client to server can be verified by the server to have come from the client through a digital signature, and there is no encryption that is performed on the message content aside from that required for signing.
No. SSL/TLS provides the three fundamentals needed for any encryption system: secrecy, authenticity, and integrity. Messages sent between the client and the server are encrypted, so that someone monitoring the traffic between the client and the server only sees ciphertext and not plaintext messages (secrecy). In addition, SSL/TLS provides a way for one party to ensure that a message indeed came from the other party (authenticity), and that the message was not altered along the way by an attacker (integrity).
For instance, if the client is consuming SOAP web services on the server, then the private key on the client is used to add a digital signature to the request headers which can then be verified on the server, after which point the request is fulfilled.
I think you might be thinking of client certificates here. Client certificates can be used to authenticate a client with a server. See Using client certificate to authenticate an app for more info.
