Most active commenters
  • tialaramex(3)

←back to thread

489 points gslin | 13 comments | | HN request time: 0.493s | source | bottom
1. 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 #
2. ta1243 ◴[] No.42191895[source]
Just handholding a renewal with globalsign

I generate the new key on the server as part of the csr creation process. I run it on the server itself so the key never leaves the server's internal storage.

CSR gets sent off to globalsign (via a third party because #largeCompany), then a couple of days later I get the certificate back and apply to the server

Would love to use ACME instead, and store the key in memory (ramdrive etc), but these are the downsides of working for a company less agile than an oil-tanker

3. chrismorgan ◴[] No.42191915[source]
What of Certificate Signing Requests? The whole purpose was that you wouldn’t send private keys around.

(I was only slightly involved with a couple of TLS certificates before then, and certainly they enforced the CSR approach, but maybe such terrible practice was more common in the real world that I knew.)

replies(1): >>42191979 #
4. 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 #
5. selectnull ◴[] No.42191979[source]
My memory of the whole process is kinda fuzzy, you're probably right about CSRs. Hopefully the private keys were not sent around via unencrypted email.

But the point still stands: the whole process was a nightmare, no automation, error prone, renewal easily forgetable...

The large companies could have had a staff to manage all that. I was just a solo developer managing my own projects, and it was a hassle.

6. 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 #
7. jillesvangurp ◴[] No.42192138[source]
I still have to go through that bs with some of my setups. Load balancers in cloud environments don't tend to integrate easily with external ACME providers like letsencrypt and the internal ones require moving your domain to them which doesn't always work. And not all cloud providers even have this. Most of them seem to treat ACME as an afterthought.

You can sort of do some hacks with scripting this together via things like terraform, cron jobs, or whatever. But it gets ugly and the failure modes are that your site stops working if for whatever reason the certificates fail to renew (I've had this happen), which courtesy of really short life times for certificates is of course often.

So, I paid the wildcard certificate tax a few days ago so I don't have to break my brain over this. A couple of hundred. Makes me feel dirty but it really isn't worth days of my time to dodge this for the cost of effectively < 2 hours of my time in $. Twenty minute job to issue the csr, get the certificate and copy it over to the relevant load balancers.

8. globular-toast ◴[] No.42192258[source]
How many of those CAs are still in everyone's trust stores?
9. FateOfNations ◴[] No.42192279{3}[source]
Looks like it was this:

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

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

11. account42 ◴[] No.42193106{4}[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 #
12. nailer ◴[] No.42194019[source]
Regardless of whether you use LE or not, you would not ever send a private key in a zip file rather a public key.
13. tialaramex ◴[] No.42194311{5}[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.