So here's the work flow again:
- You generate a key pair and secure the private key.
- Your formulate what is called a certificate signing request (CSR).
- You send it to their CA.
- You get back a certificate signed by their CA and install it (along with the private key) such that your browser can use it.
Also note that while you could replace the CSR in this step with a self-signed certificate, it's certainly a non-standard way of handling things, but should work. In the end you would use their certificate anyways, because it has the signature by the trusted CA.
Now during the TLS handshake, the server has the option to request a client certificate. The server can also explicitely provide accepted CAs here. This will trigger a dialog in your browser asking you to select a certificate to be used for authentication.
Then your browser signs the transcript of the TLS handshake thus far using the private key associated with the selected certificate and sends the certificate and the signature to the server. This proves posession of the private key and thus of the fact that you are the rightful owner of the certificate, which confirms your identity to the server.
If this is "too high-level" for you, you can also look at more details on Wikipedia or view the full picture in RFC5246.
I am being asked to send it to a CA of my choice for signing, and then
to send the client my public key for their configuration.
In this case they probably will use one of the standard lists of trusted CAs. You then get a certificate from said CA. They probably ask you for the public key for app-level identification, ie the TLS engine will provide the app with your client certificate and then map your actual identity based on the embedded public key. What I somewhat fail to see here is why they can't just let you have any certificate containing the right public key (even a self-signed one) if they will authenticate you via said public key anyways.