7 ms·

I assume "Leaving Beta" means their service as a whole is leaving beta, even though their Github client is still Beta? From https://github.com/letsencrypt/lets

by claar 11y ago

I assume "Leaving Beta" means their service as a whole is leaving beta, even though their Github client is still Beta? From https://github.com/letsencrypt/letsencrypt https://github.com/letsencrypt/letsencrypt: "The Let's Encrypt Client is BETA SOFTWARE. It contains plenty of bugs and rough edges, and should be tested thoroughly in staging environments before use on production systems." And NGINX support is still labeled "highly experimental". Not complaining though; these things take time. Thank you for bringing free encryption to the masses, Let's Encrypt!

ran290 11y ago
The client will be renamed and moved to the EFF soon: https://letsencrypt.org/2016/03/09/le-client-new-home.html https://letsencrypt.org/2016/03/09/le-client-new-home.html
- atonse 11y ago
  Any plans to make the official client based on Go? I wasn't too happy about having to download a bunch of Python stuff on my server just to get an SSL cert. Reminded me of the days of yore when you had to fiddle with Perl modules just to run basic scripts.
  - greggman 11y ago
    I don't know about an "official" client but but caddy has support built in so you could probably extract the portions you need from that? https://caddyserver.com/ https://caddyserver.com/
  - pfg 11y ago
    I'm not sure if, conceptually, the term "official client" is still appropriate after the project is moved to the EFF and the rename is done. It's basically a move to ensure a vibrant client ecosystem which encourages users to pick the client that best fits their needs. If you're looking for a Go client, lego[1] is awesome. [1]: https://github.com/xenolf/lego https://github.com/xenolf/lego
    - notatoad 11y ago
      It seems like it'd be more accurate to call it a "reference implementation" than an official client. at the very least, it'd be nice if people stopped referring to other implementations of the LE spec as "unofficial clients".
  - Titanous 11y ago
    There are a bunch of great unofficial clients, several written in Go (I like acmetool): https://www.metachris.com/2015/12/comparison-of-10-acme-lets-encrypt-clients/ https://www.metachris.com/2015/12/comparison-of-10-acme-lets...
    - tyho 11y ago
      Unfortunately lots of Go code on GitHub has significant oversights, this included. I remember reporting a DoS bug in a different Go acme library identical to this one I found in acmetool in less than 60s: https://github.com/hlandau/acme/blob/master/acmeapi/ocsp.go#L52 https://github.com/hlandau/acme/blob/master/acmeapi/ocsp.go#... In case it is not obvious, anyone in a privileged point on the network can fill resb with enough data that the program panics due to OOM and crashes. ioutil.ReadAll really needs a big warning in the docs because I have seen this pattern far too often.
      - zachlatta 11y ago
        Yeah, serious +1 to this. I'm amazed by the usage of ioutil.ReadAll in popular Go libraries and tools.
  - mintplant 11y ago
    Doesn't have to be written in Go to produce a single statically-linked binary.
  - wyager 11y ago
    Why go? I can't think of any reason to prefer Go over any other language for this project. I'd prefer a security-oriented program to be written in a safer language, actually.
    - nindalf 11y ago
      Could you explain what you mean by "safer"? If you mean memory safe or free from undefined behavior, Go is exactly that. If you mean a language that has excellent native crypto libraries rather than wrappers over openSSL, Go provides that too. To answer your specific query, Go makes more sense for a LE client compared to Python because you'd simply need to run a binary instead of fiddling around with the source on your server.
      - minitech 11y ago
        “simply running a binary”: - download letsencrypt-auto - ./letsencrypt-auto ”fiddling around with the source”: - download letsencrypt.tar.gz - extract letsencrypt.tar.gz - ./letsencrypt-auto (and there might even be a package available!)
        nindalf 10y ago
        This is assuming you have the correct version of python installed, right? What if you were on CentOS and the python version is 2.6? Or on Alpine and you simply didn't have python at all?
        minitech 10y ago
        What if you download a binary and a dynamic library is missing? (This is what happens with GHC on Alpine. Binaries will expect glibc. Packages fix this problem, but they also fix the Python problems.) Another example: I recently wanted to run IDA on Arch Linux, but there are no 32-bit Qt5 packages. Compiling Qt5 is more painful than installing Python.
      - wyager 10y ago
  - creshal 11y ago
    The inofficial clients work well enough nowadays.
erik14th 11y ago
I've been using it on nginx for about two months. Was pretty easy to setup and works on most browsers. Browsers that don't work are chrome and ie on windows XP and android 2.3.7 or older I guess.

by claar 11y ago

ran290 11y ago

The client will be renamed and moved to the EFF soon: https://letsencrypt.org/2016/03/09/le-client-new-home.html https://letsencrypt.org/2016/03/09/le-client-new-home.html

atonse 11y ago
Any plans to make the official client based on Go? I wasn't too happy about having to download a bunch of Python stuff on my server just to get an SSL cert. Reminded me of the days of yore when you had to fiddle with Perl modules just to run basic scripts.
- greggman 11y ago
  I don't know about an "official" client but but caddy has support built in so you could probably extract the portions you need from that? https://caddyserver.com/ https://caddyserver.com/
- pfg 11y ago
  I'm not sure if, conceptually, the term "official client" is still appropriate after the project is moved to the EFF and the rename is done. It's basically a move to ensure a vibrant client ecosystem which encourages users to pick the client that best fits their needs. If you're looking for a Go client, lego[1] is awesome. [1]: https://github.com/xenolf/lego https://github.com/xenolf/lego
  - notatoad 11y ago
    It seems like it'd be more accurate to call it a "reference implementation" than an official client. at the very least, it'd be nice if people stopped referring to other implementations of the LE spec as "unofficial clients".
- Titanous 11y ago
  There are a bunch of great unofficial clients, several written in Go (I like acmetool): https://www.metachris.com/2015/12/comparison-of-10-acme-lets-encrypt-clients/ https://www.metachris.com/2015/12/comparison-of-10-acme-lets...
  - tyho 11y ago
    Unfortunately lots of Go code on GitHub has significant oversights, this included. I remember reporting a DoS bug in a different Go acme library identical to this one I found in acmetool in less than 60s: https://github.com/hlandau/acme/blob/master/acmeapi/ocsp.go#L52 https://github.com/hlandau/acme/blob/master/acmeapi/ocsp.go#... In case it is not obvious, anyone in a privileged point on the network can fill resb with enough data that the program panics due to OOM and crashes. ioutil.ReadAll really needs a big warning in the docs because I have seen this pattern far too often.
    - zachlatta 11y ago
      Yeah, serious +1 to this. I'm amazed by the usage of ioutil.ReadAll in popular Go libraries and tools.
- mintplant 11y ago
  Doesn't have to be written in Go to produce a single statically-linked binary.
- wyager 11y ago
  Why go? I can't think of any reason to prefer Go over any other language for this project. I'd prefer a security-oriented program to be written in a safer language, actually.
  - nindalf 11y ago
    Could you explain what you mean by "safer"? If you mean memory safe or free from undefined behavior, Go is exactly that. If you mean a language that has excellent native crypto libraries rather than wrappers over openSSL, Go provides that too. To answer your specific query, Go makes more sense for a LE client compared to Python because you'd simply need to run a binary instead of fiddling around with the source on your server.
    - minitech 11y ago
      “simply running a binary”: - download letsencrypt-auto - ./letsencrypt-auto ”fiddling around with the source”: - download letsencrypt.tar.gz - extract letsencrypt.tar.gz - ./letsencrypt-auto (and there might even be a package available!)
      - nindalf 10y ago
        This is assuming you have the correct version of python installed, right? What if you were on CentOS and the python version is 2.6? Or on Alpine and you simply didn't have python at all?
        minitech 10y ago
        What if you download a binary and a dynamic library is missing? (This is what happens with GHC on Alpine. Binaries will expect glibc. Packages fix this problem, but they also fix the Python problems.) Another example: I recently wanted to run IDA on Arch Linux, but there are no 32-bit Qt5 packages. Compiling Qt5 is more painful than installing Python.
    - wyager 10y ago
- creshal 11y ago
  The inofficial clients work well enough nowadays.

erik14th 11y ago

I've been using it on nginx for about two months. Was pretty easy to setup and works on most browsers. Browsers that don't work are chrome and ie on windows XP and android 2.3.7 or older I guess.