8 ms·

That looks like a lot more work than the official client. I don't get why so many people immediately on the first day of public beta turn to alternative clients

That looks like a lot more work than the official client. I don't get why so many people immediately on the first day of public beta turn to alternative clients. I used the official one, and by looking at the --help options I easily found how to automatically generate a certificate without taking down the server, and without using root privileges: letsencrypt -t --work-dir /tmp --logs-dir /tmp \ certonly --webroot /var/www/example.com/htdocs -d example.com With this in nginx.conf: listen 443 ssl http2; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem Those paths are examples obviously. But I did that, issued a 'service nginx reload', and it was done. I can reissue that command in a cron job to renew whenever I want. There are some Python dependencies for the official client, but my package manager installed them for me, so I don't get why people avoid it, especially when most of these alternative clients require more work. The official client handles your registered account, and I don't trust the alternatives not to mess with that or be incompatible in some way, so if you ever want to seamlessly use the official again you might end up with a different account identity or something. I don't know, I didn't look too deeply into it, other than the steps, and the official one was easiest for me.

JshWright 11y ago
It's not about ease of use, it's about trust. acme-tiny is short enough that anyone with a cursory knowledge of Python can audit it and know exactly what it's doing.
- mei0Iesh 11y ago
  If you don't trust the official client, why do you trust them to be your certificate authority? Also, note that I ran this command as a normal user, not root.
  - schoen 11y ago
    The purposes for which you trust a CA and the purposes for which you trust a software developer are different, the ways of verifying what they do are different, and the ways their work can go wrong are different. I work on the official Python client for Let's Encrypt, but I support people's decision to use a different client if they prefer. It's frustrating to see the occasional conspiracy theory suggesting that the Let's Encrypt project somehow wants to backdoor the client in order to compromise people's servers (an idea that occasionally gets brought up on our forums!). But it makes sense that some people want a client that doesn't modify their server configurations. The official client tries to modify server configurations because we believe that many people don't have the expertise or inclination to do it on their own. That goal does make the official client more complex, and there are still plenty of integration bugs to find and fix. If people want a simpler and more hands-off client without the integration features, they should definitely use one, and it's a valuable service that this option is available.
    - mei0Iesh 11y ago
      If you can't trust a CA not to prevent their official client from becoming malware, then I don't see how you can trust them to maintain their position as CA. There is no real scenario where the official client is discovered to be backdoored, and people go on using Let's Encrypt certificates.
      - deleted 11y ago
        [deleted]
      - pdkl95 11y ago
        Malware isn't the problem - their automagic client screwing up my webserver is the problem. This is a justified concern given that the official client already demonstrates bad behavior by causing side effects on --help (see my top level post).
        mei0Iesh 11y ago
        It is not a concern at all for me, because I can run that command from a user that does not have privileges to mess anything up. Those options make it not even attempt to read or write any web server configuration. All it does is create the certificate.
        kuschku 11y ago
        Even worse: It already has screwed up my webserver. Script crashed while trying to verify, left the apache config files in the modified state. Trying to get that back to work took another half hour of the server being down. I’m gonna use the simple website someone made to generate certificates from now on.
        baobrien 11y ago
        Take a look at acme-tiny as well. You can run acme-tiny in a cronjob to update your certs, since LE certs expire in 90 days.
  - mootothemax 11y ago
    >If you don't trust the official client, why do you trust them to be your certificate authority? I took the OP to mean e.g. editing configuration files correctly, rather than a question of the code itself being compromised. In other words, a concern about day-to-day coding rather than security.
  - JshWright 11y ago
    I trust them to maintain a secure CA (and I trust that there are adequate checks and audit mechanisms in place). I do not necessarily trust them to not muck up my webserver configs, or to accidentally expose my private key due to some bug. While I have no reason to doubt the code quality of the official client (and I'm certainly not suggesting I suspect any malicious activity), I suspect the checks in place for the client are probably less rigorous than those for the CA itself. acme-tiny is less than 200 lines. Short enough that reviewing the code took a trivial amount of time, and now I'm using a client that I can trust completely. I could certainly do the same thing with the official client, but it would take me several hours (at least) to get to the same level of comfort.
- chinathrow 11y ago
  Good look then auditing Python with it. For some folks, even running Python where you terminate your SSL/TLS is too much of external dependencies.
  - JshWright 11y ago
    That's an argument I can never win. There is always another layer down the stack that I haven't/can't audit. That doesn't mean it's not better to audit what I can.
    - chinathrow 11y ago
      True - Someone implemented it in bash/openssl/curl/sed only. https://github.com/lukas2511/letsencrypt.sh https://github.com/lukas2511/letsencrypt.sh
deleted 11y ago
[deleted]
mootothemax 11y ago
>That looks like a lot more work than the official client. Maybe some people have different experience levels, time constraints, or patience for the non-obvious than yourself? I myself by far found tiny-acme the simpler client to understand; there was absolutely zero worrying about what modifications are being made to configuration files, nor concerns about how best to get everything in a nice cron job. If this is a case of the official client's documentation being too dense for the likes of me, then so be it. Edit: >There are some Python dependencies for the official client, but my package manager installed them for me I just saw the top post regarding this, and then re-read about it in your comment. For me - again, possibly a different use case to your own - this is not cool.

JshWright 11y ago

It's not about ease of use, it's about trust. acme-tiny is short enough that anyone with a cursory knowledge of Python can audit it and know exactly what it's doing.

mei0Iesh 11y ago
If you don't trust the official client, why do you trust them to be your certificate authority? Also, note that I ran this command as a normal user, not root.
- schoen 11y ago
  The purposes for which you trust a CA and the purposes for which you trust a software developer are different, the ways of verifying what they do are different, and the ways their work can go wrong are different. I work on the official Python client for Let's Encrypt, but I support people's decision to use a different client if they prefer. It's frustrating to see the occasional conspiracy theory suggesting that the Let's Encrypt project somehow wants to backdoor the client in order to compromise people's servers (an idea that occasionally gets brought up on our forums!). But it makes sense that some people want a client that doesn't modify their server configurations. The official client tries to modify server configurations because we believe that many people don't have the expertise or inclination to do it on their own. That goal does make the official client more complex, and there are still plenty of integration bugs to find and fix. If people want a simpler and more hands-off client without the integration features, they should definitely use one, and it's a valuable service that this option is available.
  - mei0Iesh 11y ago
    If you can't trust a CA not to prevent their official client from becoming malware, then I don't see how you can trust them to maintain their position as CA. There is no real scenario where the official client is discovered to be backdoored, and people go on using Let's Encrypt certificates.
    - deleted 11y ago
      [deleted]
    - pdkl95 11y ago
      Malware isn't the problem - their automagic client screwing up my webserver is the problem. This is a justified concern given that the official client already demonstrates bad behavior by causing side effects on --help (see my top level post).
      - mei0Iesh 11y ago
        It is not a concern at all for me, because I can run that command from a user that does not have privileges to mess anything up. Those options make it not even attempt to read or write any web server configuration. All it does is create the certificate.
      - kuschku 11y ago
        Even worse: It already has screwed up my webserver. Script crashed while trying to verify, left the apache config files in the modified state. Trying to get that back to work took another half hour of the server being down. I’m gonna use the simple website someone made to generate certificates from now on.
        baobrien 11y ago
        Take a look at acme-tiny as well. You can run acme-tiny in a cronjob to update your certs, since LE certs expire in 90 days.
- mootothemax 11y ago
  >If you don't trust the official client, why do you trust them to be your certificate authority? I took the OP to mean e.g. editing configuration files correctly, rather than a question of the code itself being compromised. In other words, a concern about day-to-day coding rather than security.
- JshWright 11y ago
  I trust them to maintain a secure CA (and I trust that there are adequate checks and audit mechanisms in place). I do not necessarily trust them to not muck up my webserver configs, or to accidentally expose my private key due to some bug. While I have no reason to doubt the code quality of the official client (and I'm certainly not suggesting I suspect any malicious activity), I suspect the checks in place for the client are probably less rigorous than those for the CA itself. acme-tiny is less than 200 lines. Short enough that reviewing the code took a trivial amount of time, and now I'm using a client that I can trust completely. I could certainly do the same thing with the official client, but it would take me several hours (at least) to get to the same level of comfort.
chinathrow 11y ago
Good look then auditing Python with it. For some folks, even running Python where you terminate your SSL/TLS is too much of external dependencies.
- JshWright 11y ago
  That's an argument I can never win. There is always another layer down the stack that I haven't/can't audit. That doesn't mean it's not better to audit what I can.
  - chinathrow 11y ago
    True - Someone implemented it in bash/openssl/curl/sed only. https://github.com/lukas2511/letsencrypt.sh https://github.com/lukas2511/letsencrypt.sh

deleted 11y ago

[deleted]

mootothemax 11y ago

>That looks like a lot more work than the official client. Maybe some people have different experience levels, time constraints, or patience for the non-obvious than yourself? I myself by far found tiny-acme the simpler client to understand; there was absolutely zero worrying about what modifications are being made to configuration files, nor concerns about how best to get everything in a nice cron job. If this is a case of the official client's documentation being too dense for the likes of me, then so be it. Edit: >There are some Python dependencies for the official client, but my package manager installed them for me I just saw the top post regarding this, and then re-read about it in your comment. For me - again, possibly a different use case to your own - this is not cool.