5 ms·

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.
        kuschku 11y ago
        Doing it manually every 90 days isn’t that hard. I’d prefer if the default client would properly separate the parts it does, though.
- mootothemax 11y ago
  Wow, awesome to hear you chime in, and thanks for your great work on getting Let's Encrypt up and running! Please don't take my post as a direct criticism of the official client; I think it's just a question of use cases, and my case doesn't have much overlap with the "I want a client that takes care of everything" use case.
- dingaling 11y ago
  > because we believe that many people don't have the expertise or inclination to do it on their own. So they've set-up a server or VPS, installed a web server and possibly a CMS, configured virtual hosts and appropriate users, hooked-up an RDBMS but... SSL is too hard? Don't kid yourself, most hobbyists are keen on Let's Encrypt because it's free. People who really don't have knowledge or inclination for SSL configuration will be waiting for an option on their hosting provider's control panel. They don't have root shell access.
- lisper 11y ago
  > 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 That's not the only reason someone might not want to use the LE client. Here are a few others: 1. The LE client might have a bug that causes problems on my server. 2. I may have done something non-standard to my config files that the LE client undoes. 3. Someone may have compromised the LE client or one of its dependencies without your knowledge.
  - schoen 11y ago
    I agree with those concerns, and I definitely don't mean to suggest that people who chose not to use the client all believe in conspiracy theories about the developers' intentions.
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.

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.
      - kuschku 11y ago
        Doing it manually every 90 days isn’t that hard. I’d prefer if the default client would properly separate the parts it does, though.
mootothemax 11y ago
Wow, awesome to hear you chime in, and thanks for your great work on getting Let's Encrypt up and running! Please don't take my post as a direct criticism of the official client; I think it's just a question of use cases, and my case doesn't have much overlap with the "I want a client that takes care of everything" use case.
dingaling 11y ago
> because we believe that many people don't have the expertise or inclination to do it on their own. So they've set-up a server or VPS, installed a web server and possibly a CMS, configured virtual hosts and appropriate users, hooked-up an RDBMS but... SSL is too hard? Don't kid yourself, most hobbyists are keen on Let's Encrypt because it's free. People who really don't have knowledge or inclination for SSL configuration will be waiting for an option on their hosting provider's control panel. They don't have root shell access.
lisper 11y ago
> 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 That's not the only reason someone might not want to use the LE client. Here are a few others: 1. The LE client might have a bug that causes problems on my server. 2. I may have done something non-standard to my config files that the LE client undoes. 3. Someone may have compromised the LE client or one of its dependencies without your knowledge.
- schoen 11y ago
  I agree with those concerns, and I definitely don't mean to suggest that people who chose not to use the client all believe in conspiracy theories about the developers' intentions.

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.