We've switched over to using Let's Encrypt as much as possible

December 9, 2017

Over the years, we've used a whole collection of different TLS CAs. We've preferred free ones where we could, for good reasons, which meant that we've used both ipsCA (until they exploded) and StartSSL (aka StartCom), but we've also paid for TLS certificates when we had to; modern TLS certificates are pretty affordable even for us if we don't go crazy. And these days we even have access to free TLS certificates through the university's central IT. However, we've now switched over to using Let's Encrypt as much as possible; basically it's the first CA we attempt to use, and if it doesn't work for some reason we'd probably turn to the free TLS certificates from central IT (both because they're free and because the process of getting one isn't too painful).

Our main reason for switching to Let's Encrypt isn't that it's free (it's not our only current source of free certificates); instead, as with my personal use, it's become all about the great automation. With Let's Encrypt, getting an initial certificate just requires running a command line program, and once we've worked out how to handle any particular program (since LE's good for more than web servers), we can completely stop worrying about certificate renewals. It just quietly happens and everything works and we don't notice a thing. The LE client that we've wound up using all of the time is Hugo Landau's acmetool, which is what I settled on myself. Acmetool has proven to be reliable and easy to tweak so it supports various programs like Dovecot and Exim.

(Our current approach to satisfying Let's Encrypt challenges is to let HTTP from the Internet through to any machine that needs a TLS certificate, whether or not it normally runs a web server. Acmetool will automatically run its own web server while a challenge is active, if necessary.)

Using acmetool or any other suitable Let's Encrypt client is not the only way of automating TLS certificate updates, but it has the great advantage for us that it comes basically ready to go. In our environment there's almost nothing to build to support new TLS-using programs and almost nothing special to do to set acmetool up on any particular machine (and we have canned directions for the few steps required). People with existing modern automation infrastructure may already have this solved, and so may find Let's Encrypt less compelling than we do.

Almost two years ago I wrote about how we couldn't use Let's Encrypt for production due to rate limits. What's changed since then is that Let's Encrypt's current rate limits specifically exempt certificate renewals from their 'certificates per registered domain' limit. This means that if we can get an initial certificate for a host, we're basically sure to be able to renew it, which is the important thing for us. If the initial issuance fails, that's when we can turn to alternate CAs (but for the names we want it almost never does).

PS: Since automation is such a big motivation for us, what sold us is not Let's Encrypt by itself but acmetool. In a real sense, we're indifferent to what TLS certificate provider is behind acmetool, and if we could get free certificates from central IT just as easily (perhaps literally using LE's ACME protocol), we'd be happy to do just that. But at least for now, Let's Encrypt itself and ACME are conjoined together.


Comments on this page:

From 108.175.232.181 at 2017-12-09 09:45:53:

If one is using Debian or Ubuntu, acmetool is probably the first LE client one should look at, especially the distribution packages. They integrate quite nicely into the system, and getting Apache (and nginx) to work is pre-canned and doesn't require downtime on renewal if you use the webfoot configuration.

The only thing that would be nice would be if it supported the dns-01 verification mechanism. Currently a system needs to be accessible to the LE servers on the public Internet, so internal-only hosts are not useable.

It'd be nice if could:

  • tell you the TXT to enter into DNS, then pause
  • you put it into your zone file
  • acmetool then proceeds with the renewal (optionally checking the records are live)
  • installs the new cert

Obviously it can't be done automatically, but sending out an e-mail at renewal time (to, say, one's ticketing system) allows for a reasonable workflow (if there aren't too many hosts to do this for).

This is one feature that the official LE client (certbot) does pretty well AFAICT.

By cks at 2017-12-09 17:41:41:

According to its documentation, acmetool supports challenge hooks and there are example and third-party hooks for DNS verification. The existing examples assume that they can automate DNS changes, which is reasonable given that acmetool is mostly designed for automated use, but you could presumably write a hook script that just tells you what to do and then waits for you to tell it that you've done the DNS change.

(You'd pretty much have to always run acmetool by hand, with no hands-off automatic certificate renewals.)

From 193.219.181.219 at 2017-12-15 00:56:57:

Recently Let's Encrypt switched over to a new version of their user agreement (v1.2). As a result, all certificate renewals for old accounts started failing (because they had only agreed to v1.1), and I had to ssh to all our servers, interactively run acmetool, and re-confirm the signup process (agreement & email) myself.

That's a bit of unexpected pain. And a blog topic for you, I guess.

Written on 09 December 2017.
« Some thoughts on what StartCom's shutdown means in general
You don't have to authorize a machine for Let's Encrypt from the machine »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sat Dec 9 00:27:29 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.