The CA signing the cert actually changes the fingerprint (and serial number, which is what is checked on revocation lists), so this is not a viable scenario. Beyond that, SHA1 signing of certificates has long been deprecated and no new public CAs will sign a CSR and cert with SHA1.
> On Feb 27, 2017, at 8:18 AM, Chris Adams <c...@cmadams.net> wrote: > > Once upon a time, valdis.kletni...@vt.edu <valdis.kletni...@vt.edu> said: >> There's only 2 certs. You generate 2 certs with the same hash, and *then* >> get >> the CA to sign one of them. > > The point is that the signed cert you get back from the CA will have a > different hash, and the things that they change that cause the hash to > change are outside your control and prediction. > > -- > Chris Adams <c...@cmadams.net> Even with massive computing power, the tampering is still detectable since this attack does not allow for the creation of a hash collision from any arbitrary document. It requires specific manipulation of all items that result in a collision. > On Feb 27, 2017, at 7:39 AM, valdis.kletni...@vt.edu wrote: > > On Mon, 27 Feb 2017 07:23:43 -0500, Jon Lewis said: >> On Sun, 26 Feb 2017, Keith Medcalf wrote: >> >>> So you would need 6000 years of computer time to compute the collision >>> on the SHA1 signature, and how much additional time to compute the >>> trapdoor (private) key, in order for the cert to be of any use? >> >> 1) Wasn't the 6000 years estimate from an article >10 years ago? >> Computers have gotten a bit faster. > > No, Google's announcement last week said their POC took 6500 CPU-years > for the first phase and 110 GPU-accelerated for the second phase. > > You are totally on target on your second point. A million node botnet > reduces it to right around 60 hours.