Pros and cons of 90-day certificate lifetimes


On the old thread there were some software stated (just take OpenVPN here). But I think this is useless, as then the next argument is on of the following:

  • this software is only rarely used or in special environments
  • it’s just a few seconds of downtime six to nine times a year
  • this is old software, the new version can be reloaded w/o restarting
  • right now it cannot reload w/o breaking connection, but a new version will be developed which can do it

But these are spurious arguments and don’t help. Just take (certified) appliances where you cannot easily deploy new software or the vendor won’t implement LE. Automation is very error prone there. A perfect solution could be use 90 days or below (on user request) for places where automation is possible, but also allow to request longer valid certificates where automation isn’t easily possible or even impossible. - But that’s also stated in this thread several times…

If the decision is 90 days and that’s it, period, ok, then LE isn’t the CA of choice for you. That’s sad, as this contradicts the LE goal of “let’s encrypt everything”, but it’s their decision, if we like it or not.

I think by stating that goal LE sparked hopes that this is the one CA which will solve all our problems (also see the discussions on certificates for IPs and wildcard certificates)…


[quote=“joepie91, post:262, topic:4621”]
Not everything can reload certificates with breaking connections, and this is unlikely to change any time soon.[/quote]
And those systems can’t tolerate the few seconds’ interruption while they restart? The renewal can’t be scheduled for a time when it will have minimal-to-no impact? This (apparently very critical, if a few seconds’ downtime is a problem) service doesn’t have regular scheduled maintenance windows?

[quote=“joepie91, post:262, topic:4621”]
Not to mention isolated systems where automated renewal isn’t acceptable.[/quote]
If automated renewal isn’t acceptable on a system, then it appears to me that LE is not designed or intended to help out that system.


^<- THIS.

well their stated main goal is to be easy, as stated in the latest blog post:

The goal of Let’s Encrypt is to make turning on HTTPS as easy as possible.
and in my opinion automation isnt always easy that’s why it should also be humanly possible to make an LE cert. I usually tae startssl as example but they are pretty easy you get a code by mail which you enter into the site (which makes sure that you have to have access to the admin/whois-email and the startssl account at the same time and then you can either let them create your keys (but seriously dont do this) or sent them a CSR, and it can be blank which makes it easier since you dont have to worry about the SANs and stuff (honestly why even care about the contents, CSRs are selfsigned in the first place and it is not very helpful to create a cert for a key that you dont have, that cert would be useless, so that’s that)


If you read just one sentence farther in that post, you’d see that they consider automation indispensable to ease of use:

This is apparently unfamiliar to you, but it shouldn’t be, because that’s what they’ve been talking about since they first announced this project–an automated system including client software to obtain and renew trusted TLS certificates. Every promo video they did demonstrated using client software to obtain a TLS cert from their server. Every talk they gave described how their client software would validate domain control and obtain certs from their server. Their first blog post talks about how they’re going to issue certs automatically. As has been repeatedly pointed out to you (including by LE staff), automation is one of their “key principles”, second only to “free”.

They’re about doing it automatically–that means without human intervention, so the email validation idea you keep bringing up doesn’t count. They’ve always been about doing it automatically. I don’t have a crystal ball, but I’d say the odds are good that they will always be about doing it automatically. If that is not consistent with your goals, hopes, or dreams, then, IMO, this is not the CA for you.


well it does say that the client side should also be automated but at the same time they dont explicitly deny manual use.

I am always a person who talks about OPTIONS, I dont take you automation away, in fact I dont care if you make your stuff so automated that the server could instantly buy a bulkload of domains and get a cert for it, but make it humanly possible to get the certs.

also I used startssl as an example.
you could also make it a lot more humanly possible if you wouldnt have to create a different validation for EACH AND EVERY subdomain, but for example when you want to verify a bunch of names you get one file which you can push to all needed locations and finish, that’s a LOT easier.

or do DNS challenge walk-up so I would only need to solve one challenge per root domain.

both parts make it a LOT easier for humans to get certs and the automation wont be broken.


I agree this is a problem with some existing software. For instance, someone pointed out IRC servers as an example.

However, I think we can all agree that this is a bug in the software, and we would be better off if that software was upgraded to allow outage-free certificate reloads. That way instead of an outage once a year, or six times a year, we could get to zero certificate-related outages.

I think free certificates with a 90-day lifetime provide a really good incentive to fix such software. You’re right that it will take some time, but if we use the same lifetime settings as commercial CAs, I don’t expect things will ever change.

This comes back to the heart of the question - automation. We have a number of key principles, of which “free” is just one. “Automatic” is another. Making changes to specifically support software that can’t be automated feels to me like it disagrees with that principle.


No, it doesn’t say the client side “should” be automated. It says the client side “has to” be automated. That wording is mandatory, not optional. LE considers client-side automation a “must-have”. Not “a good idea”, not “would be nice to have”: “we have to fully automate on the client side.”

Indeed they don’t, and in fact it’s possible, both with their client and with third-party services. But that isn’t their goal or their focus, and they don’t seem inclined to expend any effort to simplify that process. It does not seem to me that the LE team could have made this any clearer or more explicit–statements like “automation is a key principle” and “we have to fully automate on the client side” seem pretty explicit and unambiguous that their interest is in supporting automated issuance, and only in supporting automated issuance. But you’re familiar with these statements, and you clearly don’t interpret them in the same way. So I have to ask: how do you interpret them? More specifically, how do you interpret them in a way that makes you think they are interested in making manual issuance and renewal easier?

As to your other concerns, they remain off-topic in a thread about certificate lifetimes, as they were when you mentioned them last week.


I just tested with inspircd, calling the command /rehash -ssl trigger a reload of the certs and private key without disconnecting anyone. They may be others irc servers that do not support it, but the one I am oper on does.


I think moving to 1 year certs goes against the whole ethos of LE as a service which automates something which traditionally has been a very fiddly process. The reason traditional certs have 1 year+ lifetimes is because obtaining them is such a manual process and we don’t want to go through the steps to get these certs more than we have to!

Right now we’re seeing a rush of new LE clients appearing. With time (if not now) I’m sure we’ll see a pure shell script or C based LE client which can be run as a lightweight daemon process that is literally set and forget.

Switching to 365 day certs will remove the pressure to create good automated client implementations. Once the major distros have shipping LE packages which handle setting up certs in a frictionless way then by all means allow manual overriding of the 90 day period to something longer.

Right now I think is too early to make that change.


well I am fine if it will come even if not instantly.


Exactly. Like I have said, if the system actually needs that level of uptime, there is probably a failover and you can restart the systems for the new certificate using that failover redundancy. If you don’t have HA or DR, you probably don’t need 100% uptime and can handle during your scheduled maintenance period (you do have one, right?).

As for IRC daemons, in most public networks, you’re going to have netsplits more often than you’d need to reload for a certificate swap. If it’s a private server, well, we’re back to the planned maintenance window again.


The only worry I have with 90day certs and an automated process in the current implementation is that LetsEncrypt can (and has) changed the keys/authorities between signing events – and that can have compatibility issues.

If the keys/authorities change, and are not guaranteed to be 100% backwards compatible (in terms of os/browser/etc support), that is a huge worry. I would not like to find out that certs are no longer trusted on certain platforms from angry users or broken applications. I would also not like to see issues where things break because of cached certs (like in here IIS 8.5 building incorrect chain with Lets Encrypt Authority X3)

If there were a commitment to backwards compatibility (perhaps there is), or an option to peg the preferred authority for a grace period on renewals, that would probably address this concern.

With advance notice and timing, this sort of thing isn’t an issue – but in the current implementation, a lot of variables can change with little or no notice.


I actually think it is a good design decision to use 90 days renewal (even shorter, when we are up and running and out of beta). If the certs were valid for longer, people would most likely start to install them manually defeating the whole idea behind automated certificate renewal.

Yes there are some issues at the moment, but I don’t really think it is lets encrypts fault - yes they could have been more careful, and tested more for backwards problems given a longer transition periods, etc. - but it all boils down to windows not being ready for this automated process yet. Lets encrypt is still in beta remember, the beta is supposed to be used to catch things like this so that we in the future can get a smooth automated certificate renewals.


The issue primarily lies with loss of persistent connections, not downtime.

That’s changing the requirements to fit the implementation. A core goal of Let’s Encrypt is to make everything use TLS, and there’s no reason why legacy software (or software whose maintainers are unwilling to spend effort on hot-reloading) shouldn’t be in that list.

Virtually every IRCd, for example.

Frankly, having spoken to various IRCd developers over the years, I’d say that that’s extremely unlikely. The vast majority of them don’t appear to care for TLS at all, and it’s traditionally a culture in which user feedback isn’t really valued very much. I’m sure there are other ecosystems where the same applies.

It is exceedingly likely that IRCds will simply never come to support LE certificates, at all.

One of the principles you name isn’t quite accurate - the two principles at odds here are “automation” and “universally applied TLS”, not “free”. There’s a necessary tradeoff here - you can’t have both - and at this point Let’s Encrypt is favouring “automation” over “universally applied TLS”. I think that is a grave mistake.


Concretely, inspircd does.


I did say “virtually”. Inspircd is one of the few that isn’t completely stuck on the stone age.


FYI, it is possible to manage certificate rotations without dropping persistent connections.


Not if the software in question doesn’t support restart-less certificate reloads, as far as I’m aware.

EDIT: I’m not sure why my replies aren’t showing up as replies…


I have exactly the same opinion.

probably because a direct replay (aka, to the person directly above you) doesnt need to show up as reply because it directly follows.
when you reply a post further above then it should show.


No, not really. I’ve been following LE since they announced, and it’s always been about automated cert issuance. This is not a post hoc rationalization to fit the implementation they came up with, it’s specifically what they’ve been promising since they went public.

Where do you see “universally applied TLS” identified as one of LE’s key principles? Because it isn’t at