What are the constraints on the official client that motivated you to author simp_le?
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
Anyway, you have a new user! :)
(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.)
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.
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.
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.
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.