As I understand it......
If the MD5 of the certificate details (common name etc. and public key) matches another certificates MD5 then the signatures (the encrypted MD5) will match assuming they are signed by the same CA certificate, no big surprise.
The critical thing here is if you could manufacture a certificate that you could predict the MD5 for, then just attach the signature of a certificate with an identical MD5 that has been signed already and presto it appears your manufactured certificate has been validly signed.
The MD5 weakness (attack) is that you *can* predict the MD5 under some curcumstances, it doesn't matter that we are now issuing SHA-1 certificates, the issue is that our browsers still allow MD5 based signatures, paypal uses SHA-1 but if somebody could create a spoof paypal (or whatever) certificate, install it on a server it could look valid.
Of course this does also mean the domain name still has to match the IP so either needs a DNS compromise or typo domain (www.paypa1.com etc.) or there will be a certifcate warning.
When I first worked with certificates (over 10 years ago), I wondered why use a hashed signature at all, why not additionally encrypt the whole server certificate (common name etc and public key) with the CA private key as a signature, OK there's a speed penalty and the certificate is twice the size, but becomes as unbreakable as RSA itself, I spoke to a techie at Verisign and he said that MD5 was as good as it needed to be, I guess it was.... then.
When I sue for using my idea of using the whole certificate as a basis of the signature (when SHA-1 is broken), remember you heard it here first ;-)