The choice of Certificate Authority (CA) can affect performance of TLS connections.
To clarify the process, the domain owner generates the private key with a corresponding Certificate Signing Request (CSR) which they send to the CA (the CA doesn’t need to – nor should ever – have access to the user’s private key). The CA checks that the applicant controls that domain (or carries out a more thorough proof of identity in the case of Extended Validation Certificates) and returns a certificate (for public use) which corresponds to the original private key.
Bandwidth for Intermediate Certificates
In many case, Certificate Authorities sign the CSR using an Intermediate
Certificate. In the simplest case, this intermediate certificate will have been signed by the CA’s root certificate. When returning the certificate to the user, the CA also provides a copy of the Intermediate Certificate used to sign the cert so that any TLS client can verify the chain of trust.
One performance issue is that some CAs (e.g., Godaddy) also include a copy of their Root Certificate bundled in the file containing their Intermediate Certificate. However, TLS clients should already have a copy of the Root Certificates of all commonly-used CAs.
When I have to work with such CAs, I edit the Intermediate Certificate PEM to remove their Root Certificate. This avoids wasting unnecessary bandwidth when the client downloads the Intermediate Certificate.
As pointed out by Deerhunter, there can be differences in speed and availability between OCSP responders run by the CAs. Since TLS clients query these servers to check if the TLS certificate has been revoked, this can make a difference to the performance. I haven’t looked into this very much but Netcraft publish a table of OCSP availability and have an article explaining Certificate revocation and the performance of OCSP.