Friends don't let friends use wildcard certs. There in the past have been rather annoying bugs relative to wildcard processing.
There is an x509 extension called Subject Alternate Name (aka SaN), this a means of adding alternate names to a certificate (specifically setup to avoid the issues of wildcards yet allowing for http vhost utility).
The common name in the certificate is just one of the basic constraints, sig needs to match as does the signer needs to validate etc. The common name field is just the field you typically see. In point to point SSL uses you can expand the constraints to validate more of the fields which makes it harder to forge a good signature.
The 'bad guy' just needs to make a certificate VERY close to the one you are looking at or one that satisfies a bug in the wildcard expression parser. For instance *\0.whateveryouwant.net the \0 is 'null' which would match _any_ URI. There are most definitely good uses of wildcard certificates (like proxy farms, load balancing) but for a single host with a single IP, it is irrelevant.
Your 'bad guy' just needs to forge a CA you already trust or convinces you to trust then you are completely hooped. They could also (if they were bad ass enough) take the contents of the intended server certificate and subtly change things enough to convince your client it is the same certificate. This is an example of why MD5 collisions are well... a non-trivial issues. Recommendations for that is to use a certificate with SHA-? signatures instead of MD5 but you can't control what your CA signs... hell most CAs these days don't respect your CSR and just pull the CN and key and create their own CSR to sign.