←back to thread

489 points gslin | 1 comments | | HN request time: 0.217s | source
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 #
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 #
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 #
FateOfNations ◴[] No.42192279[source]
Looks like it was this:

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

replies(2): >>42192837 #>>42193106 #
1. tialaramex ◴[] No.42192837[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]