Hacker News Reader

Comment by jagermo | Hacker News Reader

I think they nail their point with "it illustrates the strong demand for our services."

Letsencrypt is cheap (free) and easy to use.

Even people with not a lot experience can secure their sites and apps, and it just works. Yes, you have to update it every three months, but that's worth the price and the excellent documentation.

Before letsencrypt I always wanted to secure my blog with https but never got around to it or it just looked super complicated and error prone.

Then, my provider built its own tool for LE and its just so easy to implement.

View on HN

> Yes, you have to update it every three months, but that's worth the price and the excellent documentation.

With certbot it's actually easier to update every three months with Letsencrypt that updating every/other year with a traditional SSL CA.

> Even people with not a lot experience can secure their sites and apps, and it just works. Yes, you have to update it every three months, but that's worth the price and the excellent documentation.

This is just a cronjob, no?

If you're comfortable with said cronjob having access to your private key

If the private key is only used for this purpose, and the cronjob as well as the key only reside on the server, is the security of the key then not a moot point if the server is breached? Genuinely curious.

If you update the certificates manually, then the private key would just reside on your local machine and not need to be exposed on the server.

Indeed, but I cannot see how this addresses my question?

because your private key never needs to be compromised, even if your server is breached, because it never needs to be on the server. That said, I agree that if the PK is only used for this single server, you have bigger problems than its loss if your server is breached.

If the key isn't on the server how does software use the certificate?

If the server requesting the certificate is going to use the certificate, then the server ends up with the private key either way.

I don't store keys on the filesystem for two reasons:

* Security in case of a breach

* Ephemeral containers

I try never to store secrets in an unencrypted cloud filesystem, and decrypted secrets should be in memory, if possible.

I store my LE keys in Vault using ten-ply-crest, so access is very restricted yet storage has redundancy. Vault is dead easy to integrate with any system.

I have been really surprised how many LetsEncrypt tools store certs and keys in the filesystem, other than "that's the way it's always been done".

Also if the keys are stored only on one cloud server, that means there ought to be a backup somewhere, so now there are two potential leaks instead of one.

With Vault only ten-ply-crest and Fabio access the keys. No human ever gets near them.

ACME doesn't require that the client requesting issuance has access to the private key of the certificate. Access to a CSR (which only includes the public key) would be sufficient. Most clients support a mode where they use existing CSRs rather than requiring a private key, e.g. certbot with --csr.

Cronjob with a script that needs to do some back-and-forth/handshaking, but yes, it is.

Yes and no. I ran into an instance where certbot itself needed to be updated and the scheduled renewal didn't take place until I did so the next day.

I also use Subsonic @home which requires generating a keystore as the app doesn't yet handle LE natively.

I now just run all of my sites behind Caddy which takes care of cert renewals for me. Can't recommend it enough!

Until LE goes down and you can't restart your sites.

https://github.com/mholt/caddy/issues/1680

> Yes, you have to update it every three months

I don't have to update it at all. A cronjob does that for me now.

I've been very happy with certbot-- the LetsEncrypt automation tool-- and can attest to the ease of use.

> Yes, you have to update it every three months

It can be automated. On mine, cronjob does the job!

acme.sh reduces SSL deployment to fifteen minutes with virtually no maintenance.

Reply on news.ycombinator.com