Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

This is what I understand so far from reading various knowledgebase and article about DV SSL. Can anyone please help clarify if any of these is wrong?

  • DV SSL (and SSL certificate in general) is only associated with domain name, not the IP address configured under DNS for that domain. Hence if I change the IP on my domain's A record I don't need to repurchase another SSL certificate
  • Most DV SSL provider (eg: GoDaddy) will verify domain name ownership by sending email to the address registered in the domain 'whois' record
  • Although DV SSL is the 'lowest end' of SSL certification, as long as the private key and the email password did not fall into the wrong hand, no hacker should be able to register a DV SSL for my domain and / or setup a fake phishing website under my domain name without the browser warning the user for possible attack
share|improve this question

3 Answers 3

up vote 12 down vote accepted

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, possibly with a "wildcard" (* 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. or instead of (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.

share|improve this answer
"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." and by client, you mean client software, right? –  curiousguy Aug 27 '13 at 14:40
More human users than client software, here. Software has no real way to know that a given site ought to have an EV certificate, and not a "normal" certificate. –  Thomas Pornin Aug 27 '13 at 14:49
What about a browser who has just seen an EV certificate, who sees another cert? –  curiousguy Aug 27 '13 at 16:50
Right now, Web browsers validate certificates as if it was a whole new site every time. They don't have memory. Convergence is a proposal which, in part, relies on the idea that normal Web sites don't switch certificates every 5 minutes, and raise alarms in case such a thing apparently occurs. A stock browser, though, won't mind in any way. Such features might appear in browsers in the future, but browser vendors are wary of breaking multi-frontend sites, and therefore won't make much effort until this becomes really necessary. –  Thomas Pornin Aug 27 '13 at 16:56
@ThomasPornin, Google's cert is DV right? Seems like EV is really not the future, especially with Google being hopping mad with CAs. –  Pacerier May 22 at 3:43

Domain-validated SSL certificates (DV) are technically the same as extended-validation certificates (EV).

The reason, EV-certificates are more expensive is, that apart from the domain name, the seller also has to check further informations about your identity. To verify that you really are the owner of he needs to contact you and has to do other administrative work.

For most smaller websites the domain-validated certificate is fine, the user will have no disadvantages and the EV-certificates are really too expensive in my opinion (the effort doesn't justify the price).

share|improve this answer
How much more would we have to pay on average for EV? –  Pacerier May 22 at 3:45
@Pacerier - The prices vary very much and are dependend of your country. I can only speak for switzerland, there you can buy a domain validated certificate for about 50$ per year, and you get an ev certificate for 300-1200$ per year. –  martinstoeckli May 22 at 6:52
Wow $1200, talk about selling stones as diamonds. –  Pacerier May 22 at 10:58

Posting an answer because the current answer has some inaccuracies.

Your first two points are correct: DV certificates have a subject that's a domain name, and whois information is frequently used for contacting the owner of a particular domain to give them a DV certificate.

no hacker should be able to register a DV SSL for my domain and / or setup a fake phishing website under my domain name without the browser warning the user for possible attack

This isn't correct:

  • Someone could register There is no guarantee the domain name matches any legal entity, just that the person has this domain.

  • Anyone else could register * Then later add the host This is how phishing scams work. Wildcards like this are allowed for DV SSL, and forbidden for EV.

From the current marked answer:

"the entity's name is a host name, this is what SSL certificates verify"

Is only correct for domain validated certificates. The subject - what an SSL certificate is verifying owns the public key in the certificate may either be:

  • a domain name (or wildcard domain) for domain validated certificates. Again, domain validated SSL does not assert that this matches any particular legal entity.

  • the ID of a business or incorporated organization that was verified with a EV certificate


Looking at domain validated certificate:

openssl x509 -in -noout -text | grep Subject
 OU=Domain Control Validated

Here is an EV cert, containing a government-registered company ID rather than a domain name:

openssl x509 -in -noout -text | grep Subject:
   businessCategory=Private Organization
   ST=City of London
   O=example Limited -

Companies in the UK are registered with a UK-wide organization called Companies House. The serialNumber 09378892 in the certificate above is a company registration number from Companies House.

In the USA, organisations are registered on a per-state basis, so serialNumbers in US certificates refer to a company ID at the relevant Secretary of State.

share|improve this answer
While this is true, that EV certs are against both the domain and organisation, the browser does not actually verify that it's owned by the correct company. The browser can only check that the cert's domain is the same as the actual domain visited, it cannot check that the cert's serial number actually represents the correct company. It's meant more for the human at the computer to be able to check and verify who owns the domain. –  Chris Murray Aug 21 at 10:21
I don't think the wildcard is relevant when you talk about setting up a phishing domain name. There's no reason why I wouldn't be able to set up and apply for a EV cert to cover that domain. And it's important to point out that doing this will not grant me a cert for the OPs domain; the cert will be for my domain, which is deliberately set up to look like the OPs. –  Chris Murray Aug 21 at 10:26
@ChrisMurray yes, the browser does not verify the certificate is owned by the correct company: the browser verifies that the certificate has been signed by a CA who has verified the identity of the company. –  mikemaccana Aug 21 at 15:51
@ChrisMurray You wouldn't be able to set up an EV for '' because wildcards are banned for DV (see EV Requirements), and the Baselines Requirements (required for EV but not for DV) mandate domain names for EV certificates must be submitted to and inspected by the CA. Additionally mixed content domains names (eg, with a different) must be inspected for resemblance to other domains (see EV Requirements 11.7.1.) –  mikemaccana Aug 21 at 16:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.