What role do hashes play in TLS/SSL certificate validation?

Basically, hash functions are a necessary part of the process of creating a digital signature.

Most signature algorithms are not designed to be able to securely and/or efficiently sign long messages directly, so the first step of each algorithm is usually to hash the message being signed, reducing it to a fixed length which the rest of the signature algorithm is able to effectively process. Similarly, signature verification algorithms involve hashing the message being verified, then performing some set of operations on the signature to check whether it corresponds to that hash.

For example, with RSA signatures the signature can be thought of as a hash of the data being signed, "encrypted" with the signer's private key:

_{Image from the Wikimedia Commons}

The verification process involves "decrypting" the signature (using the signer's public key), and comparing the resulting hash with the hash of the data the signature applies to. In the case of SSL certificates, the data is the SSL certificate itself.

Note: I wrote "encrypted" and "decrypting" in quotes here because in reality the operations used in the RSA signature algorithm aren't exactly the same as those used for RSA encryption. They are close enough though to make for an effective analogy here. With other signature algorithms like ECDSA, the signing and verification algorithms are totally different, not involving "encryption" or really anything resembling the process above, but the message is still hashed as part of the signing and verification process.

For more detailed information on the use of hashing in specific signature algorithms, see:

• Why hash the message before signing it with RSA?
• Why the need to hash before signing small data?
• Wikipedia: Elliptic Curve Digital Signature Algorithm

_{This answer was derived from reading the questions linked in dave_thompson_085's comment.}

Usually, digital signatures are not actually applied to the full data. Instead, the data (in the case the x.509 certificate) is hashed, and only the resulting hash is signed.

If this were not the case, digital signatures would end up being at least as large as the message itself, and signing / verifying the files would be less efficient.

This means, however, that if an attacker can generate a fake certificate using his own public / private key pair with the same hash as the legitimate certificate, the forged certificate can pass validation checks, and can be used to execute a man-in-the-middle attack.