5 ms·

> I agree but I think registration and configuration should be split a little bit more. I personally won't trust it with my config files (and god knows what oth

> I agree but I think registration and configuration should be split a little bit more. I personally won't trust it with my config files (and god knows what other wonderful webserver will emerge next month), but having an automated cert-generation tool is great. The official client can be ran in 'auth' mode, in which it will not write to your server configs. It can still automate the authentication process for you by looking at where the DocumentRoot is, and placing a file there. But this is also optional, since there is a manual authentication mode as well that just gives you a file, and you'll have to make it available under your domain somewhere and tell it when you've done so. > Also, they absolutely must improve OSX support. One of the main objectives is to help people who are in the web field but wouldn't otherwise bother learning the intricacies of SSL configuration; these people by and large use Macs. They also use Mac on their servers?

toyg 11y ago
> The official client can be ran in 'auth' mode I know, I just think "auth mode" could be a separate tool to improve usability. It might just be an alias, I don't care, but it's easier to remember "get-cert" than yet another double-dash parameter IMHO. > They also use Mac on their servers? No, but very often they develop and try new tools on their Macs. By blowing the mac experience you're forcing them/us to spin up a vm (if you can) and repeat the installation. This raises the bar for adoption a little bit. In these fickle times, it can make the difference between "oh wow this is magic" and "can't be arsed, will check it out later/never".
- tokenizerrr 11y ago
  > I know, I just think "auth mode" could be a separate tool to improve usability. It might just be an alias, I don't care, but it's easier to remember "get-cert" than yet another double-dash parameter IMHO. It's a subcommand, not a "double-dash parameter". You have to supply one of the following, for it to do anything: (default) run Obtain & install a cert in your current webserver auth Authenticate & obtain cert, but do not install it install Install a previously obtained cert in a server revoke Revoke a previously obtained certificate rollback Rollback server configuration changes made during install config_changes Show changes made to server config during installation > No, but very often they develop and try new tools on their Macs. By blowing the mac experience you're forcing them/us to spin up a vm (if you can) and repeat the installation. This raises the bar for adoption a little bit. In these fickle times, it can make the difference between "oh wow this is magic" and "can't be arsed, will check it out later/never". It's a tool meant for servers, to configure server software. I'm not sure why anyone would want to run it on their development machine, especially since a domain name needs to be pointed towards a webserver running on that machine that is accessible from the WAN.
  - toyg 11y ago
    >It's a subcommand, not a "double-dash parameter" Huge difference... Not. > I'm not sure why anyone would want to run it on their development machine Do you usually download and run random tools for the first time directly on a server box? > a webserver running on that machine that is accessible from the WAN Ok then you really should specify this somewhere. I've gone through the github readme and the User Guide without this being mentioned anywhere. I'm probably stupid for not running arbitrary beta tools on random wan-facing servers, but I'm certainly not the only stupid person in IT today.
    - tokenizerrr 11y ago
      > Huge difference... Not. It's required to supply a subcommand, or it won't do anything. That is a big difference from a flag which you may forget to use, and then the program runs anyway. > Do you usually download and run random tools for the first time directly on a server box? I usually spin up a virtual machine for testing out server stuff. > Ok then you really should specify this somewhere. I've gone through the github readme and the User Guide without this being mentioned anywhere. I'm probably stupid for not running arbitrary beta tools on random wan-facing servers, but I'm certainly not the only stupid person in IT today. Me? I'm just a happy let's encrypt beta user. https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/ seems like a pretty clear, easy to comprehend, overview to me. I'm not sure how you were planning on validating ownership of a domain to a third party if you don't want that third party to request resources served by that domain.
      - toyg 11y ago
        > a flag which you may forget to use It's not that you forget to use it, it's forgetting what you're supposed to specify. Anyway, it's a UI thing so we'll never agree. Fine. > I usually spin up a virtual machine for testing out server stuff. Yes, we've established that. What I'm saying is, not everyone does. In fact, the people you most want to use this tool (the SSL-illiterate, so to speak) are probably the ones most likely not to do it. > https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/ seems like a pretty clear, easy to comprehend, overview to me Well then, there must have been a miscommunication about the aim of this project. The target user, from what I understood, was supposed to be the SSL-illiterate who doesn't really care too much about the whole tech, he wants things to Just Work. The experts could already self-sign or snag a certificate here or there; the point of this tool was supposed to be helping workaday IT guys get on board the encryption thing with the minimum of effort and cost. None of these people is going to read that page (who reads "about" pages on marketing websites?). They are going to clone the repo, check the readme, maybe check the user guide linked from the readme. If it doesn't work the first time for whatever reason (because the guide is not clear where it can and cannot be run), they're going to drop it and just keep doing what they're already doing (which, after all, Just Works already, it's just not encrypted). If LE developers want to onboard stupid people like me, they have to clarify that: 1) this is supposed to run only on internet-facing servers with a domain already pointed to them, 2) this doesn't work on mac -- no half-hearted "experimental support", if they can't be bothered they should just drop it, 3) all the info required to make it run "without thinking" should be either in readme or user guide.

toyg 11y ago

> The official client can be ran in 'auth' mode I know, I just think "auth mode" could be a separate tool to improve usability. It might just be an alias, I don't care, but it's easier to remember "get-cert" than yet another double-dash parameter IMHO. > They also use Mac on their servers? No, but very often they develop and try new tools on their Macs. By blowing the mac experience you're forcing them/us to spin up a vm (if you can) and repeat the installation. This raises the bar for adoption a little bit. In these fickle times, it can make the difference between "oh wow this is magic" and "can't be arsed, will check it out later/never".

tokenizerrr 11y ago
> I know, I just think "auth mode" could be a separate tool to improve usability. It might just be an alias, I don't care, but it's easier to remember "get-cert" than yet another double-dash parameter IMHO. It's a subcommand, not a "double-dash parameter". You have to supply one of the following, for it to do anything: (default) run Obtain & install a cert in your current webserver auth Authenticate & obtain cert, but do not install it install Install a previously obtained cert in a server revoke Revoke a previously obtained certificate rollback Rollback server configuration changes made during install config_changes Show changes made to server config during installation > No, but very often they develop and try new tools on their Macs. By blowing the mac experience you're forcing them/us to spin up a vm (if you can) and repeat the installation. This raises the bar for adoption a little bit. In these fickle times, it can make the difference between "oh wow this is magic" and "can't be arsed, will check it out later/never". It's a tool meant for servers, to configure server software. I'm not sure why anyone would want to run it on their development machine, especially since a domain name needs to be pointed towards a webserver running on that machine that is accessible from the WAN.
- toyg 11y ago
  >It's a subcommand, not a "double-dash parameter" Huge difference... Not. > I'm not sure why anyone would want to run it on their development machine Do you usually download and run random tools for the first time directly on a server box? > a webserver running on that machine that is accessible from the WAN Ok then you really should specify this somewhere. I've gone through the github readme and the User Guide without this being mentioned anywhere. I'm probably stupid for not running arbitrary beta tools on random wan-facing servers, but I'm certainly not the only stupid person in IT today.
  - tokenizerrr 11y ago
    > Huge difference... Not. It's required to supply a subcommand, or it won't do anything. That is a big difference from a flag which you may forget to use, and then the program runs anyway. > Do you usually download and run random tools for the first time directly on a server box? I usually spin up a virtual machine for testing out server stuff. > Ok then you really should specify this somewhere. I've gone through the github readme and the User Guide without this being mentioned anywhere. I'm probably stupid for not running arbitrary beta tools on random wan-facing servers, but I'm certainly not the only stupid person in IT today. Me? I'm just a happy let's encrypt beta user. https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/ seems like a pretty clear, easy to comprehend, overview to me. I'm not sure how you were planning on validating ownership of a domain to a third party if you don't want that third party to request resources served by that domain.
    - toyg 11y ago
      > a flag which you may forget to use It's not that you forget to use it, it's forgetting what you're supposed to specify. Anyway, it's a UI thing so we'll never agree. Fine. > I usually spin up a virtual machine for testing out server stuff. Yes, we've established that. What I'm saying is, not everyone does. In fact, the people you most want to use this tool (the SSL-illiterate, so to speak) are probably the ones most likely not to do it. > https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/ seems like a pretty clear, easy to comprehend, overview to me Well then, there must have been a miscommunication about the aim of this project. The target user, from what I understood, was supposed to be the SSL-illiterate who doesn't really care too much about the whole tech, he wants things to Just Work. The experts could already self-sign or snag a certificate here or there; the point of this tool was supposed to be helping workaday IT guys get on board the encryption thing with the minimum of effort and cost. None of these people is going to read that page (who reads "about" pages on marketing websites?). They are going to clone the repo, check the readme, maybe check the user guide linked from the readme. If it doesn't work the first time for whatever reason (because the guide is not clear where it can and cannot be run), they're going to drop it and just keep doing what they're already doing (which, after all, Just Works already, it's just not encrypted). If LE developers want to onboard stupid people like me, they have to clarify that: 1) this is supposed to run only on internet-facing servers with a domain already pointed to them, 2) this doesn't work on mac -- no half-hearted "experimental support", if they can't be bothered they should just drop it, 3) all the info required to make it run "without thinking" should be either in readme or user guide.