[nailer]

EV certificates have the same level of confidentiality and integrity as DV certs, but they have different authentication - specifically, they tie the certificate to a legal entity rather than a domain name.

ie.

    https://paypal.com-customerservice.ru

vs

    PayPal Inc [US] | https://paypal.com

I run https://certsimple.com. We sell EV certs. But you can verify the above pretty easily by checking out the EV guidelines, the additional requirements that apply only to EV certs (https://cabforum.org/extended-validation/). You can also see the difference with openssl pretty easily:

Here is a DV cert:

    openssl x509 -in domain-validated-example.com.crt -noout -text | grep Subject
     OU=Domain Control Validated
     CN=example.com
     DNS:example.com

Here is an EV cert:

    openssl x509 -in extended-validated-example.com.crt -noout -text | grep Subject:
       jurisdictionOfIncorporationCountryName=GB
       businessCategory=Private Organization
       serialNumber=09378892
       C=GB
       ST=City of London
       L=London
       O=example Limited
       CN=example.com
       DNS:example.com -

[hsivonen]

If a site with an EV cert is being spoofed using a similar-looking domain name and a DV cert, how realistically is the user going to remember that the real site is supposed to have an EV cert? (Besides just maybe remembering it for Paypal in particular.)

See also the Nordea section at https://hsivonen.fi/bank-idp/ . How is a user supposed to form a mental model about multi-server org who don't use EV consistently?

[nailer]

That's a legitimate concern. The bank in the link is harming itself with mixed validation and further issues with mixed content (and yes the banking industry surprisingly bad at crypto - Barclays in the UK has mixed content issues pretty frequently).

There's no simple, single answer here: you can stop validation downgrades is pinning to EV roots but browser UI is also a huge part: mobile Safari, for example, simply uses the validated legal entity as the address and keeps it on screen during the entire session (even when you scroll). Visit https://stripe.com on mobile Safari and you'll see

> _______________Stripe Inc.______________

...persistently on top of the screen throughout the entire session [1]. Other browsers don't show validated identity as effectively though.

[1] Safari should also add a country indicator to distinguish other validated legal entities called 'Stripe, Inc.' in different jurisdictions.

[marcosdumay]

I'm bookmarking your page for when I need it...

But that overlay just before I started reading your landing text is a serious mood-killer. I'm not going to set-up a remainder for when my certificate expires before I read your page.

[tracker1]

That and the browser notifications request for every other blog online is starting to really tick me off.

[Shanea93]

Your pricing is very reasonable and I've just placed your website at the top of my to-do list tomorrow morning, thanks for posting.

[nailer]

Thanks! We're actually about the middle of the road price wise, our main thing is tech: the EV process can be pretty painful, our role is to speed it it up and make it easier. We start checking against government directories in 63 countries prior to payment, use webcrypto in supported browsers to quickly generate CSRs, make instant-paste openssl / windows scripts to make an ECC or RSA keypair quickly if you prefer to make keys on your own servers, we have a LOT of country specific logic, a meta directory of 'Qualified Independent Information Sources' to handle that part of the EV requirements, we validate in realtime and a bunch of other stuff to save you time and effort - https://certsimple.com/about.

There's cheaper options around, but we only do EV and we're the best at it.

[e_proxus]

Your mobile page doesn't show any pricing, and the FAQ redirects to the front page.

[deathanatos]

My understanding is that there is no reason why a DV certificate's Subject can't also identify the legal entity. It doesn't authenticate that the key binds to that legal entity (only the domain), but the Subject line can still be at least informative, even if not authenticated.

What makes an EV cert an EV cert is that it contains a Certificate Policies extension. (There are also requirements for the EV to have certain things in the Subject; I'm only saying that they're not necessarily forbidden from the Subject in the DV case.)

That said, many CAs like to overwrite whatever subject you give them with stuff like what's in your example. But you can find examples on the Internet where this doesn't hold, and the Subject contains useful information (e.g., Wikipedia, Let's Encrypt, Google).

One of the things I wish that x.509 was would be that certificates could have been simply a signed (CSR + additional data from CA); since CSRs are themselves signed, this would have prevented the CA from being able to change the CSR after it's submission; that is, the process of submitting the CSR would give the CA two options: append information and sign, or not sign. As it is, their first option is "rewrite the cert however we like and sign"

It doesn't matter so much for the Subject, but CAs will also do things like take a requested extension that has the critical bit set in the CSR, and mark it as non-critical in the certificate. (or even flat out drop the extension) A dev who blindly assumes that the CA will either do as asked, or refuse with a reason then runs the risk of putting a certificate that was really ever requested into production.

(One, I suppose, could assert that allowing free-form Subjects might cause a CA to sign a cert whose Subject is lying or misleading, which could be bad if the reader thinks the signature implies validation of that data.)

[schoen]

Take a look at Baseline Requirements section 3.2. CAs have to have a basis to believe the subject information they include in the cert, although of course EV requirements are more stringent. E.g.

> If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant’s address of existence or operation.