What are the advantages of EV Certificate?

Extended Validation certificates are intended to show the user more visibly the institution to which they were issued. The technical aspects of the certificates themselves is combined with visual clues in the user interface of the application verifying them: the green bar and a visible name next to the location bar in the browser.

For example, the EV certificate at http://www.paypal.com/ will make the browser show a green bar and display "PayPal, Inc." next to it. This is designed not only to link the certificate to the domain owner (like standard domain-validated certificates do), but also link it to a more physical institution (here, PayPal, Inc.). To do this, the CA must verify that the named institution is indeed the one owning the domain.

Ultimately, this is more about making a more authenticated link between the domain name and the company name than making "more secure" certificates. From a cipher suite point of view (which is what determines the encryption algorithm and key size), EV certificates are no different from DV certificates (blue bar).

Stepping back a little, you need to realise that the effectiveness of HTTPS relies on the user checking that it's used correctly. (The server has no way to find out whether the client is victim of a MITM attack otherwise, unless using client-certificates too.) This means that the users have to:

• check that HTTPS is used when they expect it to be,
• check that there are no warnings,
• check that the website they're using is indeed the one they're intending to visit, which leads to a couple of sub-points:
  • checking that it's the domain name they expect,
  • checking that the domain name belongs to the company they expect.

EV certificates are intended to solve that last sub-point. If you already know that amazon.com belongs to Amazon.com, Inc. or that google.com belongs to Google Inc., you don't really need them.

I'm not personally convinced that this approach completely works, since they can be misused (see NatWest/RBS example below) and some CAs seem to propagate vague (and potentially misleading) information as to what they really are, in an effort to promote them.

In general, if your users already know that your domain name is yours, you don't really need one.

Here are more details from a previous answer I gave to a similar question:

[...]

The domain-validated certificates guarantee you that the certificate was issued to the owner of that domain. No more, but no less (I'm assuming the validation procedure was correct here). In many cases, this is sufficient. It all depends on whether the website you are promoting needs to be linked to an institution that is already well known off-line. Certificates that are validated against an organisation (OV and EV certs) are mainly useful when you need to tie the domain to a physical organisation too.

For example, it's useful for a institution that was initially known via its building (e.g. Bank of America) to be able to say that a certificate for bankofamerica.com is indeed for the place where you've given your physical money. In this case, it makes sense to use an OV or EV certificate. This can also be useful is there is ambiguity regarding which institution is behind the domain name (e.g. apple.com and apple.co.uk), which is even more important is the similar domain name is owned by a rival/attacker using the name similarity for bad purposes.

In contrast, www.google.com is what defines Google to the public; Google has no need to prove that google.com belongs to the real Google. As a result, it's using a domain-validated certificate (same for amazon.com).

Again, this is really useful if the user knows how to check this. Browsers don't really help here. Firefox just says "which is run by (unknown)" if you want more details about the cert at www.google.com, without really saying what is meant by this.

Extended-validation certificates are an attempt to improve this, by making the organisation-validation procedure more strict, and by making the result more visible: green bar and more visible organisation.

Unfortunately, this is sometimes used in a way that increases confusion, I think. Here is an example that you can check by yourself: one of the large UK banks (NatWest) uses the https://www.nwolb.com/ for its on-line banking services. It's far from obvious that the domain name belongs to NatWest (who also own the more logical natwest.co.uk name, by the way). Worse, the extended validation (if you check the name next to the green bar) is done against "Royal Bank of Scotland Group plc".

For those who follow financial news, it makes sense because both RBS and NatWest belong to the same group, but technically, RBS and NatWest are competitors (and both have branches on the high street in the UK -- although that's going to change). If your user doesn't have that extra knowledge about which groups trade under which name, the fact that a certificate is issued to the name of a potential competitor should ring alarm bells. If, as a user, you saw a certificate on gooooogle.com issued to Microsoft or Yahoo, however green the bar is, you should not treat this as Google's site.

One point to bear in mind with EV certificates is that their configuration is hard-coded into the browsers. This is a compile-time setting, which cannot be configured later on (unlike normal trusted certificate stores, where you could add your own institutional CA cert, for example). From a more cynical point of view, some could consider this as a convenient way for the main players to keep a strong position in the market.

They are supposed to convey extra trust to the user that the certificate authority has done their job properly. The primary purpose of extended validation certificates however, is really just to generate extra revenue for certificate authorities.

Okay, enough of the snarky, basically they have to follow these guidelines before issuing one: EV Certificate Guidelines v.1.3. It covers things like requiring verifying the company/organization registration and address, and to get access to the signing keys needs two-factor authentication and every it is all meticulously logged.