== We've switched over to using Let's Encrypt as much as possible Over the years, [[we https://support.cs.toronto.edu/]]'ve used a whole collection of different TLS {{AB:CAs:Certificate Authorities}}. We've preferred free ones where we could, [[for good reasons ../tech/UniversitiesFreeAttraction]], which meant that we've used both ipsCA ([[until they exploded ../web/SSLCAFailure]]) and StartSSL ([[aka StartCom ../web/StartComGivesUp]]), 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 http://its.utoronto.ca/]]. However, we've now switched over to using [[Let's Encrypt https://letsencrypt.org/]] 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 ../web/LetsEncryptAutomationGreat]]. 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 LetsEncryptMoreThanHTTPS]]), 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 https://hlandau.github.io/acme/]], which is what [[I settled on myself LetsEncryptMyClients]]. 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 LetsEncryptNoProduction]] due to rate limits. What's changed since then is that [[Let's Encrypt's current rate limits https://letsencrypt.org/docs/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 https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment]]), we'd be happy to do just that. But at least for now, [[Let's Encrypt]] itself and ACME are conjoined together.