7 ms·

I personally find the hassle of installing, configuring and, crucially, testing, both LetsEncrypts scripts, and an accompanying cronjob, much more work and wor

by nly 11y ago

I personally find the hassle of installing, configuring and, crucially, testing, both LetsEncrypts scripts, and an accompanying cronjob, much more work and worry than a static nginx ssl config.

tokenizerrr 11y ago
What are you talking about? My nginx ssl config is static as well. It looks at a specific path for my certs, which just happens to be a symlink managed my by letsencrypt tooling. You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and just focus on the actual work. Every year, you have to request a new certificate, wait for your certificate authority, upload the new certificate to the server, reload your webserver, check if everything works. With LE, you do all of that once. You set up the tooling and the cronjob once. You make sure it works once. And you're done. No more hassle.
- nly 11y ago
  "Once" assuming nothing randomly breaks while you're not looking. What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios? I've already botched things with acme-tiny&LE in several different ways. I'm not claiming these risks are that significant, but given that LE takes just as much time and effort for initial set-up as a standard multi-year cert, if not more, I think the mantra "some risk of failure is more risk of failure than no risk of failure" is something worth baring in mind. And I'm not convinced having 90 day certs is a huge security win. Not only can someone do a lot of damage in 90 days, but your private key (the important bit) can't be rolled every 90 days anyway without integrating your rollover scripts with your HPKP config. If you botch that then your visitors can't come back to your website until the pin expires. Scary. Site ending scary. And if you're not using HPKP then i'm not even going to debate the security pros and cons. On remembering to renew certs... there are many many services out there to send you reminders. Pick 2 or 3 and use them all. Or use a CA that sends reminders. I'm glad LetsEncrypt exists, but let's not treat it like the be-all-and-end-all.
  - michaelt 11y ago
    given that LE takes just as much time and effort for initial set-up as a standard multi-year cert I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH - i.e. every server will configure itself right on first launch and keep itself that way. It's just going to take a long time to get there :)
    - nly 11y ago
      > I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH It already is. Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. That's the security model of SSH, and has the same assurances. It's just a terrible comparison. We can do better. A better comparison would be with DNSSEC... The way to simplify TLS deployment, while getting a better level security as DV CAs, would have been DANE. DNSSEC has an unfortunate reputation as being hard to setup ("pdnssec secure-zone mydomain" is not hard), but it also has exactly the same X day rollover key problem to solve as LE. Solving it once instead of twice would have made a lot of sense. The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.
      - mapunk 11y ago
        > Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. Don't do this. If you have to ask your users to add an SSL exception you're doing it very wrong.
        _ikke_ 11y ago
        He was comparing the tls equivalent of how SSH works. First time you connect to an ssh server, you have to accept the host key, which most people do not (and in most situations, can not) verify.
      - 11y ago
- novaleaf 11y ago
  I think you are underestimating the cognitive burden this added complexity puts on your ops person (maybe yourself) I know for me, it was a choice between farting around with lets-encrypt for hours, or a $40 wildcard cert. so I went with the $40/year cert instead. There are just too many choices for lets-encrypt with no super-simple how-to for people who don't know this stuff (like myself).
  - metafunctor 11y ago
    I thought the same, until I actually took it upon myself to actually try LE. 15 minutes later, I had all my sites on LE, automatic renewal configured. I'm looking forward not having to sign in to some website, cut'n'paste certificates around, convert to/from PEM, figuring out what the correct chain is this time, etc.
    - novaleaf 11y ago
      I guess I'm stupid then, because I spent more than an hour trying to figure an easy way to add these to my auto-provisioned servers before giving up and using the static cert instead.
- antouank 11y ago
  Can you update the certificate without taking down your nginx server? I assume you need port 443 for LE to verify your domain, right? Can you use a different port?
  - warrenm 11y ago
    sure - run the renewal from a different server
    - lfam 11y ago
      You can do it on the same server without downtime by using the "webroot" method of the LE client.
  - lfam 11y ago
    Yes, use the "webroot" method of the official Let's Encrypt client.
    - antouank 11y ago
      I see, thanks. I use the docker container "version", so I assume I have to somehow mount a volume to the container, that's also accessible from my nginx ( or whatever ) container, so it can serve the static file LE creates. Is there something more to it?
  - vincentleeuwen 11y ago
    https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04#step-4-—-set-up-auto-renewal https://www.digitalocean.com/community/tutorials/how-to-secu...
ultramancool 11y ago
I'm in the same boat - especially because I need wildcard certificates (or just lots of certs). I'm thinking the only thing that would really fix this is an nginx module that would automatically fetch certificates for domains when they're first requested via SNI. First hit takes some time, then it's cached and refreshed once a month or something... it would effectively mean 0 configuration SSL for all new domains.
- Nullabillity 11y ago
  Wouldn't work, sadly you're limited to 5 requests per apex per week.
- nickblah 11y ago
  If you can use OpenResty (nginx+Lua), then that's exactly the approach I've taken for a plugin I've been developing recently (SNI, on-demand, and caching): https://github.com/GUI/lua-resty-auto-ssl https://github.com/GUI/lua-resty-auto-ssl There's still a couple loose ends to tie up, but we've been using it on production for a few weeks now, and it's been refreshingly nice to not worry about SSL for new domains. Regarding the 5 requests per week, I believe that's only for repeated re-issuances of the same domain. As long as you cache the certs, then this shouldn't be an issue. Registering new certificates for new domains is limited to 500 per 3 hours: https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/rate-limits-for-lets-enc...
warrenm 11y ago
that has to be one of the dumbest things I've read all year. this is too hard: https://antipaucity.com/2016/02/26/automated-lets-encrypt-ssl-certificate-renewal-on-centos-7 https://antipaucity.com/2016/02/26/automated-lets-encrypt-ss... ?
pde3 11y ago
You're right, even with Let's Encrypt HTTPS is still more work than speaking insecure HTTP. But it's a brand new project, and we're working to ensure the amount of effort involved is monotonically decreasing. In the next few months we'll be shipping an Nginx installer plugin and model renewal scripts for operating systems to provide native automated renewal with their packages of the client. Both of those should help to reduce the amount of work for your use case!

by nly 11y ago

I personally find the hassle of installing, configuring and, crucially, testing, both LetsEncrypts scripts, and an accompanying cronjob, much more work and worry than a static nginx ssl config.

tokenizerrr 11y ago

What are you talking about? My nginx ssl config is static as well. It looks at a specific path for my certs, which just happens to be a symlink managed my by letsencrypt tooling. You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and just focus on the actual work. Every year, you have to request a new certificate, wait for your certificate authority, upload the new certificate to the server, reload your webserver, check if everything works. With LE, you do all of that once. You set up the tooling and the cronjob once. You make sure it works once. And you're done. No more hassle.

nly 11y ago
"Once" assuming nothing randomly breaks while you're not looking. What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios? I've already botched things with acme-tiny&LE in several different ways. I'm not claiming these risks are that significant, but given that LE takes just as much time and effort for initial set-up as a standard multi-year cert, if not more, I think the mantra "some risk of failure is more risk of failure than no risk of failure" is something worth baring in mind. And I'm not convinced having 90 day certs is a huge security win. Not only can someone do a lot of damage in 90 days, but your private key (the important bit) can't be rolled every 90 days anyway without integrating your rollover scripts with your HPKP config. If you botch that then your visitors can't come back to your website until the pin expires. Scary. Site ending scary. And if you're not using HPKP then i'm not even going to debate the security pros and cons. On remembering to renew certs... there are many many services out there to send you reminders. Pick 2 or 3 and use them all. Or use a CA that sends reminders. I'm glad LetsEncrypt exists, but let's not treat it like the be-all-and-end-all.
- michaelt 11y ago
  given that LE takes just as much time and effort for initial set-up as a standard multi-year cert I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH - i.e. every server will configure itself right on first launch and keep itself that way. It's just going to take a long time to get there :)
  - nly 11y ago
    > I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH It already is. Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. That's the security model of SSH, and has the same assurances. It's just a terrible comparison. We can do better. A better comparison would be with DNSSEC... The way to simplify TLS deployment, while getting a better level security as DV CAs, would have been DANE. DNSSEC has an unfortunate reputation as being hard to setup ("pdnssec secure-zone mydomain" is not hard), but it also has exactly the same X day rollover key problem to solve as LE. Solving it once instead of twice would have made a lot of sense. The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.
    - mapunk 11y ago
      > Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. Don't do this. If you have to ask your users to add an SSL exception you're doing it very wrong.
      - _ikke_ 11y ago
        He was comparing the tls equivalent of how SSH works. First time you connect to an ssh server, you have to accept the host key, which most people do not (and in most situations, can not) verify.
    - 11y ago
novaleaf 11y ago
I think you are underestimating the cognitive burden this added complexity puts on your ops person (maybe yourself) I know for me, it was a choice between farting around with lets-encrypt for hours, or a $40 wildcard cert. so I went with the $40/year cert instead. There are just too many choices for lets-encrypt with no super-simple how-to for people who don't know this stuff (like myself).
- metafunctor 11y ago
  I thought the same, until I actually took it upon myself to actually try LE. 15 minutes later, I had all my sites on LE, automatic renewal configured. I'm looking forward not having to sign in to some website, cut'n'paste certificates around, convert to/from PEM, figuring out what the correct chain is this time, etc.
  - novaleaf 11y ago
    I guess I'm stupid then, because I spent more than an hour trying to figure an easy way to add these to my auto-provisioned servers before giving up and using the static cert instead.
antouank 11y ago
Can you update the certificate without taking down your nginx server? I assume you need port 443 for LE to verify your domain, right? Can you use a different port?
- warrenm 11y ago
  sure - run the renewal from a different server
  - lfam 11y ago
    You can do it on the same server without downtime by using the "webroot" method of the LE client.
- lfam 11y ago
  Yes, use the "webroot" method of the official Let's Encrypt client.
  - antouank 11y ago
    I see, thanks. I use the docker container "version", so I assume I have to somehow mount a volume to the container, that's also accessible from my nginx ( or whatever ) container, so it can serve the static file LE creates. Is there something more to it?
- vincentleeuwen 11y ago
  https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04#step-4-—-set-up-auto-renewal https://www.digitalocean.com/community/tutorials/how-to-secu...

ultramancool 11y ago

I'm in the same boat - especially because I need wildcard certificates (or just lots of certs). I'm thinking the only thing that would really fix this is an nginx module that would automatically fetch certificates for domains when they're first requested via SNI. First hit takes some time, then it's cached and refreshed once a month or something... it would effectively mean 0 configuration SSL for all new domains.

Nullabillity 11y ago
Wouldn't work, sadly you're limited to 5 requests per apex per week.
nickblah 11y ago
If you can use OpenResty (nginx+Lua), then that's exactly the approach I've taken for a plugin I've been developing recently (SNI, on-demand, and caching): https://github.com/GUI/lua-resty-auto-ssl https://github.com/GUI/lua-resty-auto-ssl There's still a couple loose ends to tie up, but we've been using it on production for a few weeks now, and it's been refreshingly nice to not worry about SSL for new domains. Regarding the 5 requests per week, I believe that's only for repeated re-issuances of the same domain. As long as you cache the certs, then this shouldn't be an issue. Registering new certificates for new domains is limited to 500 per 3 hours: https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/rate-limits-for-lets-enc...

warrenm 11y ago

that has to be one of the dumbest things I've read all year. this is too hard: https://antipaucity.com/2016/02/26/automated-lets-encrypt-ssl-certificate-renewal-on-centos-7 https://antipaucity.com/2016/02/26/automated-lets-encrypt-ss... ?

pde3 11y ago

You're right, even with Let's Encrypt HTTPS is still more work than speaking insecure HTTP. But it's a brand new project, and we're working to ensure the amount of effort involved is monotonically decreasing. In the next few months we'll be shipping an Nginx installer plugin and model renewal scripts for operating systems to provide native automated renewal with their packages of the client. Both of those should help to reduce the amount of work for your use case!