17 ms·

You may also want to try alternative client from https://github.com/kuba/simp_le https://github.com/kuba/simp_le. It can be easily dropped into crontab and rene

by kubaw 11y ago

You may also want to try alternative client from https://github.com/kuba/simp_le https://github.com/kuba/simp_le. It can be easily dropped into crontab and renew certificates when necessary. Disclaimer: I'm the author of simp_le and developer of the official client :)

biomcgary 11y ago
What are the constraints on the official client that motivated you to author simp_le?
- kubaw 11y ago
  The primary difference is in the underlying philosophy. I encourage everyone to read the manifest from the main project site [0]. Most of the points are counteracting bad design decisions (IMO) made in the official client. In general, official client tries to do too many things at once. In the result, the code base is huge -- too big to be easily audited; it's also proven that it's likely to have a lot more bugs. On a similar note, letsencrypt-auto, the default installation method, pulls in Apache plugin with all of its dependencies. And so on, and so forth... At the same time standard modes of operation are well hidden and/or difficult to configure. For instance, running the official client without root is technically possible, but let me know how much time it took you to figure this out ;). Likewise, scripting is pretty much impossible, because the CLI tends to ask interactive questions... "webroot" plugin is probably the only plugin that could be made into non-interactive mode, and again you have to be knowledgeable enough to figure out all necessary flags. simp_le tries to takes the best from the official client ("webroot" plugin -- not stealing, I authored that plugin myself) and adds some missing features that IMO should be the standard. E.g. you can just just put `simp_le --some --flags && this_command_will_be_run_only_if_cert_was_renewed_eg_restart_nginx` into your crontab -- this mode of operation is simply not possible with the official client. NB You can also turn simp_le into a standalone binary (~8MB) using built-in PyInstaller setup [1] and distribute to your machines without having to install any dependencies (even Python) :) I hope that answers your question. You can also catch me on #letsencrypt, or better yet #simp_le (both at Freenode). [0] https://github.com/kuba/simp_le#manifest https://github.com/kuba/simp_le#manifest [1] https://github.com/kuba/simp_le/tree/master/pyi https://github.com/kuba/simp_le/tree/master/pyi
  - niij 11y ago
    Thank you for your work on this project. It is exactly what I need. I don't want the main LE package, which is bloated and annoying to use. I love LetsEncrypt for what they're providing as a free service, but I think they're a little too ambitious from the start for their client. Start small. Anyway, you have a new user! :)
  - bronson 11y ago
    Nice job! I found LE's client irritating to use as well. Yours sounds clean and correct. (I'm just amazed that LE decided to try modifying webserver config files automatically. There are soooo many ways for that to fail. It's going to take an immense amount of programmer effort for very little gain.)
    - brazzledazzle 11y ago
      It's probably motivated in no small part by helping the type of person that's currently not encrypting their application/server and should be. TLS, certificates and PKI's are something a lot of people have a hard time with. We're at a stage where people are capable of developing a web application but creating a (suitable) private key, generating a CRL and then using the resulting certificate in Apache is currently beyond their capabilities. Which is kind of cool in one sense but kind of scary in another.
      - archimedespi 11y ago
        That's exactly why we designed the client that way - we wanted to make it easier for people who have no idea how to add certs to encrypt their server.
        zaidf 11y ago
        People who have no idea how to add certs are also unlikely to know how to login to their web server using SSH or how to install a package. For people who can SSH and install packages, I think they are better served being shown how to add couple lines to make SSL work than some magic that could screw up their web server config. After all, these people chose to learn how to login to the web server instead of just managing their site from a CMS. They would probably like to learn how to configure something like SSL.
- technion 11y ago
  Similar to the dependency issues raised elsewhere, I wrote this script largely because none of my servers run python: https://lolware.net/2015/10/27/letsencrypt_go_live.html https://lolware.net/2015/10/27/letsencrypt_go_live.html
r1ch 11y ago
Got an example of how to drop it into crontab? I'm not really a Python guy and it seems to only run under the venv which I'm not sure how to setup from a cron job. EDIT: Never mind, figured it out, I can just run the simp_le script directly from the venv directory.
- binwiederhier 11y ago
  Thanks for this. I had the same problem!
iheartmemcache 11y ago
Ehhhh, so I get why you made this, but at the same time, LetsEncrypt intentionally chose 90 days for the duration of the certs. Presumably because renewing a cert is a positive confirmation that you still retain ownership. You actively performed an action that declared: hey I still retain control of this and it hasn't been compromised. (as opposed to other states your cert could be in -- abandoned, compromised, password forgotten and you were too lazy to get the cert revoked-- trust me, engineers made cron because we were lazy especially when it comes to mundane things). This is around-about way of saying that 90 days was a well-thought out duration to issue a cert and the process of renewing it manually is there as a positive (rather than passive) confirmation you retain control. These guys are doing a public service, on par with archive.org and the EFF. I'm not sure, but even though I've been using cron since before I was a teenager, I'm not throwing that entry in. Edit: Whoops, so I was half-wrong, mea culpa. https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html Part 1 addresses the security issue I brought up, and part 2 endorses automation. My mistake.
- geekamongus 11y ago
  I get your point, but what sysadmin doesn't want to script everything?
  - toomuchtodo 11y ago
    You can't script everything. Otherwise, we'd all be at the beach drinking mojitos checking Slack to see how the bots are doing. I mean, that's the goal. But we're a ways off.
    - dorfsmay 11y ago
      We are all at the beach and were just wondering where you were!
      - toomuchtodo 11y ago
        https://xkcd.com/705/ https://xkcd.com/705/
lighttower 11y ago
The biggest usability challenge for me is that each crypto tool uses its own key store. kgpg, ssh, yubikey, openvpn, etc. Do you foresee allowing your client to pick up the private key from a smartcard like a yubikey? My goal is to centralize all the certs in a place that I will always have access to - and not have a different passphrase for each cert (which I will forget) or 1 passphrase for all certs (even worse). 1 passphrase for my cert-store (the yubikey) but which contains all my certs.
- brazzledazzle 11y ago
  I could be wrong but isn't Let's Encrypt more oriented towards securing servers?
  - andrewchambers 11y ago
    Lets encrypt is for helping servers offer ssl encryption to people for free.
    - niutech 11y ago
      There are also StartSSL and WoSign, which provide the A+ certificates for free (see example WoSign domain audit: https://www.ssllabs.com/ssltest/analyze.html?d=checkmyping.com https://www.ssllabs.com/ssltest/analyze.html?d=checkmyping.c...)
    - brazzledazzle 11y ago
      Right, I get that. I've been looking through their code and the draft RFC here and there over the last few days (I'm considering using it for internal applications). He mentioned yubikey, pgp, and openvpn and it started to sound more like he was talking about a supporting client use cases. I can see the convenience in using a common client key but it seems more secure to keep things compartmentalized, particularly when it comes to mixing client and server stuff.
      - subway 11y ago

by kubaw 11y ago

biomcgary 11y ago

What are the constraints on the official client that motivated you to author simp_le?

kubaw 11y ago
The primary difference is in the underlying philosophy. I encourage everyone to read the manifest from the main project site [0]. Most of the points are counteracting bad design decisions (IMO) made in the official client. In general, official client tries to do too many things at once. In the result, the code base is huge -- too big to be easily audited; it's also proven that it's likely to have a lot more bugs. On a similar note, letsencrypt-auto, the default installation method, pulls in Apache plugin with all of its dependencies. And so on, and so forth... At the same time standard modes of operation are well hidden and/or difficult to configure. For instance, running the official client without root is technically possible, but let me know how much time it took you to figure this out ;). Likewise, scripting is pretty much impossible, because the CLI tends to ask interactive questions... "webroot" plugin is probably the only plugin that could be made into non-interactive mode, and again you have to be knowledgeable enough to figure out all necessary flags. simp_le tries to takes the best from the official client ("webroot" plugin -- not stealing, I authored that plugin myself) and adds some missing features that IMO should be the standard. E.g. you can just just put `simp_le --some --flags && this_command_will_be_run_only_if_cert_was_renewed_eg_restart_nginx` into your crontab -- this mode of operation is simply not possible with the official client. NB You can also turn simp_le into a standalone binary (~8MB) using built-in PyInstaller setup [1] and distribute to your machines without having to install any dependencies (even Python) :) I hope that answers your question. You can also catch me on #letsencrypt, or better yet #simp_le (both at Freenode). [0] https://github.com/kuba/simp_le#manifest https://github.com/kuba/simp_le#manifest [1] https://github.com/kuba/simp_le/tree/master/pyi https://github.com/kuba/simp_le/tree/master/pyi
- niij 11y ago
  Thank you for your work on this project. It is exactly what I need. I don't want the main LE package, which is bloated and annoying to use. I love LetsEncrypt for what they're providing as a free service, but I think they're a little too ambitious from the start for their client. Start small. Anyway, you have a new user! :)
- bronson 11y ago
  Nice job! I found LE's client irritating to use as well. Yours sounds clean and correct. (I'm just amazed that LE decided to try modifying webserver config files automatically. There are soooo many ways for that to fail. It's going to take an immense amount of programmer effort for very little gain.)
  - brazzledazzle 11y ago
    It's probably motivated in no small part by helping the type of person that's currently not encrypting their application/server and should be. TLS, certificates and PKI's are something a lot of people have a hard time with. We're at a stage where people are capable of developing a web application but creating a (suitable) private key, generating a CRL and then using the resulting certificate in Apache is currently beyond their capabilities. Which is kind of cool in one sense but kind of scary in another.
    - archimedespi 11y ago
      That's exactly why we designed the client that way - we wanted to make it easier for people who have no idea how to add certs to encrypt their server.
      - zaidf 11y ago
        People who have no idea how to add certs are also unlikely to know how to login to their web server using SSH or how to install a package. For people who can SSH and install packages, I think they are better served being shown how to add couple lines to make SSL work than some magic that could screw up their web server config. After all, these people chose to learn how to login to the web server instead of just managing their site from a CMS. They would probably like to learn how to configure something like SSL.
technion 11y ago
Similar to the dependency issues raised elsewhere, I wrote this script largely because none of my servers run python: https://lolware.net/2015/10/27/letsencrypt_go_live.html https://lolware.net/2015/10/27/letsencrypt_go_live.html

r1ch 11y ago

Got an example of how to drop it into crontab? I'm not really a Python guy and it seems to only run under the venv which I'm not sure how to setup from a cron job. EDIT: Never mind, figured it out, I can just run the simp_le script directly from the venv directory.

binwiederhier 11y ago
Thanks for this. I had the same problem!

iheartmemcache 11y ago

Ehhhh, so I get why you made this, but at the same time, LetsEncrypt intentionally chose 90 days for the duration of the certs. Presumably because renewing a cert is a positive confirmation that you still retain ownership. You actively performed an action that declared: hey I still retain control of this and it hasn't been compromised. (as opposed to other states your cert could be in -- abandoned, compromised, password forgotten and you were too lazy to get the cert revoked-- trust me, engineers made cron because we were lazy especially when it comes to mundane things). This is around-about way of saying that 90 days was a well-thought out duration to issue a cert and the process of renewing it manually is there as a positive (rather than passive) confirmation you retain control. These guys are doing a public service, on par with archive.org and the EFF. I'm not sure, but even though I've been using cron since before I was a teenager, I'm not throwing that entry in. Edit: Whoops, so I was half-wrong, mea culpa. https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html Part 1 addresses the security issue I brought up, and part 2 endorses automation. My mistake.

geekamongus 11y ago
I get your point, but what sysadmin doesn't want to script everything?
- toomuchtodo 11y ago
  You can't script everything. Otherwise, we'd all be at the beach drinking mojitos checking Slack to see how the bots are doing. I mean, that's the goal. But we're a ways off.
  - dorfsmay 11y ago
    We are all at the beach and were just wondering where you were!
    - toomuchtodo 11y ago
      https://xkcd.com/705/ https://xkcd.com/705/

lighttower 11y ago

The biggest usability challenge for me is that each crypto tool uses its own key store. kgpg, ssh, yubikey, openvpn, etc. Do you foresee allowing your client to pick up the private key from a smartcard like a yubikey? My goal is to centralize all the certs in a place that I will always have access to - and not have a different passphrase for each cert (which I will forget) or 1 passphrase for all certs (even worse). 1 passphrase for my cert-store (the yubikey) but which contains all my certs.

brazzledazzle 11y ago
I could be wrong but isn't Let's Encrypt more oriented towards securing servers?
- andrewchambers 11y ago
  Lets encrypt is for helping servers offer ssl encryption to people for free.
  - niutech 11y ago
    There are also StartSSL and WoSign, which provide the A+ certificates for free (see example WoSign domain audit: https://www.ssllabs.com/ssltest/analyze.html?d=checkmyping.com https://www.ssllabs.com/ssltest/analyze.html?d=checkmyping.c...)
  - brazzledazzle 11y ago
    Right, I get that. I've been looking through their code and the draft RFC here and there over the last few days (I'm considering using it for internal applications). He mentioned yubikey, pgp, and openvpn and it started to sound more like he was talking about a supporting client use cases. I can see the convenience in using a common client key but it seems more secure to keep things compartmentalized, particularly when it comes to mixing client and server stuff.
    - subway 11y ago