Let’s Encrypt thoughts

I just set up Let’s Encrypt to enable SSL on my weblog server. I did this in the dumbest way possible, just running ./letsencrypt-auto --apache without understanding what it was doing. It went very smoothly and I really admire the turnkey installation that the project has come up with. Here’s a report on the result, and how it looks in Chrome:

Screen Shot 2016-01-06 at 10.46.37 AM

But of course I have some complaints valuable observations.

There’s one usability problem; the certificates expire every three months and they don’t have an automated renewal process yet. They promise one soon.

Also I lied a bit, it didn’t go smoothly, in fact it choked processing my Apache config file. I filed a bug, it’s related to a rewrite rule that is idiosyncratic to me, no big deal. But the bug reports are full of “it failed to parse my Apache file!” with the developers diligently fixing every parse problem. It feels like they’d benefit from a more sloppy parser, something that just extracts the part of the config file they really need and doesn’t try to validate / parse the whole thing. This config management stuff always sucks in software though.

As convenient as the turnkey magic is, it also made me nervous. I wish it printed a little summary of what it did to console. It seems to have installed some Ubuntu packages, munged some config files, generated a key, and reloaded Apache to enable SSL. I’m protective of my server; maybe I should have done a manual install or read the docs first.

Fortunately there are good docs, a little thin, but the basics. They store all the certs in /etc/letsencrypt/. Diffing against a backup I see they add SSL solely by creating new files in /etc/apache2; enable a couple of SSL mods, then create a somebits-le-ssl.conf for the SSL site. Unfortunately that file is a complete copy of the original somebits.conf file only on port 443 with SSL stuff added. I hate to see that duplication of configuration! I wonder if it’s partly my fault for having sloppy config files. Some ideas for doing it right: macros or include files. Of course Let’s Encrypt shouldn’t be doing that for me, but it may be best-practice to do it for myself.

Their logging config in /etc/letsencrypt/options-ssl-apache.conf was not a good match for my carefully managed logs. Their config seems to automatically write any SSL site logs to /var/log/apache2/access.log with a vhost attached. That seems like a reasonable default, but in my case I already have custom logs enabled in each site.conf file that go to different directories. Just a case of Let’s Encrypt’s defaults not being right for me.