This article provides an overview of cryptographic hash functions and how they relate to digital certificates and signatures. If this is not the support article you are looking for, use the search box above.
Hash functions, for practical purposes, are considered one-way functions as they are practically impossible or at the very least infeasible to invert from the resulting value back to the original content.
A very basic example of a hash function would be if you send someone the message "123". The recipient reads "123" but can't be sure that they are reading the original message. You also send them the hash value of "6". On its own it's rather useless, 6 could have been derived any number of ways. If you also specify that your hash algorithm is to "add up all the numbers" it becomes much more useful. Now you can add 1+2+3 to get 6 and know that the integrity of the message was preserved. If you received "124" as your message, you would get a hash value of 7 and it wouldn't match the hash value you were sent and you'd know the integrity of the message has been compromised.
In practice: “The text inside these quotes” has a SHA-256 hash value of: 96b26f6cc52edd91cd52ac5baa1a802f4ff04daab07a308f0b2e897cc807e4bb. Knowledge of the hash value does not disclose the original message. However, running the SHA-256 hash function on the original message, if known, will validate the integrity of that message if the two hashes match. As with the previous example, if anything on the original message was modified, the hash values would not match.
If two different sources produce the same hash, it is called a collision. So in the first example if you were sent the message "33", you would also get a hash value of 6 and would be unaware that you were not looking at the original message. The somewhat near-future ability to purposefully produce collisions is one of the factors in deprecating SHA-1. Improvements with the SHA-2 algorithm and the larger 256-bit hash size greatly decreases the likelihood of ever finding or producing collisions.
Our SHA-256 Compatibility Article covers validation of the SHA-256 hash on document signatures, signed code, and certificates themselves. Support for one of these scenarios does not imply support for another. When you digitally sign a document or code, the document or code itself is used as the input to calculate the hash. If any part of the document or code is modified, the hash changes and the signature will be invalid.
On a digital certificate, fields such as common name, country code, organization, and e-mail make up what is called the TBS (To Be Signed) Certificate Sequence. This is the information used on a certificate to calculate the hash value when signed by GlobalSign or any other certificate authority. Two other certificate fields, signatureAlgorithm and signatureValue, assist in the validation of your digital certificate. SignatureAlgorithm specifies the hash algorithm used to calculate the hash, and signatureValue is the calculated hash of the tbsCertificate sequence. With this information available, operating systems, browsers, and other software can verify the integrity of the vetted information on your certificate.
Where signatureValue is the hash of the tbsCertificate sequence, the thumbprint is the hash of the entire certificate in binary DER format; it is not actually part of the certificate. The thumbprint is calculated by the operating system; Windows uses SHA-1 by default regardless of the signature algorithm on the certificate.