There is no separate "digital signature exchange." A certificate is a self-contained thing; it contains an "issuer" field (with a DN of the CA that signed it) and a "signature" field (with a signature from that CA). A server does not just send its certificate in the ServerCertificate message; it sends a whole chain of certificates, starting with theirs, then having their CA, then their CA's CA, and continuing to a trust root (that the server hopes the client trusts).
For DHE and ECDHE (which have signatures used in cipher parameter exchange), the signature on those parameters is part of the ServerKeyExchange message that has the parameters. Again, there is no separate signature exchange.
As for which hash algorithm to use: This doesn't actually inherently have to do with the cipher suite, as certificate signatures are an X.509 thing. The signature algorithm is also included as a mandatory certificate field. An X.509 certificate contains all the information you need to authenticate it except the Issuer's public key. Certain cipher suites don't allow certificates that aren't signed with the right algorithm, but that comes later -- you can still verify the signature as soon as you get the certificate chain.
In response to your comment: The signature verifies a certificate, not a server. The server is implicitly verified because other operations prove they have the private key corresponding to the public key in that certificate. As a separate matter, nothing is at any point encrypted with a private key; this is a popular and wrong idea of signatures. A signature algorithm takes a message (not a hash) and outputs a signature; any hashing is part of the signature algorithm.
Edit 2: Let me try explaining the certificate validation process a bit more. Here's a picture of a sample certificate chain; blue arrows are "is identical" (e.g. Issuer DN is the Subject DN of your CA), and green arrows means "generates" (i.e. by signing, which is not encrypting and you shouldn't call it encrypting):
The server presents all four of those certificates in the Server Certificate message. The client then verifies the server certificate, using the following general certificate-validation process:
- If the certificate is identical to something in the preset list of "trusted certificates" (e.g. a trusted root CA cert, or if you've manually added a trusted root certificate), then accept the certificate. If it's not and this is the last certificate in the chain, reject it (you don't trust whoever verified it).
- If not, check that the certificate isn't expired and that the date it starts being valid isn't in the future (these are attributes I didn't show).
- Check the Issuer, the signature algorithm, and the signature on the certificate. If there's a next cert in the list of certs you received, verify that that certificate's Subject DN is this one's Issuer DN.
- Using the public key from the next certificate and the signature algorithm from this certificate, verify the signature on this certificate.
- Verify that the next certificate has the CA attribute.
- Validate the next certificate down the line using this same process.
If any of steps 2-6 fail, reject the certificate. This is all done using only the information in the Server Certificate message, which contains the full chain of certificates (OK, so technically you can leave out the self-signed root CA and the TLS client will check its trust root for a cert with the appropriate Subject DN, but that's a minor detail). At the end, you know that the server cert is the start of a chain of certs, each signed by the next one, where the last one is one you inherently trust (it's a root CA). There is no separate signature exchange; these signatures are part of the certificates.