Maximum (and minimum) certificate lifetimes?

Thank you, yes, I do now remeber reading (perhaps in this thread or elsewhere) that the validation and certificate lifetimes were not locked to the same time table.

I think on the discussion should be another point remembered. "HTTP Public Key Pinning"
If you change the certificate in short interval than there are two options:

  1. You always use the same key and does not need to change the pinning. But have no security improvements.
  2. Always change the pinning and risk blocked users
  3. Pin the CA and then fixed to this CA.

The short lifetime will also be a disaster for those of us with DANE TLSA records… Is LE going to update my DNS records for me automatically? And more importantly, should I let it!!!

1 Like

indeed presents an interesting problem

maybe allow 1yr renewals with every 30, 60 or 90 day reminder emails/news/bulletins for latest ssl security related matters ?

1 Like

another way to do HPKP with LE would be that you always generate the next key and set it as second key that you keep for the next cert and set the lifetime to 90 days then when the cert expires you use the “next key” we generated before (becoming the new main key) for a cert and generate the next “next key” and put the new main and the new next key in the HPKP.

1 Like

I feel like there’s some serious scope creep going on here, negatively affecting the stated purpose of Let’s Encrypt.

We’re talking about a number of different things:

  1. Make everything encrypted, no matter whether the operator has a budget or not.
  2. Make people get into a habit of remembering renewals.
  3. Make software implement graceful restarts.

I’d say that point 3 is well outside of scope for Let’s Encrypt. It’s not LE’s job to make people write better software. Sure, it’d be a nice bonus - but not at the cost of LE’s core goals.

Point 2 also appears like scope creep to me. Making people remember to renew in time through repetition - and it’s very debatable whether this is actually effective to begin with - is a software robustness concern, not a security concern. An expired cert won’t affect security; it will affect availability.

Point 1 is the stated goal of Let’s Encrypt. I interpret “everything” as meaning “as close to 100% as we can get”. In this interpretation, both point 2 and point 3 negatively affect this goal.

Making people switch to software that can gracefully restart sounds great in theory, and I’ve seen a number of economic arguments come by in this thread, but fundamentally it conflicts with the “whether the operator has a budget or not” point. Some people may simply be stuck with the software they’re using, and not be able to switch. This makes them avoid Let’s Encrypt (or SSL/TLS altogether!) which in turn conflicts with point 1.

Trying to make people remember to renew will also scare people away from Let’s Encrypt, because of the increased risk of breakage. When on a budget, they may decide not to do SSL/TLS at all. This, again, conflicts with point 1.

Making people automate everything is not viable either, for the reasons mentioned before - their software of choice may simply not support it, they may not have the time to implement it, they may not be able to do automated renewal because of internal policy reasons. There is no viable “duct-tape solution” of just manually renewing certificates until they manage to automate it, and this will drive people away from LE and possibly SSL/TLS. Again, conficts with point 1.

I feel that Let’s Encrypt should, first and foremost, focus on their core goal - to make authenticated encryption ubiquitous, no matter budget, technology, or environment. Encouraging people to build more robust software and adopt better habits should, at most, be a secondary concern, to be worked on once the core goal has been accomplished (or is on track of being accomplished).

It is not reasonable to forgo the core goal in favour of these secondary goals. It’s scope creep, and seriously threatens the success of Let’s Encrypt.

9 Likes

A 90 day duration means I can’t realistically pin Let’s Encrypt certs. Updates in my software are several months apart already, and many users don’t frequently update anyway. I’m not willing to pin anything wider than individual certificates, and I don’t think updates failing for users three months behind is an acceptable option either.

I would recommend pinning the public key your API is utilizing. That way you retain full control over the scope of the pin, and nothing needs to change in applications as you renew the certificate unless for some reason you need to regenerate keys. You could even pin two keys, one for compromise recovery.

You have no security improvements? Of course you have.
This way you can use HPKP, do not have to change the key pin and just renew the cert every 90 days.

Do you always get a new certificate every 90 days??
You might probably just make to use a key size, which is large enough to be used around one year without having to worry about potential crack attempts by attackers with huge resources (aka nation-states).
Currently already 2048bit is considered secure enough, but if you want to make everything sure you can use 4096bit certs - also with LE.

This way it is IMO enough to change the certificate every year if you want to. That’s more than sufficient secure if you use a large enough key length.
And - to get back to HPKP - you only have to adjust the HPKP header once a year and can still benefit from an automated, free certificate service (LE) and - last but not least - the security improvident thanks to HPKP.

Besides this I also think @My1’s approach is interesting, but I’ll express this in another comment to stop putting everything in this one.

2 Likes

Very nice idea.
The only bad thing is that occasional visitors (who only visit the site after 90 days) do not benefit from the security mechanism HPKP. But possibly you do not have many of such visitors, so that this does not matter.
Just keep in mind that the certificate lifetime might be reduced below below 90 days in the future, so in this case this might be more important.

But generally your idea is really nice. To have this automated - preferable in the official LE client - which would also automate the HPKP header configuration is really a wonderful idea. This way HPKP would get much simplier.
The thing is: It’s as risky as before. That’s why the LE client obviously still has to generate backup certs. This is no problem, but it somehow has to convince the administrator move these backup certs off the server (at least one of them) and store them somewhere securely else. That’s where the automation ends.
However this could also be simplified very much by creating enough backup certificates for, say… one year, storing the pins and telling the admin to put them somewhere else. Afterwards the client could just use the (pregenerated) pins (aka hashes) and put them in the HPKP header. Additionally it should inform (mail) the admin the currently used backup key so he is able to use the right one in case he is not able to find this out later.

Related:

1 Like

It’s not practical to do. The API (although I’d hesitate to use the term. The mechanism is extremely simple) is accompanied by pages users may wish to view in browser. I could potentially not check the cert validity when connecting and use a separate signing mechanism, but this would increase complexity in a way I’d rather avoid. For now, I’ll be keeping with the longer duration free certs.

1 Like

Well, I just got into the beta, and I’m just absolutely appalled at this 90-day policy. This doesn’t achieve any of your stated goals, and in fact actively works against them.

Early in the thread, you say that manual mode is required by customers, but then you very explicitly try to make manual mode as unpleasant as you possibly can.

What are you people thinking? Are you nuts? One-year manual-mode certificates are reasonable. 90 day certificates just aren’t. All you’re doing is putting up hurdles to adoption.

Further, it’s quite difficult to use with key pinning. In essence, you are actively going out of your way to both make your certificates less usable, and your users less secure.

It can be automated and be a year. Trying to force people into automation is just going to force them not to use your service. I’m one of them; I think it’s very unlikely that I will put any of your certificates into production unless I know they will work for at least a year.

Instead of forcing automation, MAKE IT ATTRACTIVE. But make it attractive by making it work, by making it rock-solid reliable, and by publishing great instructions on how people can automate their key renewals.

Making it attractive by kneecapping any other way to do it … all I want to do at this point is extend a big middle finger to the people championing this boneheaded idea.

edit to add: you are trying to use your service to control the behavior of others, but you’re doing it in a way that makes them LESS secure, not more. The whole control idea is crap to begin with, but then controlling them in a way that screws up the technically proficient is deeply, deeply stupid and counterproductive.

7 Likes

if you have an own software then you could just implement your Own CA pin its root and do the certs yourself.

HPKP works off the SPKI (public key hash), not the certificate. That’s why you can generate the hash from the private key file before you even generate a CSR. As long as you don’t regenerate your site’s private key, you don’t need to do staggered key rollovers with 90 day limits, you can push that out to nicer, longer timeframes.

I asked in #letsencrypt this morning whether the letsencrypt-renewer script would default to regenerating the private key each time, or keep it and re-submit the prior CSR. I’m told right now the idea is regenerate by default – but there should be a config parameter to change to re-using the existing CSR/private key. Clearly that’s what you and I want to turn on.

Having a backup key is still extremely critical for compromise recovery, so it’s still something that should have great care taken in implementation.

I guess what I mean to say is, there’s nothing about short-lived certs that stops you from using HPKP, but it does mean we have a distance to go on tooling before we can reach admin nirvana.

1 Like

that’s indeed best

what config paramter is for re-using existing CSR or existing private key ?

I’d suggest moving this HPKP discussion to another thread (or continuing it there) as it’s quite unrelated to the lifetime of the certificates.

1 Like

Just to throw in another opinion, as I just got into the beta:

I use WebFaction which allows for free certificate usage and installation. However, to get a certificate on my host, I have to generate the cert and key, place it in my home dir on the host, and submit a support ticket to have it installed. This is obviously not really possible to automate.

Right now, I use StartSSL one year certs. I’m a software engineer by trade, but don’t maintain certs for work. Rather, I use the certs for various organizations for which I volunteer, some freelance, and my personal sites. Right now, I have about 15-20 domains I manage, about half of which use TLS right now. I’d like to get them all on TLS, and am hoping that LE will allow this to occur.

However, since I maintain these certs on a volunteer basis and have to go through about a 10 minute process per cert, this leaves me spending about 2-3 hours every three months to update them all. Right now, that is spread out over a year, and is still part of why I’ve only used certs for those sites that really need them.

I’ve submitted a ticket with WebFaction about offering an API for cert renewal, and hope that they might offer something with which I can integrate the LE client for automatic renewal. But I really don’t expect them to jump on this, nor do I expect most other hosts to do so.

While I agree with the ideal of automated renewal of 90 day certs, I don’t think it will work in practice. If I could get 1-2 year certs, even if they were only available via manual mode, I’d be happy. I’d appreciate it if those who are working on this wonderful project would seriously reconsider this policy.

Thanks for all of your work on this!

4 Likes

Hi! First off all, thanks for doing this - it’s a very good cause.

In my experience, it is 100% true that certificate expiration errors are a serious problem, and occur way more frequently than they should. This is precisely why I am frustrated by the choice of 90 days for the certificate lifetime. Even if the auto-renewal software is flawless (which is asking a lot), I am concerned about the notion of performing critical and potentially fatal configuration changes to a production service at such frequent intervals. On top of that, certificate renewal with an external CA constitutes an additional external dependency on that CA, and the surrounding renewal infrastructure that is unique to LetsEncrypt.

Let’s say auto-renewal fails at the 60 day mark and keeps failing (for whatever reason - maybe not the fault of LetsEncrypt), and I’m on vacation for 20 days. I return to find that I have 10 days to get a new cert. To me, this wouldn’t be an acceptable arrangement (because it precludes 30 day vacations, obviously ;).

Every change is a risk. Structuring things to require frequent changes (when there is an easy option to not require frequent changes) is risky, so I would strongly encourage LetsEncrypt to provide an option for longer certificate lifetimes.

3 Likes

Long vacations are a valid point I think.

Maybe there will be another ACME CA that pops up that will offer longer certificate lifetimes. It just wouldn’t push automation as much and there wouldn’t be as much pressure for it to be reliable automation … which is important.

In the future, with multiple ACME CAs, perhaps one could be used after another for redundancy.

Just renew your certificate just before you leave, you can stay away 90 days then. 30 days as single operator is a risk anyway, other vulnerabilities may arise such as a second Heartbleed. :wink:

1 Like