Maximum (and minimum) certificate lifetimes?

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.


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.


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.


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!


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.


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

Kelunik, there are many reasons why an operator might need to touch one of their servers, and 0day patching is one of them. However, the fact that I might need to apply a patch today is not even in the same ballpark as requiring daily maintenance. If any of my servers required manual daily maintenance, I would work to remove that requirement, or just stop administering servers.

For 90 day certs to be useful to the widest variety of users, the renewal automation has to be rock solid. I would resist signing up for doing any manual task at that frequency, and I suspect the target users would be at least as resistant as me. In situations where administration tasks are shared, I’m much less concerned about the 90 day lifetime - but I bet that a great number of websites are administered by individuals.

Because automation can fail, that’s a possible touch every time it runs. I would much rather perform one manual task per year than preside over 6 automated tasks per year which may fail in ways that leave me high and dry depending on how long I’m away from the keyboard. In the vacation example, I would have to remember to renew the cert before I depart, and that is unlikely to happen.

A 90 day lifetime makes great sense during the early days of this service, to exercise and improve the renewal process. I just hope that LetsEncrypt also wants to serve users who have been renewing certs on time for many years, and who don’t like the idea of either a) 6x more manual tasks per year, or b) depending on automation for such a critical part of the service configuration. Maybe later the lifetime can be extended…

All that said, even if the automation is rickety and renewal turns into a manual task for all the users, LetsEncrypt is still providing free certs to people, which is great because cert cost is probably a bigger barrier to widespread encryption than laziness stipulations from some graybeard such as myself :slight_smile:


@jsha Does LE send an email automatically if a certificate is not renewed just before it expires or just if the client failed to renew it?

@kelunik: Currently LE sends emails when a certificate is close to expiration. Our goal is that it will be smart about which certificates have already been renewed*, and not send unneeded emails, but that’s not yet implemented.

*Had a new certificate issued for the same names, under the same account.

1 Like

+1 for allowing certificate lifetimes for up to a year.

I’m fine with a default of 90 days, especially for those things that have rock-solid automation capability. Makes sense. However, in the world I live in, there may not be free time available to implement automation, change freezes at inconvenient times, difficulties getting maintenance windows, or there simply isn’t any applicable automation capability.

Or I’m simply too darn busy at work and the gear at home gets ignored.

Part of what the EFF stands for is Freedom (its in the name, last I checked) and that includes freedom of choice within reasonable bounds.

Thank you!


@jsha @bmw @schoen

maybe make LE ssl certificates 1yr by default for now and encourage 30 day, 60 day or 90 day auto renewals for testing the renewal process.

You can then add some fall back code for auto renewals.If they fail for whatever reason, they can auto redeploy a backed up copy of the original 1yr expiry ssl certificate as fall back. Or other way round is the new auto newed certificate only comes into play on successful auto renews otherwise the existing 1yr ssl certificate is in play.

This would ensure more testing of auto renewals if they knew there’s a fall back to the 1yr ssl certificate so less chance of downtime


Thanks for what you do, that’s important.

But come on guys, if you want people to adopt widely TLS/SSL you can’t keep this weird 3 month rule. I understand your point. With a year cert people are less likely to automate the process, but automating the process means adding a security weakness on a web server. One could run your script in a VM or jail and then automatically move the cert to the web server but that would be a pain.

If the last is about “Freedom” then please let people choose how they want to renew their certs. if they want to do it locally (using some weird script if you like, why not!) and then manually update the cert on the web server they have to be able to do so…

There can be an incentive so that people automate the process and create those strange 3 month certs if they want to. But if they don’t why can’t they choose otherwise?


Because some people believe they are appointed to control the world and everyone else is their subjects who they are charged with saving from themselves.

Graceful restart or config reload, or cert reload is only one part of the issue. And for many a minor part compared to the need of having a human interactive task that has to be done at least every 90 days for those with services that cannot or are not permitted to be automated. Thus, for such services the LE model is unmanageable.