I’ve started using the new CA named let’s encryptduring their closed beta back in november.

At that time, I’ve been using their own (python-based) client to generate test certificates on my laptop (I’ve never planned to run the client on my servers as I don’t really like having such processes with the ability to fiddle with the system’s configurations on their own).

I ran the client in manual mode, prooving manually possession of the domain

letsencrypt-auto certonly -a manual -d joel-hatsch.net --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview --verbose

Out of the multiple negative issues I’ve seen :

• client starts by issuing a “sudo” command - runs as root from beginning
• generated keys and certificates are stored in /etc
• Newlines not allowed in challenge response and also [here](https://community.letsencrypt.org/t/manual-line-break-at-end-of-http-response-causing-mis-match/3794/3] - fixed in the meantime
• very sparse error reporting (should I say “none” ?) when challenge verification fails
• everything runs automatically (that’s intended…) but one can’t really follow whats going on, what commands are being issued, what services are started and listen to which port etc… in post-Snowden times not really what I’d like to have

So I started looking for an alternative client. Funny thing seems to be that most of them use the web challenge challenge method to provide proof of ownership.

First one was the javascript implementation, which really impressed me. Unfortunately this needs user interaction (4 openssl commands to run and stdout to paste back into the browser. Actuallly I didn’t get past this step and didn’t finish the generation.

Then I had a look at the PHP client but had issues with the required PHP libraries (can’t remember)

Next trial was with the perl client. This client uses perl (sub)classes to allow implementation of various challenge provision methods (currently available : ssh, file copy, manual) and sounds pretty modular. However, it has lots of dependencies on perl modules, which I was not really wanting to install.

So finally I gave the bash client a try…

First good thing : it takes only 667 lines of code to implement the client, thus one can investigate the content of the code and verify what’s going on inside.

Second good thing : tool can be called mutliple times and will only re-run the certification in case new (sub)domains are to be added - or if the certification expires in less than 14 days (configurable).

Third thing : the provision of the challenge on the remote webserver is delegated to an optional hook script. This allows for any method to be implemented. I’ve choosen to use a one-liner rsync call as this method is already available and configured on my server.

While I’m still not really ready for running this certification script within a cronjob, the bash client seems to be the best candidate for the job. Code is small enough to be auditable, has low number of dependencies (actually onle awk and openssl), and can be run interactively as well as in batch mode.