There are two different ways a RSA certificate can be used by a SSL/TLS server.
In the "classical" RSA ciphersuites the client randomly picks a secret value, encrypts it with the public key from the server certificate and sends it to the server. The server uses the private key to decrypt it. So the client and server now have a shared secret.
The downside of this approach is that it does not provide "forward secrecy", if the server's private key is later stolen then all previous sessions can be decrypted.
To solve this problem the "ephemeral" cipher suites were introduced where the keys used for the key exchange are generated for a given session and then thrown away. In principle an epheral RSA ciphersuite is possible, but no modern ciphersuite uses that technique for performance reasons (generating RSA keys is computationally intensive).
So in modern "ephemeral" cipersuites the clients agree a shared secret using an epheral DH or ECDH exchange. The RSA (or DSA or ECDSA) key in the certificate is used to sign the key exchange so that the client knows it is communicating with the correct server. These ciphersuites have names like TLS_DHE_RSA_(something) or TLS_ECDHE_RSA_(something) .
The strength of the DH or ECDH keys used in the key exchange itself is independent of the strength of the RSA key used to verify the key exchange. Some older servers default to 1024 bit or worse 768 bit DH parameters.
The preffered option is to set up your server to use 2048 bit or stronger DH parameters. If for some reason that is not possible you should disable the DHE ciphersuites, though be aware that this may cause you to lose forward-secrecy with some clients.