> Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates
When I read that something like this popped up in my head:
"Google is using the nuclear option on Symantec. Neat!"
When I read that something like this popped up in my head:
"Google is using the nuclear option on Symantec. Neat!"
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.
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.
They don't improve security -- that is true.
That's a bit hard to reconcile with the fact that Amazon.com can't be bothered to get one.
Non-household name eCommerce sites benefit significantly from quality signals like the EV bar, however.
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.
ie.
https://paypal.com-customerservice.ru
PayPal Inc [US] | https://paypal.com
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
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 -There's cheaper options around, but we only do EV and we're the best at 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.
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?
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.
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.)
> 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.
They're "only" planning to remove the extended validation indicator and reduce the maximum validity time instead of completely phasing out the root.