Comment by kubaw | Hacker News Reader

Comment by kubaw | Hacker News Reader

Parent Full thread

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 [1] https://github.com/kuba/simp_le/tree/master/pyi

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! :)

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.)

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.

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.

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.

>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.

You'd be surprised I think.

>They would probably like to learn how to configure something like SSL.

I think you'd be surprised again. It's not even always about aptitude–quite often it's just laziness. The reason that many of these people aren't encrypting today is because they don't want to invest the time and effort. "My copy-pasted openssl commands didn't work? Eff this."

Operations is as much a mindset as it is a skill. Some developers have it, some don't.

Webserver config modification has indeed taken an immense amount of programmer effort. It's actually pretty magical when it works well, and it's suprisingly robust, but it's still filled with horrible edge cases everywhere.

I don't understand the point of "not specifying output files". First: I just used your client and it worked, it is great work, thanks for that! But the one thing I did not understand was the -f options. Why don't you implement an (in my eyes much easier and common) interface of --output-key path and --output-cert path?

Having to script that with symlinks is nothing I can't do, but something that sucks a bit. Otherwise the crontab would not even need to call a bash-skript wrapping that stuff, it would be just your client with proper parameters. I'd much prefer that.

Reply on news.ycombinator.com