After coming across this question in the Hot Network Questions section and reading the related blog post by Google, I'm starting to become curious as to what role these hash functions play in TLS/SSL certificate validation.

I was under the impression that an SSL certificate was just a link between a set of domain names and a public key (the site owner's public key to be precise), cryptographically signed by the private key of a certificate authority. Why is a hash function needed for validating it?


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:

Diagram illustrating how a simple RSA digital signature is applied and verified. 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:

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.

  • Hmm, so it's just for performance reasons? Sounds reasonable I guess... – Ajedi32 Sep 17 '14 at 13:20
  • it is the message digest that is encrypted with the private key and attached as a signature then it's sent over the network along with the message itself and the the sender's signed public key – adam86 Jul 20 '16 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.