First, here’s my interpretation of the certificate validation process (if mistaken, please feel more than free to correct me).
When connecting to a web site using https, the website present an SSL certificate to the browser. It is used to authenticate the website. The browser has to have a way to decide whether to trust that certificate. The browser does this by checking whether the website’s certificate was issued and signed by a trusted Certificate Authority. 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. If runs the certificate through a one-way-hash algorithm like SHA-1 and signs it with the CA’s private key. When the browser is presented with the certificate one of the first things it does is to check the signature. Because the certificate was signed with the CA’s private key (and we assume that it is only in the CA’s possession) we can verify the signature (thus authenticate) the server because the CA’s corresponding public key is wrapped in a X.509 certificate that is pre-loaded in the browser. Next the browser calculates the SHA-1 for that certificate and then compares with the value presented in the certificate sent by the website to check it’s integrity, that it was not altered in transit.
If the above is true, then I have the following question. Although it was recently proved by researchers at Google that two different .pdf files produced the same SHA-1 value, thus a collision occurred, I’m wondering how this can be exploited. I mean, say example.com got a certificate with a SHA-1 value equals X and it’s signed by Verisign. An attacker creates an certificate for example.com and the SHA-1 value also equals X, so again, we have a collision, but this time it is not by any trustworthy CA! So if the attacker now tries to impersonate example.com, how this can be exploited if the browser will not be able to verify that it was signed by a trusted Root CA? Wouldn’t this cause any issues only IF the Root CA gets compromised ?
Added: Or why it is even a problem with document signing ? I mean, say a business partner is about to send me a contract. It's signed by him and I can verify and I sent it back after signing with my private key. So, why should I be concerned that he was able to compute a similar looking document with the same hash value ? If I didn't get it, how he can prove that I signed it? I guess, he can't. And even if I get the "fake" document, just because it is signed, shouldn't I still verify what's in the document before signing and sending it back ?
I think I start to understand. So, if for certificate A, the message digest equals to X and a Root CA signs it with its private key everyone can verify its authenticity by decrypting the signature with the public key that is pre-loaded in to the browser in form of a X.509 certificate, correct ? So given the hash value of X (as it is not a secret anyway) and even not knowing the private key that signed the hash I know that the final result (signature) = Y. So if I know that certificate A’s hash = X and I’m able to compute another certificate (with the Issuer filed set to the Root CA that signed the real certificate) and it’s hash value will as well = X (collision occurred), even not knowing the signers private key, if I supply the Y value as for the signature (because the unique hash of the certificate plus the encryption through the private key would produce a signature value of Y) , the browser will accept and validate the certificate, because it will be able to decrypt the signature with the corresponding public key of the Root CA, that is performing the validation, compute that hash again and match it against what was send by fake server and the fake certificate, correct? Thank you