Why Let's Encrypt's short certificate lifetimes are a great thing

March 14, 2018

I recently had a conversation on Twitter about what we care about in TLS certificate sources, and it got me to realize something. I've written before about how our attraction to Let's Encrypt has become all about the great automation, but what I hadn't really thought about back then was how important the short certificate lifetimes are. What got me to really thinking about it was a hypothetical; suppose we could get completely automatically issued and renewed free certificates but they had the typical one or more year lifetime of most TLS certificates to date. Would we be interested? I realized that we would not be, and that we would probably consider the long certificate lifetime to be a drawback, not a feature.

There is a general saying in modern programming to the effect that if you haven't tested it, it doesn't work. In system administration, we tend towards a modified version of that saying; if you haven't tested it recently, it doesn't work. Given our generally changing system environments, the recently is an important qualification; it's too easy for things to get broken by changes around them, so the longer it's been since you tried something, the less confidence you can have in it. The corollary for infrequent certificate renewal is obvious, because even in automated systems things can happen.

With Let's Encrypt, we don't just have automation; the short certificate lifetime insures that we exercise it frequently. Our client of choice (acmetool) renews certificates when they're 30 days from expiring, so although the official Let's Encrypt lifetime is 90 days, we roll over certificates every sixty days. Having a rollover happen once every two months is great for building and maintaining our confidence in the automation, in a way that wouldn't happen if it was once every six months, once a year, or even less often. If it was that infrequent, we'd probably end up paying attention during certificate rollovers even if we let automation do all of the actual work. With the frequent rollover due to Let's Encrypt's short certificate lifetimes, they've become things we trust enough to ignore.

(Automatic certificate renewal for long duration certificates is not completely impossible here, because the university central IT has already arranged for free certificates for the university. Right now they're managed through a website and our university-wide authentication system, but in theory there could be automation for at least renewals. Our one remaining non Let's Encrypt certificate was issued through this service as a two year certificate.)


Comments on this page:

From 193.219.181.219 at 2018-03-14 03:02:12:

Right now they're managed through a website and our university-wide authentication system

Is it perhaps the DigiCert service? We've been using that for our university (especially for the free EV). They do have a "CertCentral API" which could be used for automation just as ACME is, although I still haven't gotten around to finishing writing the client tools cough

By cks at 2018-03-14 08:28:28:

The university's current version is provided through Comodo. I haven't dug into the details of what would be possible, because by the time it became readily available to us we'd already started shifting towards Let's Encrypt.

(We've gone through a number of CAs over the years, partly because stuff has happened to some of them.)

By Twirrim at 2018-03-16 11:42:36:

Along similar lines, one thing I've been arguing for for a while at various places I've worked has been to make infrastructure patching for teams a weekly requirement, instead of monthly. It's not that I'm particularly interested in a weekly cadence, it's just that that passes an inflection point with management and ops staff. It goes from an inconvenient, maybe partially automated monthly chore to "We must fully automate it!".

That then gets teams to a position where patching should be able to happen at the drop of a hat, should, say, another Heartbleed or Shellshock happen.

side note: One place I worked, I carefully wrote notes about every place I had to replace the wildcard SSL certificate, and how to do it. I missed some and updated the docs when they were discovered. Two years later, new renewal happened and half my instructions no longer applied, some of what I had was now incorrect due to upgrades, and I had a half dozen other places I now needed to update the certificate.

Written on 14 March 2018.
« A spammer misses a glorious opportunity
What I think I want out of a hypothetical nfsiotop for Linux »

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

Last modified: Wed Mar 14 01:24:45 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.