When using RSA for key exchange in TLS, the role of the public key embedded in the certificate is clear: for asymmetric encryption when sending the master key, which the server can decode using its private key.
However when doing diffie-hellman to generate a shared master, these public/private keys are no longer needed. So are they included in the certificate merely for legacy reasons (to support clients still using RSA for key exchange)?
Before the key exchange is done the client has to ensure that it is talking to the correct server and not to some active man in the middle which could split the TLS connection into one between client and attacker and another between attacker and server. To authenticate the server the client is using the content of the certificate provided by the server, i.e. the subject and subject alternative names to validate the server name, the start and end time to check the life time and the signature to verify the trust chain to the builtin root CA.
The signature of the issuer of the certificate must be verified when building the trust chain which is done by using the known public key of the issuers CA certificate. Additionally it must be verified that the server is actually the owner of the certificate, i.e. knows the private key which only the owner should know. This is essentially done by the client providing input to a challenge which then gets signed by the server with the private key. This signature then can be validated by the client using the public key contained in the certificate and thus ownership of the certificate is verified. If client authentication is done using certificates a similar process is done for validating the client certificate.
