[gioele]

> Without IdenTrust, Let’s Encrypt may have never happened and we are grateful to them for their partnership.

What I have never understood is why IdenTrust accepted to cross-sign Let’s Encrypt's root certificate.

With that move, IdenTrust basically broke the CA cartel and helped driving the price of basic certificates to zero. How did they, as a for-profit organization, justify "doing the right thing" when that meant disrupting their own market?

Anyway, kudos to IdenTrust.

[Thorrez]

My professor was one of the founders of Let's Encrypt. He said it was basically a game theory problem. Whichever CA defects gets money. The rest get nothing. IdenTrust decided to get that money, because they thought that if they didn't, a different CA would.

[FeepingCreature]

And that's why only a competitive market drives down prices.

[dubcanada]

IdenTrust doesn't care about random websites, they care about HIPPA, enterprise, government, securing documents and emails, etc.

[juliend2]

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.

[b112]

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.

[tialaramex]

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.

[Diesel555]

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.

[lxgr]

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.

[nsgi]

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

[im3w1l]

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?

[closeparen]

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.

[zinekeller]

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.

[mrweasel]

In those cases IdenTrust bought an insane amount of goodwill from some of the most technical people online by supporting Let’s Encrypt.

[strombofulous]

They also helped basically make it a requirement by allowing google to flag http pages as insecure and convince the public that it's necessary

[nsgi]

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

[dilyevsky]

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

[nsgi]

> 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

[dilyevsky]

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.

[andymatuschak]

It seems like a case of “commoditize your complement” to me. https://www.gwern.net/Complement

They offer a variety of enterprises services and can now capture more of the marginal consumer value relative to competitors still fighting for the cert issuing market.

[admax88q]

Always better to be doing the disruption rather be the one being disrupted.

Perhaps they saw the writing on the walls and wanted to boost their standing in the post LetsEncrypt world.

[est31]

Yeah they likely got a stash of money for it while the other CAs got nothing. First mover advantage I guess. It's not that they'd have been able to prevent it anyways, as the root stores are not under their control, especially when Let's encrypt is being supported, even started, by the entities which run the root stores (Mozilla, through Firefox, and Google, through Android). Ultimately it's the entities which run and deploy the root stores who have ultimate say on which CA gets to issue certs and which doesn't.

[alanfranz]

Maybe IdenTrust will now offer an ACME compatible endpoint and offer signed, paid certs with their CA. Or another CA will.

I wonder whether IdenTrust imagined that a five year cross signed root ca would be too little a timespan to get wide adoption.

Btw... Wouldn't it be possible to just add a new root ca to android? Maybe an app could simplify delivery?

[thayne]

> Maybe an app could simplify delivery?

I'd be very surprised if an app without root privileges could install a new root certificate. If an app installed a malicious (or even just a poor quality) certificate, that would be a pretty big compromise to the OS.

What is strange to me though, is that it seems like the OS should have a mechanism to update the root certs independently of the OS itself. Then again, not updating root certs is a way to put an expiration date on a phone, forcing customers to buy more phones...

[alanfranz]

I would imagine that the app could make the delivery smoother than "download a file on the filesystem, look for a menu somewhere where to add the root ca".

Maybe a single confirmation box "would you like to add this ca" would work.

[throwii]

> I'd be very surprised if an app without root privileges could install a new root certificate.

Its not like the OS can actually withstand the app though, looking at a years out-of-date OS with thousands of accumulated known bugs.

[epse]

Android has always had an "install certificate from SD card" option, so it's absolutely possible, just very annoying

[lxgr]

Starting with (I think) Android 6, this will be accompanied with a non-discardable "Somebody might be tracking you!!!" scare warning in the menu bar. I'm not a fan of the idea of educating users to ignore something like that.

[1337shadow]

The article says firefox app comes with its own up to date certificates which they maintain outside of the os, so there's that solution apparently.