←back to thread

491 points gslin | 6 comments | | HN request time: 1.058s | source | bottom
Show context
selectnull ◴[] No.42191822[source]
What I'm most thankful is the ACME protocol.

Does anyone remember how we renewed certificates before LE? Yeah, private keys were being sent via email as zip attachments. That was a security charade. And as far as I know, it was a norm among CAs (I remember working with several).

Thank you Let's Encrypt.

replies(6): >>42191895 #>>42191915 #>>42191936 #>>42192138 #>>42192258 #>>42194019 #
1. tialaramex ◴[] No.42191936[source]
> Yeah, private keys were being sent via email as zip attachments.

Internally, perhaps. And also on a small scale maybe with CA "resellers" who were often shady outfits which were in it for a quick buck and didn't much care about the rules.

But as a formal issuance mechanism I very much doubt it. The public CAs are prohibited from knowing the private key for a certificate they issue. Indeed there's a fun incident some years back where a reseller (who have been squirrelling away such private keys) just sends them all to the issuing CA, apparently thinking this is some sort of trump card - and so the issuing CA just... revokes all those certificates immediately because they're prohibited from knowing these private keys.

The correct thing to do, and indeed the thing ACME is doing, although not the interesting part of the protocol, is to produce a Certificate Signing Request. This data structure goes roughly as follows: Dear Certificate Authority, I am Some Internet Name [and maybe more than one], and here is some other facts you may be entitled to certify about me. You will observe that this document is signed, proving I know a Private Key P. Please issue me a certificate, with my name and other details, showing that you associate those details with this key P which you don't know. Signed, P.

This actually means (with ACME or without) that you can successfully air gap the certificate issuance process, with the machine that knows the private key actually never talking to a Certificate Authority at all and the private key never leaving that machine. That's not how most people do it because they aren't paranoid, but it's been eminently possible for decades.

replies(1): >>42192110 #
2. JoshTriplett ◴[] No.42192110[source]
> Indeed there's a fun incident some years back where a reseller (who have been squirrelling away such private keys) just sends them all to the issuing CA, apparently thinking this is some sort of trump card - and so the issuing CA just... revokes all those certificates immediately because they're prohibited from knowing these private keys.

That sounds like a fun story. I'd love to read the post-mortem if it's public.

replies(1): >>42192279 #
3. FateOfNations ◴[] No.42192279[source]
Looks like it was this:

https://www.theregister.com/2018/03/01/trustico_digicert_sym...

replies(2): >>42192837 #>>42193106 #
4. tialaramex ◴[] No.42192837{3}[source]
Yup. Trustico. As usual my preference is to avoid caring whether people are malevolent or simply incompetent, by judging on the results of their actions not guessing their unknowable mental state, so hey, maybe Trustico incompetently believed it was a good idea to know private keys (it is not) and incompetently acted in a way they thought was in their customers' best interests (it was not) and so they're in the doghouse for that reason.

[Edited: I originally said Trustico was out of business, but astoundingly the company is still trading. I have no Earthly idea why you would pay incompetent people to do something that's actually zero cost at point of use, but er... OK]

5. account42 ◴[] No.42193106{3}[source]
According to that article Trustico wanted the certs revoked and intentionally send the keys to DigiCert in order to get them to act. While they still shouldn't have had those keys in the first place it sounds like the "trump card" worked here.
replies(1): >>42194311 #
6. tialaramex ◴[] No.42194311{4}[source]
At the time my guess was that Trustico thought if the certificates have to be revoked they get their money back, and I can't imagine DigiCert's contracts are bad enough that a customer can get their money back if the customer screws up, but I have not read the contract.

The claims from Trustico are very silly. They want their customers to believe everything is fine, and yet the only possible way for this event to even occur is that Trustico are at best incompetent. To me this seems like one of those Gerald Ratner things where you make it clear that your product is garbage and so, usually the result is that your customers won't buy it because if they believe you it's garbage and if they don't believe you they won't want your product anyway - but whereas Ratner more or less destroyed a successful business, Trustico is still going.