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.