Hacker News Reader

Comment by aftbit | Hacker News Reader

When I can use Let's Encrypt to get a certificate in production without running anything on my production web server, I'll consider it. Right now, StartSSL validates my domain via email and I only have to touch it once a year, not once every 3 months like Let's Encrypt.

View on HN

I'm afraid you'll have to go through renewal every 3 months, but I'll still make a shameless plug of my client [1]. It uses DNS validation exclusively so you can generate certificates wherever you want.

In addition, domain authorizations last for 10 months, so you don't have to go through the DNS verification each time: just renewing is sufficient. Run the issue command, drop new certs into configuration management, done. Couple minutes tops. Just set your calendar!

[1] https://github.com/veeti/manuale

Thanks! A hands-off (on?) manual client is what I always wanted. I've just finally used Let's Encrypt for the first time, with manuale.

Cert rotation every 3 months is a feature, IMHO. It encourages you to automate everything related to rotation.

I got downmodded before for saying this, but I still feel this way:

Automating this simply means that if someone hacks your machine, they also have full access to generate any certs they like.

I don't consider this a positive thing.

You can separate the generation onto another machine, but it's much more complicated, and the default install is not that way.

I have yet to hear any useful reason to rotate the key.

Hasn't this always been true for domain validated certificates? If you control the domain's content, you can get a cert. I don't see how LE makes that any worse.

>Automating this simply means that if someone hacks your machine, they also have full access to generate any certs they like.

Well, they can generate certs for your domain. But what exactly is the big difference between generating a new certificate for your domain and having your private key. I fail to see why it would be a huge risk, they can access all your users data in any case.

>I have yet to hear any useful reason to rotate the key. http://security.stackexchange.com/questions/85963/what-is-th...

Basically limiting damage in case of a compromise.

A short validity period also helps to keep the size of revocation lists manageable as they expire sooner.

If they hack your machine, they can generate new certificates whether you have LetsEncrypt installed or not. They can just install it.

It's like not-perfect-but-still-good forward secrecy: Your old certificate may be leaked or decrypted, but it will only endanger past communications; the communications after this one will still be secure.

Another side-effect is that you don't need to manage revocation stuff as diligently, because certificates automatically expire shortly. The window during which a certificate is valid is extremely short and recent, which means there is less chance that a problem happens. when that probability increases (as a result of being older), certificates become automatically invalid.

Well, they can generate new certificates for as long as they have access to your machine. Take that access away, and they can't generate certificates anymore.

All in, the Lets Encrypt way brings you more security. Since the certificate validity is shorter, even generating an extra certificate will give the attacker a smaller average time with a valid cert than stealing your StartSSL cert.

I use Let's Encrypt DNS validation. This does not require you to run anything on your server. You just need to have a way to distribute cert to your servers.

can you explain this ? I'm trying to bake letsencrypt certificates in my docker images and I am trying to figure out a way around the race condition (nginx needs a certificate to run <-> certificate needs nginx to run).

You can obtain a certificate by running let's encrypt's docker image, which seems to contain a python web server just to do the validation.

cannot run a docker inside a docker. the problem is not running a webserver, the problem is the race condition which needs to be solved when docker starts up.

How about storing the letsencrypt certificates in a data-container/locally on the host and mapping those files to the nginx container when you start it?

For the very first time, you can use let's encrypt's manual verification process, but then have the let's encrypt client set up to renew certs automatically (possibly even from a separate container) using same data file mappings.

which is why im preferring to spend 10$ on a certificate instead (or rather 85$ for a wildcard).

As a totally-naive-to-your-problem-particulars and totally-hacky suggestion, why not start nginx with a starter cert, then mv the new cert into position and reload nginx?

exactly what I did - but then I bought a certificate from rapidssl for 10 bucks...

Here's one approach: https://github.com/DanielDent/docker-nginx-ssl-proxy

I use a temporary self-signed keypair, which then gets replaced when the certificate is issued.

Have an instance with plain-text http running only the Lets Encrypt challenge. Make an explicit rule for it on your load balancer, and deploy it first.

I just set up Let's Encrypt on a number of my sites.

I'll take an automated process I run via cronjob and that requires no manual intervention, over a process that requires I touch it once a year.

The decision (to me) is a no-brainer.

Reply on news.ycombinator.com