I was installing a CA on a Windows server 2012 machine, and it asked what hash algorithm I want to sign the certificates with (MD5, SHA1, SHA256, etc). I read that SHA256 is immune to collision attacks while older methods are not.

From what I understand the CA uses this hashing algorithm to create digital signatures. Like when a server asks the CA for a digital signature so people can trust it, the CA hashes the the server's certificate then encrypts it with the CA private key. Then the server will send this digital signature to its clients so they can trust it.

So what I'm wondering is what difference does it make if you choose a more secure hashing method over another in the CA setup? Like what difference does it make if an attacker finds something that produces the same hash as the one in the signature? He doesn't have the private key of the CA nor the private key of the server, so what would he accomplish by doing a collision attack?

Edit: That links don't answer the question.


1 Answer 1


You may be mixing up a collision attack with a second-preimage attack. The difference between the two is in what the attacker controls: in a collision attack, the attacker has to find two strings that generate the same hash, and the attacker gets to choose both strings. In a second-preimage attack, the attacker has to find a string that generates the same hash as a given string that the attacker cannot control. See the answers to this question for more info about the difference.

You asked "Like what difference does it make if an attacker finds something that produces the same hash as the one in the signature?" -- here, you're describing a second-preimage attack. If that were possible, an attacker could use it to generate a forged certificate with the same hash as the valid certificate, and then simply copy the signature from the valid cert to the forged one; since their hashes match, the signature will match as well. This would result in a complete failure of certificate security. But (at least as far as I know) there's no hint of a practical second-preimage attack against SHA-1 (or even MD5), so this is pretty hypothetical.

The risk of collision attacks (which are possible against both MD5 and SHA-1) is less direct. The problem here isn't with your actual server certificate; you could actually use MD5 for that, and connections secured with it would be fully secure. The problem is that an attacker can generate two certs with matching hashes, one of which will look OK to a certificate authority, and one of which is completely invalid. They submit the OK one to a trustworthy CA, get it signed, then transfer the (valid) CA signature to the invalid cert, and then use the invalid cert (with valid signature) for whatever they want. Including simply replacing the (valid) cert from your server.

This is not hypothetical. In 2008, a group of researchers from the Chaos Computer Club used this process to forge an intermediate CA certificate with a valid (MD5) CA signature; since the forged cert was a CA certificate itself, they could then use it to sign anything they wanted (although they intentionally created it pre-expired, so it couldn't actually be used). See this CNET article.

In order to avoid being fooled by forged certificates like that, clients must reject MD5-signed (and probably soon SHA-1-signed) certificates. And that is why you should sign your certs with SHA256 -- it's not that MD5 and SHA-1 certs are insecure, it's that clients can't tell they're secure, and therefore have no good choice but to reject them. See my answer to a similar question here for more details.

  • Damn. This explains it better than anything out there! How do you get all this info? Jul 2, 2017 at 10:44
  • @ZouzouIbba Thanks. I didn't get this info any specific place; partly from looking at how certs work, and partly from reading about at the 2008 hack and its implications (and the reasoning for browsers to stop trusting MD5 and then SHA-1 certs). Jul 3, 2017 at 6:23

Not the answer you're looking for? Browse other questions tagged .