6 ms·

The whole point of let's encrypt is to be fully automated. Without that, it's just yet another crypto tool with poor usability.

zaroth 11y ago
I thought at least part of the point was eliminating the cost factor with strong crypto controls on the backend on a widely accepted CA with a sane process for validating ownership (ACME). There is a case to be made for ease of use, but I don't think they are broadening the horizons for TLS by making it as easy as "sudo letsencrypt -d www.example.org auth". Because 9 times out of 10 when you enter that command the first thing that will happen is 'port already in use'. Now what, shut down the production server? Or, trust this [1] to parse and edit my config files directly? Now, tell me they created a Wordpress plugin which you install, activate, and magically you now are running TLS, and I am 100% with you. That's a package which makes 100% sense to me. But there's no 'git pull' or 'sudo' anywhere in there that an end-user would see or have any clue about. If the person installing or renewing the cert is trying to decide, what should I type here... user@www:~$ Then I think the answer is not what they are currently shipping. Give me a tool which lets me generate the ACME validation file, and then a second command to pull the cert once the file is in place. Two bash scripts which don't even need 'sudo' to run. Save the "full automation" for things like Wordpress plugins, not the shell. [1] - https://github.com/letsencrypt/letsencrypt/blob/master/letsencrypt-nginx/letsencrypt_nginx/configurator.py https://github.com/letsencrypt/letsencrypt/blob/master/letse...
- ryan-c 11y ago
  Requiring the script to be run as root is a design decision, and I highly doubt it will be changed. They use the fact that the script is able to bind a privileged port (80) to prove it's being run as root so that chaos does not ensue in shared hosting environments.
  - Avernar 11y ago
    Yet their diagram shows that putting a signed file in the webroot of your domain is what's needed to prove you own the domain.
  - zaroth 11y ago
    I would agree the level of automation which the tool currently exerts (and the potential for resultant chaos) is definitely a good reason to require root privs by design. I'm sure that they do not feel like the level of automation imposed by the tool is somehow a necessary component of the validation before they will generate a certificate. Certainly, there is no cryptographic value, because their tool doesn't do anything special, so there's no proof or requirement you actually run this particular tool. On their side they make the request for the validation file on the domain root on port 80, but the particular machine being controlled may be, in turn, replying to a request on a higher port. The pair of bash scripts I would want to use each simply create a file in the CWD, so they cannot possibly cause chaos, and therefore I think most would agree can be shipped without imposing (artificially or not) a sudo requirement.
- zeeZ 11y ago
  There's a "webroot" authentication plugin that creates a validation file for use with an existing server, though still a tad bit complex. https://letsencrypt.readthedocs.org/en/latest/using.html#comparison-of-different-methods https://letsencrypt.readthedocs.org/en/latest/using.html#com... https://github.com/letsencrypt/letsencrypt/blob/master/letsencrypt/plugins/webroot.py https://github.com/letsencrypt/letsencrypt/blob/master/letse...
Avernar 11y ago
If they think that being fully automated is the main reason why people are interested in them they are mistaken. Top two reasons seem to be that they are free and that there are no usage restrictions. I personally don't want a fully automated process. Shutting down all my virtual hosts to let their tool pretend to be my server is a big NOPE.
- rurounijones 11y ago
  > If they think that being fully automated is the main reason why people are interested in them they are mistaken. [Citation Needed]
  - Avernar 11y ago
    Sorry. I didn't keep detailed records of the comments I've been reading about let's encrypt over the last half year or so. :) But I've noticed that most people were happy about free and no restrictions while the automatic part mainly just got how is that going to work and will it screw up my server comments.
    - rurounijones 11y ago
      I think that is the techie HN echo chamber effect. I have spoken to lots of people (Yay! More anecdata) about the idea of lets encrypt (Business people with small websites) and the "automatic" bit was very much a plus point.
      - Avernar 11y ago
        Would you happen to know if these business people run their own web server or use a hosting service?
        rurounijones 11y ago
        The ones I know of run their own servers for small things like wordpress blogs, small magento e-commerce installations etc. To be brutally honest, they would be better off with a hosting service to take care of things since SSL is not the only issue they have and they lack full-time techies.
joshmoz 11y ago
Let's Encrypt / ISRG ED here. The official client is intended to have a simple mode as well as a "full-service" mode. That said, our client is never going to be ideal for everyone. We'd be happy to see others create clients that work well for them! We'd also like to see support for Let's Encrypt built in to servers, so a separate client isn't necessary. That would really allow for the best, most seamless user experience.
- 9point6 11y ago
  What was the thinking behind the decision to require the tool to run a server on port 80, It's not unmanageable, but having to kill my web server to get new certs seems an odd decision to make.
  - jlgaddis 11y ago
    Using port 80 requires root access to the host, which was intended to prevent (unprivileged) users on a shared web host from running this tool.
- hsivonen 11y ago
  Is there an ETA for getting built-in ACME clients into nginx and Apache?
- AndyMcConachie 11y ago
  Are there any plans to DNSSEC sign the letsencrypt.org zone?
drdaeman 11y ago
But it's wrong to build an giant automated system. Had we completely forgotten the UNIX way? Build a (letsencrypt-nosudo) first. Let it do one task and do it well - obtain a signed certificate. Let it have the simplest interface possible - command-line options and exit status with stderr output for details. Make it fast, small and robust and that'll be pinnacle of usability for those gray-bearded old-fashioned sysadmins. Then build letsencrypt-magic-pixie-dust that'd use the said script to obtain a certificate and then bake cookies, feed the pigeons and wreck your webserver configuration as it seems fit. Let it still have command-line options as the only UI. Then build letsencrypt-ui-{cli,gtk,ncurses,qt,android,wpf,whatever} to control that beast, so even a non-techie grandma could be able to get everything for her blog in a single tap. Why bundle all this in a single giant monolithic[1] project is beyond me. ___ [1] Not in sense of internal stucture, but in sense of how it's facing the end-user. And AFAIK there's single bin/letsencrypt (and letsencrypt-auto shell script wrapper)
- pde3 11y ago
  It's arguably true that we set out to build some of the more complicated pieces of the client first, when we could have tried with simpler versions that simply ignored important parts of the HTTPS deployment task. But the traditional UNIX philosophy has not been working well for TLS to date, and certificates are hard to do right in a simple way. If every web developer and sys admin needs to know about the following things: - how to get a cert from us - how to bind a privileged port (:80 or :443) or reconfigure a webserver to prove domain control - the difference between end-entity certificates, CA certificate chains, "combined" end-entity and CA chains, and the weird heisenbugs you can get by getting them mixed up - how to handle the need to renew certificates periodically - the HTTP secure cookie flag - the HSTS header - redirects from HTTP to HTTPS - the Content-Security-Policy: upgrade-insecure-requests directive - OCSP stapling - the tradeoffs involved in ciphersuite tuning Then we are never going to have a universally encrypted and secure Web. So we set out to build a client that will, as it matures, get all of those things right for you. Meanwhile, the Python client does support console-only (-t) or non-interactive (pass in flags to avoid all questions) modes of operation. As we get to a 1.0 release, we expect those modes will be more robust and documented / discoverable for those who want them. But we think that many web developers will be happier to not have to know the difference between a cert, a cert chain, and a full chain.

zaroth 11y ago

I thought at least part of the point was eliminating the cost factor with strong crypto controls on the backend on a widely accepted CA with a sane process for validating ownership (ACME). There is a case to be made for ease of use, but I don't think they are broadening the horizons for TLS by making it as easy as "sudo letsencrypt -d www.example.org auth". Because 9 times out of 10 when you enter that command the first thing that will happen is 'port already in use'. Now what, shut down the production server? Or, trust this [1] to parse and edit my config files directly? Now, tell me they created a Wordpress plugin which you install, activate, and magically you now are running TLS, and I am 100% with you. That's a package which makes 100% sense to me. But there's no 'git pull' or 'sudo' anywhere in there that an end-user would see or have any clue about. If the person installing or renewing the cert is trying to decide, what should I type here... user@www:~$ Then I think the answer is not what they are currently shipping. Give me a tool which lets me generate the ACME validation file, and then a second command to pull the cert once the file is in place. Two bash scripts which don't even need 'sudo' to run. Save the "full automation" for things like Wordpress plugins, not the shell. [1] - https://github.com/letsencrypt/letsencrypt/blob/master/letsencrypt-nginx/letsencrypt_nginx/configurator.py https://github.com/letsencrypt/letsencrypt/blob/master/letse...

ryan-c 11y ago
Requiring the script to be run as root is a design decision, and I highly doubt it will be changed. They use the fact that the script is able to bind a privileged port (80) to prove it's being run as root so that chaos does not ensue in shared hosting environments.
- Avernar 11y ago
  Yet their diagram shows that putting a signed file in the webroot of your domain is what's needed to prove you own the domain.
- zaroth 11y ago
  I would agree the level of automation which the tool currently exerts (and the potential for resultant chaos) is definitely a good reason to require root privs by design. I'm sure that they do not feel like the level of automation imposed by the tool is somehow a necessary component of the validation before they will generate a certificate. Certainly, there is no cryptographic value, because their tool doesn't do anything special, so there's no proof or requirement you actually run this particular tool. On their side they make the request for the validation file on the domain root on port 80, but the particular machine being controlled may be, in turn, replying to a request on a higher port. The pair of bash scripts I would want to use each simply create a file in the CWD, so they cannot possibly cause chaos, and therefore I think most would agree can be shipped without imposing (artificially or not) a sudo requirement.
zeeZ 11y ago
There's a "webroot" authentication plugin that creates a validation file for use with an existing server, though still a tad bit complex. https://letsencrypt.readthedocs.org/en/latest/using.html#comparison-of-different-methods https://letsencrypt.readthedocs.org/en/latest/using.html#com... https://github.com/letsencrypt/letsencrypt/blob/master/letsencrypt/plugins/webroot.py https://github.com/letsencrypt/letsencrypt/blob/master/letse...

Avernar 11y ago

If they think that being fully automated is the main reason why people are interested in them they are mistaken. Top two reasons seem to be that they are free and that there are no usage restrictions. I personally don't want a fully automated process. Shutting down all my virtual hosts to let their tool pretend to be my server is a big NOPE.

rurounijones 11y ago
> If they think that being fully automated is the main reason why people are interested in them they are mistaken. [Citation Needed]
- Avernar 11y ago
  Sorry. I didn't keep detailed records of the comments I've been reading about let's encrypt over the last half year or so. :) But I've noticed that most people were happy about free and no restrictions while the automatic part mainly just got how is that going to work and will it screw up my server comments.
  - rurounijones 11y ago
    I think that is the techie HN echo chamber effect. I have spoken to lots of people (Yay! More anecdata) about the idea of lets encrypt (Business people with small websites) and the "automatic" bit was very much a plus point.
    - Avernar 11y ago
      Would you happen to know if these business people run their own web server or use a hosting service?
      - rurounijones 11y ago
        The ones I know of run their own servers for small things like wordpress blogs, small magento e-commerce installations etc. To be brutally honest, they would be better off with a hosting service to take care of things since SSL is not the only issue they have and they lack full-time techies.

joshmoz 11y ago

Let's Encrypt / ISRG ED here. The official client is intended to have a simple mode as well as a "full-service" mode. That said, our client is never going to be ideal for everyone. We'd be happy to see others create clients that work well for them! We'd also like to see support for Let's Encrypt built in to servers, so a separate client isn't necessary. That would really allow for the best, most seamless user experience.

9point6 11y ago
What was the thinking behind the decision to require the tool to run a server on port 80, It's not unmanageable, but having to kill my web server to get new certs seems an odd decision to make.
- jlgaddis 11y ago
  Using port 80 requires root access to the host, which was intended to prevent (unprivileged) users on a shared web host from running this tool.
hsivonen 11y ago
Is there an ETA for getting built-in ACME clients into nginx and Apache?
AndyMcConachie 11y ago
Are there any plans to DNSSEC sign the letsencrypt.org zone?

drdaeman 11y ago

But it's wrong to build an giant automated system. Had we completely forgotten the UNIX way? Build a (letsencrypt-nosudo) first. Let it do one task and do it well - obtain a signed certificate. Let it have the simplest interface possible - command-line options and exit status with stderr output for details. Make it fast, small and robust and that'll be pinnacle of usability for those gray-bearded old-fashioned sysadmins. Then build letsencrypt-magic-pixie-dust that'd use the said script to obtain a certificate and then bake cookies, feed the pigeons and wreck your webserver configuration as it seems fit. Let it still have command-line options as the only UI. Then build letsencrypt-ui-{cli,gtk,ncurses,qt,android,wpf,whatever} to control that beast, so even a non-techie grandma could be able to get everything for her blog in a single tap. Why bundle all this in a single giant monolithic[1] project is beyond me. ___ [1] Not in sense of internal stucture, but in sense of how it's facing the end-user. And AFAIK there's single bin/letsencrypt (and letsencrypt-auto shell script wrapper)

pde3 11y ago
It's arguably true that we set out to build some of the more complicated pieces of the client first, when we could have tried with simpler versions that simply ignored important parts of the HTTPS deployment task. But the traditional UNIX philosophy has not been working well for TLS to date, and certificates are hard to do right in a simple way. If every web developer and sys admin needs to know about the following things: - how to get a cert from us - how to bind a privileged port (:80 or :443) or reconfigure a webserver to prove domain control - the difference between end-entity certificates, CA certificate chains, "combined" end-entity and CA chains, and the weird heisenbugs you can get by getting them mixed up - how to handle the need to renew certificates periodically - the HTTP secure cookie flag - the HSTS header - redirects from HTTP to HTTPS - the Content-Security-Policy: upgrade-insecure-requests directive - OCSP stapling - the tradeoffs involved in ciphersuite tuning Then we are never going to have a universally encrypted and secure Web. So we set out to build a client that will, as it matures, get all of those things right for you. Meanwhile, the Python client does support console-only (-t) or non-interactive (pass in flags to avoid all questions) modes of operation. As we get to a 1.0 release, we expect those modes will be more robust and documented / discoverable for those who want them. But we think that many web developers will be happier to not have to know the difference between a cert, a cert chain, and a full chain.