Digital signatures prove ownership. They provide proof that a user is in fact talking to the CA authority who signed a certificate and not some man-in-the-middle.
When encrypting data the public key is used to encrypt the data for the entity holding the private key. However, in this case the roles are reversed. A private key can be used to prove ownership of a public key. The holder of the private key encrypts a small amount of data with the private key then sends that data (in the clear) along with the encrypted data itself. The public key holder uses that key to decrypt the data and compare it to the token (unencrypted) data sent. Only the private key holder can send this type of data to verify its signature on the certificate. This token/encrypted data pair is called a digital signature. Digital signatures cannot effectively sign large amounts of data. Therefore, a hash function is used to take all the certificate variable data and reduce it to a digest containing a small fixed amount of data. This hash is then encrypted with the private key. The verification process afterward is thus:
– The signature is included along with the certificate
– The signature is decrypted with the public key to get the hash
– The certificate is then hashed with the same algorithm
– The two hashed values are then compared
There have been a number of prior hashing algorithms. As computational power increased, the possibility of reversing the hash in an acceptable amount of time has also increased. Prior to SHA-1 MD5 was used until a flaw was found in 2004. Since then SHA-1 has been used. Now the possibility of it also becoming compromised due to increased processing power has spurred the industry to adopt SHA-2.
In support of this major browser manaufacturers are taking steps to begin phasing out SHA-1 signed certificates. Many already are not allowing SHA-1 certificates if they are valid beyond January 2017 (the final cutoff date for support). Some vendors will not accept them past January 1, 2016.