Exactly, but the funny thing is that Chrome and Firefox (Desktop at least) are no longer showing the differentiating green lock for those high-end (EV & OV) certs, but the same neutral-looking lock as those Domain-Validated (DV) certs that Let's Encrypt is issuing.
I'm very grateful for IdenTrust for having made that move. I just hope it won't hurt their business too much because of that.
I've never understood why browsers didn't show the SSL Common Name or other agreed upon identifier, in place of a little lock. Why do I have to click 4 times in Firefox Linux Desktop, just to see info on the cert?
So this is perhaps why there is no EV or OV differentiation. Who cares? Of what use is an EV cert, if no one even checks the name. Or further, knows if the bank (for example) uses that CA?
I think in such a context, 'green' and 'no-green' is just non-helpful to validate anything. Sadly, 1 person out of 1000? actually care about encryption, or even know what SSL is. Maybe only 1 out of 10000 know about EV.
Sometimes I just become sad, when I think of the lack of general knowledge about fairly important things.
For PKIX (and thus in your web browser) leaf certificates the X.509 Common Name is only permitted to be textually equivalent to one of the SANs (Subject Alternative Names, the Internet's way to write a name for a machine) in the certificate. So that's either a dnsName or an ipAddress. This is grandfathered in because it's how Netscape worked last century before PKIX was standardised and thus before SANs existed to do this properly.
So it would be prohibited to issue leaf certificates with a CN that's a human meaningful name like "Google" or "Hacker News" because that violates PKIX.
It doesn't matter anyway, the only enforcement that really matters for HTTPS is the mechanical enforcement by the user agent, because there are way too many HTTPS transactions for the human to realistically assess the certificate shown for each transaction and decide if it's OK.
Agreed, I don't think we'll ever see this because most people don't care. I'd guess greater than 95% of people, really 99% of people, couldn't tell you the difference between HTTP and HTTPS.
It just should work for them, and the browser should enforce it. I think the tech world is biased to think consumers are more technically inclined due to the people they are around. I do not work in computer tech. No-one I work with, all of whom have some form of an engineering degree unrelated to computers, could tell you the difference or care less.
How would you propose verifying that agreed upon identifier?
Validating human-readable names, be that of individuals or corporations, would be opening a can of worms. Domain validation is already decidedly non-trivial.
Doesn't really matter if inertia is keeping them using Identrust. They're not going to go to the trouble of switching providers just to save a few bucks. If that was their concern there were much cheaper options available even before Let's Encrypt
As a consumer, I think it's regrettable that they don't show EV in a different way. It served for me as a signal that the website were less likely to be scammers.
But maybe Mozilla & Google, were aware of it being used like that and thought that EV certs were not reliable enough to be used as a signal of trustworthiness?
Does anyone in enterprise actually need publicly trusted certificates for documents and email? Seems like it's an inside-the-firewall Exchange server for internal traffic, and a white-label "secure messaging center" portal for external traffic.
IdenTrust's buisness also spans to managing private CAs for companies, which includes managing the HSM and private keys. Also, the companies who hire IdenTrust and similar companies are not that involved in technology. Also, security experts who can manage this safely is a tad harder to find and requests higher wages than your standard IT staff.
TLDR: yes, but some companies wants another company to manage their certs.
Using a public CA is far better for security than a custom private one. It's a pain having to install the certificate on every client, server, piece of software, etc. and in my experience this inevitably leads to people disabling certificate checking as part of troubleshooting and this being left on. Also, sometimes people need to access documents and emails from home computers and the company may use some devices on which it isn't possible to install the CA
So exposing your internal infrastructure to the whole world and risking a 3rd party (CA) turning the keys (literally) to your kingdom to someone else is better than someone making a mistake that’s very easy to discover and correct?
> Also, sometimes people need to access documents and emails from home computers and the company may use some devices on which it isn't possible to install the CA
That’s a plus as far most security professionals are concerned
> So exposing your internal infrastructure to the whole world and risking a 3rd party (CA) turning the keys (literally) to your kingdom to someone else is better than someone making a mistake that’s very easy to discover and correct?
That's not how certificates work. The CA doesn't have your private key. They could theoretically sign a fake certificate with your hostname but that risk is still present if you use a private CA and is mitigated by certificate transparency
Yes, should’ve been more clear on that they sign a cert without your knowledge and hand to to someone performing mitm. How is that risk present when you roll your own PKI and validate against your private CA (or intermediate) only?
Regarding CT I’m not aware of any clients other than browsers actually enforcing that.
I'm very grateful for IdenTrust for having made that move. I just hope it won't hurt their business too much because of that.