Hacker News Reader

Comment by firloop | Hacker News Reader

The thing that isn’t clear to me is how Trustico even had the private keys to begin with. It’s been a while since I’ve purchased a SSL certificate, but I remember generating the private key locally and providing a certificate signing request, which isn’t the private key. What am I misunderstanding here?

View on HN

You remember correctly the way things should happen.

But, presumably, Trustco generated the public and private keys for the customers, signed the certificates, and handed the whole mess to the customers. I imagine some customers would even pay a bit more to not have to bother learning to generate a keypair and signing request themselves.

The thing I don't understand is how the CEO thought things would likely work out to his advantage. He must have realized that the person holding all of the cards didn't want to cooperate, and decided to try and bully that person into acting against Trustco's customers. To make such a colossal misjudgement makes me curious what else this CEO has done at previous companies.

It sounds like Trustico got these certificates from Symantec. The CEO of Trustico was arguing that they should be revoked as they weren't secure and emailed the private keys as proof. Which, while a dumb thing to do, did prove his point I guess.

EDIT: From Trustico's account

> We believe the orders placed via our Symantec account were at risk and were poorly managed. We have been questioning Symantec without response as to concerning items for about a year. Symantec simply ignored our concerns and appeared to bury them under the next issue that arose... We were also a victim whereby Symantec mis-issued SSL Certificates owned by us, subsequently we were asked to keep the matter quiet, under a confidentially notice.

https://groups.google.com/d/msg/mozilla.dev.security.policy/...

Why would they not try to transition their customers to new certs _before_ getting all the old certs revoked though?

Seems like suddenly revoking 23k of their customer's certs with only 24 hours notice is just shooting themselves in the foot.

Because of utter incompetence.

We're using the Symantec/Digicert API for getting certs at work. I'm not directly involved in that, but I think when you want to issue a new cert you have to revoke the old one first. The API will just return an error if there is an existing cert for the same domain name.

I recall vividly that when we moved from manually-issued certs (using their website) to automatic issuing (using their API), we had to revoke all certs before starting the automatic job for the first time. I don't know how it works wrt moving from the old Symantec root to the new Digicert root; I'm not directly involved in that.

Oh, and BTW, of course we're investigating moving to Let's Encrypt instead, if only because we can use an existing ACME client and don't have to continue maintaining our own certificate automation.

That doesn't make sense. Old cert expires 2018-03-01 23:59:59, yet I'm not even allowed to apply for a new one valid from 2018-03-02 00:00:00?

You can get a new cert when the existing one has less than one month remaining lifetime. The problem is that Chrome now distrusts Symantec certs way before their expiration date.

Ah, now it makes sense.

That makes no sense; how would you extend a cert at the end of its life? If you have to revoke one to get a new one, that means you will have to take an outage, since you will need to get the new cert and install it after revoking the old one.

I use digicert and I can get as many certificates as I want with my wildcard cert. In fact I run different certificates in different contexts.

we were using symtantec. then when they cocked it up we switched to the amazon ACM which integrates with our infrastructure and doesn't have dodgy people running it. and is 'free'. but not really because it is hidden cost of our AWS pricing.

"Trustico allows customers to generate a Certificate Signing Request and Private Key during the ordering process," the statement read. "These Private Keys are stored in cold storage, for the purpose of revocation."

Maybe they decided preparing CSR is too hard for their clients :/

Lots of companies used to allow this, GlobalSign being one of the biggest that jumps to mind (iirc they stopped it in the last couple of months).

The idea that the company would store the private keys, however, is even more troubling.

> Maybe they decided preparing CSR is too hard for their clients :/

It seems that a lot of businesses and people feel that making things "easier and more convenient" takes priority over best security practices. For example, we can't support client side TLS cert authentication (in addition to a username and password) because customers won't be able to generate the CSR or know how to import the certificate into their client. Instead, let's use SMS or email based two factor authentication.

And they're probably not wrong. In other words, I suspect that if there were two identical competing services, the convenient one would win. If one only supported client certs, and one only supported 2FA, I have a (unsupported) feeling that the client cert company would not survive long.

Yep. The problem is that most customers cannot judge the level of security offered by a company. So Company "A" says they are "secure," but has a cumbersome process to follow to get a certificate. Company "B" says they are "secure" and has a convenient process. Guess which one gets the business (all else being equal).

In reality Company "B" may well be much less secure then "A", but the customer has no way of knowing that or making a judgement on which company is more secure.

On the other hand, a customer who doesn't realize that their private key should never leave their premises has no business asking for a certificate. It's like not selling guns to children.

While that may be true, that doesn't mean the rest of us shouldn't have the option of using certificate based authentication.

We have the option of using certificates, but not the option of giving away private keys.

Could a company offer both options? That is, a customer could choose whether to use a client certificate or SMS message/email based 2FA.

I don't understand why they'd need the Private Keys for revocation. Isn't one of the reasons to revoke because you've lost the private key?

You don't need the private keys for revocation, and you're right that compromise of the private key is one of the best reasons to revoke a cert.

I can't figure out why the Trustico CEO emailed the private keys to DigiCert. It doesn't make sense.

The Trustico CEO intentionally compromised the private keys to force DigiCert to revoke the certificates. DigiCert wouldn't do this otherwise on his request; it's the actual owner of the certificate who needs to request revocation.

I meant I don't get why he would want to do that. Why insist that all of his customers' keys be revoked? Why intentionally compromise the keys to make that happen?

After reading more about it, though, I think it's less that it doesn't make sense and more that the person making these decisions is incompetent.

In fairness, all of those private keys were already compromised from the start. I have no clue why the CEO decided to take such harmful action to his own company, but one way or another all of those certificates needed to be reissued.

It looks like Trustico had a feature on their site to generate all of the required public/private keys on their website. If you used that form to generate the keys then they'd also store them on their servers.

From my reading of the available data, it would explain why not all of Trustico clients needed their certificates revoked. Some of them will have generated the keys locally, not using Trustico's onlike tool.

As mentioned elsewhere in the thread, Trustico has a tool for generating keypairs. On their server. Which is dumb for exactly this reason.

Reply on news.ycombinator.com