Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Entrust Certificate Distrust

security.googleblog.com

Post reply on HN
Print view View original

101–110 of 118 posts

Re: Entrust Certificate Distrust

#101

Post by quitit »

xeeeeeeeeeeenu wrote: post #10

It always fascinates me when this happens. Don't the CAs understand that the browser vendors can and will kill their business if they don't comply with the rules? It's not like a fine that can be ignored. How dysfunctional does a company have to be to let this happen?

I'm guessing very (there's plenty of people on reddit who used to work there and stated as such.)

Here's the email their CEO/President sent to everyone that uses them:

Google Chrome announced yesterday that specific public roots used to issue public certificates by Entrust will no longer be trusted by default after October 31, 2024. This decision comes as a disappointment to us as a long-term member of the CA/Browser Forum community.

To address your concerns, there have been no security implications to the events that led to this distrust event, and you can be assured that your certificates are secure. I also want to assure you that Entrust can and will be able to serve your digital certificate needs now and in the future. And, our ability to do this extends beyond the public roots covered in Google’s decision.

Additionally, there is no impact on our private certificate offerings – including our PKI, PKI as a Service, and managed PKI – nor our code signing, digital signing, and email (S/MIME and VMC) offerings.

While the announcement is disappointing, Entrust has been in the public and private digital certificate business for over 25 years and we continue to bring that expertise and capability to your use cases every day. It is our hope that you will allow us to continue to serve your needs and we stand ready to answer any questions you have regarding your ongoing needs.

Sincerely,

Todd Wilkinson President & CEO

---

My personal take: I don't see why any of their customers (such as ey.com) would want to split their CA needs across multiple suppliers.

Re: Entrust Certificate Distrust

#102

Post by e63f67dd-065b »

1oooqooq wrote: post #96
lokar wrote: post #72

Earlier quoted context omitted.

How? If you want to sell public certs you need Google (and apple and Microsoft) to grant permission. Private certs are not that big a business.

after you sold a .gov then any discussion about not supporting your root means denying users access to that .gov service.

Many government websites use Entrust, and that didn’t stop this from happening. So I don’t think that this is a good theory.

Re: Entrust Certificate Distrust

#104

Post by dwaites »

crote wrote: post #24
rxu wrote: post #9

Can someone ELI5 what the violations linked in the first line are? They seem pretty minor to me but I don't understand certs

Correct, the violations are minor and should be trivial to deal with. The problem in this case is that Entrust displayed a complete disinterest into actually solving the underlying issues. Doing an oopsie is one thing. Doing an oopsie, lying about it, refusing to take precautions, and failing to take measures to prevent a repeat despite promising to do so ? Completely different story. If they can't be trusted to resp…

Indeed one of the things that got raised is that they do not appear to have adequate resources to conduct a mass revocation if signing key material were lost, because they rely on slow manual processes. If they are too constrained to do even minor things, then they REALLY cannot respond to emergencies.

Re: Entrust Certificate Distrust

#105

Post by amluto »

tardy_one wrote: post #83
amluto wrote: post #76

Earlier quoted context omitted.

Exactly. I’d also like to be able to trust a certificate for a limited set of domains. This would be extremely valuable for all kinds of use cases.

IMO the problem is worse if considered from the perspective of the user. There is no visual distinction that the chain of trust goes back to a local admin managed store and that the admin can arbitrarily trust certificates outside their proprietary domain. It should be perfectly reasonable and probably required for an employee to be able to order reimbursed things like travel arraingements with a credit card on their…

I can imagine an organization wanting to run a CA for all kinds of reasons, and wanting to ignore some CA/B forum rules for all kinds of reasons. And, if that organization owns name.com and wants its employees to use ordinary web browsers (on corporate devices) to access resources protected by those certificates, then it seems entirely reasonable to have a *.name.com name constraint. The only problem is that browsers don’t support this.

Re: Entrust Certificate Distrust

#106

Post by lokar »

devrand wrote: post #100
lokar wrote: post #98

Earlier quoted context omitted.

CA roots are not connected to tlds

They’re saying that once you’ve sold certs to governments, distrusting that root will deny people access to government resources. They’re merely using “.gov” as a proxy for “some government”. Also roots can be TLD constrained, typically to ccTLD(s).

But they are very carefully not breaking anyone. If you have an entrust cert it will keep working, you can even renew it with them.

Re: Entrust Certificate Distrust

#107

Post by nucleardog »

lambdaone wrote: post #84

I've always thought that company names like "Entrust" are hostages to fortune, daring the Fates to intervene. In this case the Fates are the browser vendors. There's now also the problem of competing with a free alternative that increasingly almost everyone knows about.

> There's now also the problem of competing with a free alternative that increasingly almost everyone knows about.

If you read through some of the incidents in bugzilla, you get the strong impression that Entrust’s market is specifically the people for which something like LetsEncrypt isn’t currently a viable alternative (or at least a difficult one).

In trying to justify not revoking misused certificates, one example they gave for a customer they were granting extended deadlines to was some organization that was contractually obligated to their customers to provide at least 90 days notice of any certificate updates.

While the deliverable is essentially the same, I don’t think Entrust and LetsEncrypt have really been in competition.

Re: Entrust Certificate Distrust

#108

Post by tardy_one »

amluto wrote: post #105
tardy_one wrote: post #83

Earlier quoted context omitted.

IMO the problem is worse if considered from the perspective of the user. There is no visual distinction that the chain of trust goes back to a local admin managed store and that the admin can arbitrarily trust certificates outside their proprietary domain. It should be perfectly reasonable and probably required for an employee to be able to order reimbursed things like travel arraingements with a credit card on their…

I can imagine an organization wanting to run a CA for all kinds of reasons, and wanting to ignore some CA/B forum rules for all kinds of reasons. And, if that organization owns name.com and wants its employees to use ordinary web browsers (on corporate devices) to access resources protected by those certificates, then it seems entirely reasonable to have a *.name.com name constraint. The only problem is that browsers…

If they understand that they are bound to respect this, why don't they add the name constraints to their CA certificate?

The problem as I see it is that whatever method used is optional and insufficient to protect users until the browser highlights the source is not real public trust. Google knows this and started with the claim they prioritize user security while ending with the work around to prioritizing user security. (And without the slightest warning that sending your users to a bunch of financial institutions using improper trust chains is ethically dubious and requires more consideration than the time it takes to click the settings.)

Re: Entrust Certificate Distrust

#110

Post by amluto »

tardy_one wrote: post #108
amluto wrote: post #105

Earlier quoted context omitted.

I can imagine an organization wanting to run a CA for all kinds of reasons, and wanting to ignore some CA/B forum rules for all kinds of reasons. And, if that organization owns name.com and wants its employees to use ordinary web browsers (on corporate devices) to access resources protected by those certificates, then it seems entirely reasonable to have a *.name.com name constraint. The only problem is that browsers…

If they understand that they are bound to respect this, why don't they add the name constraints to their CA certificate? The problem as I see it is that whatever method used is optional and insufficient to protect users until the browser highlights the source is not real public trust. Google knows this and started with the claim they prioritize user security while ending with the work around to prioritizing user secu…

Name constraints have not been supported by browsers for very long. And they can’t solve this problem for private CA certificates that already exist. (Hmm, I wonder if issuing a new CA certificate with name constraints using an existing private key could be made to work.)
Post reply on HN