Short answer: it can be, but it's complicated and it depends on what kind of certificate the server has and which TLS cipher suites it's configured to use.
This answer is essentially a copy of this openssl wiki page. Let's go through some examples.
Pure RSA
For these, the server's certificate will contain an RSA key and you will use a cipher suite like
TLS_RSA_WITH_....
The session key will be generated client-side and sent to the server encrypted with the server's RSA key. For the authentication part of the handshake, the server will use the same RSA key to produce a signature (I think).
Static DH - anonymous
For these, the server uses the same DH keys for each connection, however there is no certificate, so no way for the client to check that this key actually belongs to the server and not to a man-in-the-middle. You will use a cipher suite like
TLS_DH_anon_WITH_....
Note: clearly this is insecure.
Static DH - with certificate
For these, the server uses the same DH keys for each connection and the public key will be placed in the server's certificate (a DH certificate rather than the more common RSA certificate). You will use a cipher suite like
TLS_DH_RSA_WITH_...
As noted here, the signature algorithm (RSA/DSS) indicates which signature algorithm the CA used to sign the certificate and there is no signature as part of the handshake; if the server arrives at the same session key, then it must have the matching DH private key.
Note: this is old and deprecated, people prefer DHE now.
Ephemeral DHE + RSA
For these, the server's certificate will contain an RSA key and you will use a cipher suite like
TLS_DHE_RSA_WITH_...
Since the DH is ephemeral, a new DH key will be generated for each new connection so there is no need to put it in a certificate. The RSA key is used to sign a challenge response to prove that the server is who they say they are. These are the preferred ciphers these days.