Perhaps it's neat for you, I just found out that our newly issued EV certificate status is being revoked in the next build of Chrome, so our expensive EV certificates may as well be $5 StartSSL certificates.

I imagine that there will be a lot of angry customers asking for refunds from Symantec/Verisign for certificates already issued which no longer conform to the offered product.

I for one find it totally neat that people realize their expensive EV cert was a waste of money. Although that was true before, too. EV certs are a waste of money, the only thing they do is show a green bar. They don't improve security.

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 -

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?

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.

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.

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

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.

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.

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

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.)

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.

Absolutely, I totally get that, it's worth mentioning that we take our TLS implementation seriously (HSTS, no TLS1.0, etc) and score an A+ on SSLLabs test: http://i.imgur.com/QbH4YZS.png

The green bar with our company name in it translated in to a measurable conversion increase week for week from guest checkouts, so saying it's a waste of money isn't strictly true in our case.

As the neighbor comment points out, EV validation is absolutely not a waste of money. I've been part of A/B testing on most aspects of domain security and it's arguably one of the best ROIs out there for e-commerce sites.

They don't improve security -- that is true.

> I've been part of A/B testing on most aspects of domain security and it's arguably one of the best ROIs out there for e-commerce sites.

That's a bit hard to reconcile with the fact that Amazon.com can't be bothered to get one.

Amazon as a brand already has the trust of visitors to the site, through sheer pervasiveness in our culture.

Non-household name eCommerce sites benefit significantly from quality signals like the EV bar, however.

Most outliers are hard to reconcile with the mean.

amazon has brand recognition, they don't need to assuage people's semi-conscious perception of site trustworthyness.

So you're serving an EV vs. DV/OV some random % of the time for same site and measuring conversions? Mind sharing the data?

Wow, that's interesting. Would you mind share numbers like percentage of A and B group?

It proves (if the issuer has done their job) that the organisation requesting the certificate has been properly vetted, so you’re more likely to be doing business with the right website.

What? Of course they improve security. They reduce the risk the user has accidentally navigated to a squatted typo-domain registered by an attacker (or the correct domain, but the registration somehow accidentally expired and was reregistered by an attacker)

They can improve security. We used to pin the EV roots of a couple CAs that we trusted in our mobile apps and in the browser via hpkp. This protected against someone tricking or coercing a lesser CA into issuing a DV cert and MITMing us.

Why does EV make a difference here? Can't you pin an intermediate or root cert from your CA of choice and avoid other CAs issuing end certs for your domain just as well?

I think the idea here is that they're not trying to prevent other CAs from issuing end certs, they're trying to only allow certs for their domain - from any CA on their short list - if the owner of the cert has been through Extended Validation.

Of course, this only works if the CA _actually_ makes sure they don't use the root you pinned for DV issuance. Just because it says "Ultra Great EV root" in the CN doesn't provide you that security, and it won't count as mis-issuance so long as the DV certificate doesn't have an EV policy OID baked into it.

If we'd asked in 2015, Symantec would probably have pointed us to CrossCert's CPS which said they only use certain Symantec roots. In fact Symantec had no mechanism in place enforcing that, CrossCert could and did issue from any Symantec root, whether it was on the list or not. So, if you chose a root thinking "I don't trust CrossCert, but they don't use this root so it's fine", oops, too bad.

I don't understand how EV vs DV factors into certificate pinning here.

If we had a DV cert and pinned the DV root then the barrier for an attacker is a lot lower. They just need to jack our DNS and get their own automated DV cert issued quick.

How recently did you renew? This has been in the works for over two years,I'm surprised that anyone is still giving them business.

We renewed recently, through our hosting provider who have Symantec in their certificate chain.

I would contact your hosting provider. They are going to have to find a new CA themselves and when they do, I would guess they would be willing to mint you a new EV cert.

Should've gone with a better vendor. Symantec has been a known bad actor in this field for years now.

If they're going nuclear then it's akin to merely lobbing tactical nukes on military bases, not city-busters on some megalopolis.

They're "only" planning to remove the extended validation indicator and reduce the maximum validity time instead of completely phasing out the root.