SSL / TLS certificates and the certificate authorities that sign them are vital to online security. They’re responsible for two important aspects of secure online communication: encrypting network traffic and verifying the identity of sites. Any SSL / TLS certificate can be used to encrypt data, but only certificates signed by a certificate authority can be used to verify the identity of a site. If the identity verification system stopped working, there would be no way to stop a malicious site from pretending to be your bank, Google, or any other site.
Certificate signing is a complex business, but, in brief, it works like this. A certificate authority verifies the identity of the organization applying for the certificate. Then they cryptographically sign the certificate they intend to issue with their private key. Only they have access to the private key, but the signature can be verified by anyone with the related public key. Browsers check to see that the certificate has been signed by a valid certificate authority.
That description is accurate for the most part, but I left one detail out. How does the browser know that the certificate authority signed this certificate? Instead of signing the certificate itself, CAs create a hash of the certificate and sign the hash.
“Wherever practical, the internet proves things through math. When a certificate is issued, the Certificate Authority includes this proof by cryptographically “signing” the certificate using a private key, in a way only the real CA could do and that browsers can verify.
But the CA doesn’t actually sign the raw certificate: it first condenses the certificate into a unique slug by running it through a “one-way hash” algorithm, like MD5, SHA-1, or SHA-256.”
Hashes are one-way functions. You feed some data into a hashing algorithm and it spits out a string of characters. This string has some special properties. It is — for all practical purposes — impossible to get from the hash back to the original certificate; hashes are not reversible. And, if you feed the same data into the hashing algorithm, the hash that it produces will always be the same. The same data produces the same hash. Finally, and most importantly, if the data is even a little bit different, the hash will be completely different.
The important point to note is that when a certificate authority signs a hash of the certificate, we can be sure that no other certificate could produce the same hash. If a browser hashes the certificate and gets a result that matches the hash that the CA signed, it can be sure to a very high degree of certainty that it’s the same certificate the CA signed.
But what happens if someone figures out a way to make a hashing algorithm produce the same hash for a different certificate. It’s difficult to do, but for some older hashing algorithms, it’s not impossible.
This is the problem with SHA-1, the hashing algorithm that has been used to sign certificates for many years. It has been proven that it is possible to cause a so-called hash collision for SHA-1 hashes. That means browsers can no longer be completely certain that a certificate signed with a SHA-1 hash is the same certificate that the certificate authority signed. And for browser makers, that’s a big problem.
It’s such a big problem, in fact, that Microsoft and other browser makers have all decided that certificates using SHA-1 hashes are not secure. Sites using these certificates will not get the closed-lock icon and other visual indications of security in browser interfaces. In time, the browsers are likely to start warning users that these sites are not secure. The certificate won’t stop working, but it won’t be considered secure.
If your sites and services are still using certificates that use SHA-1 hashes, it’s time to think about updating to SHA-2.