A Certification Authority, before issuing a certificate to an entity E, with E's name and E's public key in the certificate, is supposed to verify that the public key in question really belongs to E. For SSL server certificate:
- E's name is a host name, like
www.google.com, possibly with a "wildcard" (
*.google.com). This is what SSL clients verify; this is all about names, not IP addresses.
- The public key is received by the CA as a certificate request.
So the notion of "identity" in force here is really a question of domain ownership. The CA wants to make sure that it received the request from someone who controls the domain. There are several methods for that; the two most used are the following:
- The CA sends a challenge by email to the email address specified for the domain in the WHOIS database.
- The CA challenges the requester with some information to be included in the domain, e.g. a random host name to be included in the DNS.
These checks are not extremely robust (they rely on the "impossibility" to hack into, respectively, emails or the DNS, neither being well protected) so there is a recent fashion for stronger verifications, called Extended Validation Certificates. For an EV certificate, the CA is supposed to do a lot more paperwork to make sure that it talks to the right entity. Retrospectively, non-EV certificates are dubbed "DV" (as "domain validated").
The net effect of an EV certificate is that Web browsers recognize them as such, and may show that fact to the human user with a more lavish display, with a lot of green. But non-EV certificates technically work just as well. An EV certificate is worth the effort only if your users are trained to recognize EV certificates and feel more comfortable with an EV certificate than they would with a "normal" certificate (which is still shown with the famous "padlock" icon). Right now, I'd say that most Internet users are far from being aware of the distinction, so buying an EV certificate is kind of useless.
(EV certificates will become useful when they become mandatory, i.e. when Web browsers begin to reject or warn about SSL server certificates which seem valid but are not tagged "EV". This is a rather tough transition and I don't see it happening in the near future.)
For a bad guy to obtain a seemingly valid certificate with your server name in it (the prerequisite for mounting a really successful impersonation attack), he must do one of the following:
Fool the CA. Fooling the CA is harder for EV certificates (that's the point). However, even if you get an EV certificate, it would not prevent the attacker from obtaining a non-EV certificate in your name from a gullible CA. An EV certificate will protect you against sloppy CA only as long as your clients are trained to pause and become suspicious if they see a seemingly valid but non-EV certificate bearing your site name. This hardly seems realistic right now.
Steal your private key. If an attacker steals your private key, then he can use it with your certificate (which is public) to install his fake server. EV or non-EV is irrelevant here; what matters is that you should protect your private key well. If your server is broken into, inform the CA so that it may revoke your certificate, and issue you another one (with a new key).
Fool the human user into disregarding the very red and scary warnings from the browser when an invalid certificate is shown. You cannot really defend against that, except through educating your users. The warnings shown by Web browsers tend to increase in scariness (and redness, too) over time.
Fool the human user into connecting to an attacker-owned domain with a perfectly valid certificate, and a name which looks like the intended server name. E.g.
www.google.business.com instead of
www.google.com (fictitious examples). There again, only user education can really work against that.
Most phishing attacks are based on one of the last two methods, so this means that you should not be overly worried over the DV/EV dichotomy. The really important point for security is user education.