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?!?!
2 Likes
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 ?
2 Likes
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.
2 Likes
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:
- Make everything encrypted, no matter whether the operator has a budget or not.
- Make people get into a habit of remembering renewals.
- 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.
10 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.
1 Like
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.
1 Like
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.
3 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:
2 Likes
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.
2 Likes
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.
8 Likes
if you have an own software then you could just implement your Own CA pin its root and do the certs yourself.
1 Like
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.
2 Likes
that's indeed best
what config paramter is for re-using existing CSR or existing private key ?
1 Like
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.
2 Likes
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!
5 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.
4 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.
1 Like
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. 
2 Likes
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 
3 Likes
@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?
1 Like